Subject: Re: draft-bernstein-ccamp-gmpls-vcat-lcas-01 comments - 3rd try

From: Huub van Helvoort <[email-masked]>
Date: Sun, 23 Oct 2005 11:30:45 +0200

Thanks Adrian,

> Huub, I don't see them in the spam bucket, but given the rate of arrival
> of new spam it is possible they went out the over flow before I got there
> :-(
> 
> Please post again.

OK, the resend with attachment did not work, this time in-line
without diff-marks.

My comments are based on ITU-T recommendation G.806 clause 10
and appendix VII.
This may be a good reference to add at the end of the draft.

If you need more information, please feel free to ask me or
read all about VCAT, LCAS (and GFP) in my book:
"Next generation SDH/SONET: Evolution or Revolution?"
John Wiley & Sons  ISBN: 0-470-09120-7

Cheers, Huub.

================================================================
                http://members.chello.nl/hhelvoort
================================================================
Always remember that you are unique...just like everyone else...

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

CCAMP working Group                                         G. Bernstein
Internet-Draft                                         Grotto Networking
Expires: April 14, 2006                                      D. Caviglia
                                                                  Marconi
                                                                R. Rabbat
                                                                  Fujitsu
                                                         October 11, 2005

Operating Virtual concatenation (VCAT) and the  Link Capacity Adjustment
  Scheme (LCAS) with Generalized Multi-Protocol Label  Switching (GMPLS)
                 draft-bernstein-ccamp-gmpls-vcat-lcas-01

Status of this Memo

    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

    This Internet-Draft will expire on April 14, 2006.

Copyright Notice

    Copyright (C) The Internet Society (2005).

Abstract

    This document describes the use of the Generalized Multi-Protocol
    Label Switching (GMPLS) control plane in conjunction with the Virtual
    Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its
    companion Link Capacity Adjustment Scheme (LCAS) which can be used

Bernstein, et al.        Expires April 14, 2006                 [Page 1]

Internet-Draft            GMPLS, VCAT and LCAS              October 2005

    for hitless dynamic resizing of the inverse multiplex group.  These
    techniques apply to the Optical Transport Network (OTN), Synchronous
    Optical Network (SONET), Synchronous Digital Hierarchy (SDH) and
    Plesiochronous Digital Hierarchy (PDH) signals.

Table of Contents

    1.  Overview of VCAT and LCAS  . . . . . . . . . . . . . . . . . .  3
      1.1.  VCAT signals and components  . . . . . . . . . . . . . . .  3
      1.2.  VCAT Capabilities and Limitations  . . . . . . . . . . . .  3
      1.3.  The LCAS Protocol  . . . . . . . . . . . . . . . . . . . .  4
    2.  Problem Statement and Current Support  . . . . . . . . . . . .  5
      2.1.  Discovery of Enabled End Systems . . . . . . . . . . . . .  5
      2.2.  Client to End Point Mappings . . . . . . . . . . . . . . .  5
      2.3.  VCAT configuration without LCAS  . . . . . . . . . . . . .  6
      2.4.  VCAT configuration with LCAS . . . . . . . . . . . . . . .  7
      2.5.  Component Signal Configuration Scenarios . . . . . . . . .  8
    3.  Possible Extensions to GMPLS to support additional
        VCAT/LCAS scenarios  . . . . . . . . . . . . . . . . . . . . . 10
      3.1.  Mechanisms for Discovery of VCAT/LCAS  . . . . . . . . . . 10
      3.2.  Mechanism to Support Multiple Client to End Point
            Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 10
      3.3.  Support for Component Signal Configuration Scenarios . . . 10
    4.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
    Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 12
    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
    Intellectual Property and Copyright Statements . . . . . . . . . . 14

Bernstein, et al.        Expires April 14, 2006                 [Page 2]

Internet-Draft            GMPLS, VCAT and LCAS              October 2005

1.  Overview of VCAT and LCAS

    Virtual Concatenation (VCAT) is a standardized layer 1 inverse
    multiplexing technique that can be applied to OTN [6], SONET [3], SDH
    [2], and PDH [5] component signals.  By inverse multiplexing we mean
    a method that combines multiple links at a particular layer into an
    aggregate link to achieve a commensurate bandwidth capacity on that
    aggregate link.  More formally, VCAT essentially combines the payload
    bandwidth of multiple path layer network signals (or trails) to support
    a single client (e.g.  Ethernet) layer link.
    For a more detailed introduction see [1].

1.1.  VCAT signals and components

    In the following we will use SDH terminology rather than both SONET and
    SDH terminology.  In SDH Virtual Concatenation (VCAT) can be applied to
    the following component time division multiplex (TDM) signals 
referred to
    as Virtual Containers (VCs): VC-11, VC-12, VC-2, VC-3, and VC-4.

    Only like component signals can be aggregated into a VCAT group (VCG).
    These VCGs are respectively known as: VC-11-Xv, VC-12-Xv, VC-2-Xv,
    VC-3-Xv, and VC-4-Xv.  In the previous designations X is an integer 
indicating the number of members in the VCG. The value of X for high 
order VCs (VC-3 and VC-4)can be from 1 to 256; and for low order VCs 
(VC-11 VC-12 and VC-2) the value of X can be 1 to 64. See [2] for details.

    VCAT can be applied to the following PDH signals as specified in 
reference
    [5]: DS1,E1, E3, DS3.  Similar to the SONET/SDH case these component
    signals can only be combined with like signals to produce 
aggregates.  For
    some reason the VCGs of the PDH signals were not given unique 
designations
    in [5] so we shall adopt a similar notation to the SDH VCAT signals for
    the permitted PDH VCAT signals that follow: DS1-Xv, E1-Xv, E3-Xv, 
DS3-Xv.

    Concatenation in the optical transport network (OTN) is realized by
    means of virtual concatenation of Optical Channel Payload Unit (OPU)
    signals.  OPUk signals (k=1, 2, 3) can be concatenated into OPUk-Xv
    aggregates with X= 1,..., 256.  See reference [6] for details.

1.2.  VCAT Capabilities and Limitations

    VCAT performs inverse multiplexing by octet/byte de-interleaving of the
    encapsulated client bit stream into the individual VCs of the VCG 
and the
    VCs are transported across the network independently from each 
other. Due
    to the possible different propagation times of the VCs, a differential
    delay may occur between the individual VCs at the path termination. This
    differential delay has to be compensated and the VCs have to be 
realigned.
    This is summarized for the different signal types in reference [1] with
    details given in the respective standards documents [2] [3].

Bernstein, et al.        Expires April 14, 2006                 [Page 3]

Internet-Draft            GMPLS, VCAT and LCAS              October 2005

1.3.  The LCAS Protocol

    The Link Capacity Adjustment Scheme for VCAT signals is a protocol
    for dynamically and hitlessly changing (i.e., increasing and
    decreasing) the capacity of a VCG.  LCAS also provides survivability
    capabilities, automatically decreasing the capacity if a member of the
    VCG experiences a failure in the network, and increasing the capacity
    when the network fault is repaired.  LCAS, itself, provides a mechanism
    for interworking between LCAS and non-LCAS VCAT end points.  VCAT does
    not require LCAS for its operation.

    LCAS functionality does not overlap or conflict with GMPLS' routing or
    signaling functionality for the establishment of component links or
    entire VCGs.  LCAS instead is used to control whether a particular
    component signal is actually put into service carrying traffic for 
the VCG.

    LCAS provides for graceful degradation of failed links by having the 
sink
    end(s) report back the receive status of all member components.  In the
    case of a reported member failure, the source end will stop using the
    failed member and distribute the data over the remaining ‘good’ members,
    thus transmission is restored to a reduced bandwidth capacity. The 
source
    end will send an LCAS message to the sink end that it is not 
transmitting
    data on that failed member.  The worst case notification times are
    summarized in [1].

Bernstein, et al.        Expires April 14, 2006                 [Page 4]

Internet-Draft            GMPLS, VCAT and LCAS              October 2005

2.  Problem Statement and Current Support

    In this section we list a number of VCAT/LCAS usage scenarios and
    their current level of support.  We will evaluate the applicability
    of GMPLS to these scenarios and for those scenarios that GMPLS does
    not currently support we describe possible GMPLS extensions in
    Section 3.  Note the term "component" signal in the text is used as a
    simplified notion to the more formal concepts of VC-n, ODUk, and PDH
    termination function as well as VC-n, ODUk and PDH path/trail.

2.1.  Discovery of Enabled End Systems

    Discovering VCAT: VCAT sources can only communicate with VCAT capable
       sinks.  Hence the VCAT capabilities of a PDH, SDH, or OTN path
       termination points need to be known.

       Currently no support for discovery of VCAT or LCAS apriori, i.e.,
       via routing information.  Support for "discovery" of VCAT
       capability at connection establishment time via signaling, i.e.,
       we can request VCAT connection and if the end system cannot
       support it,it would refuse the connection.  TBD -- is there a
       specific error code concerning "VCAT not supported".

    Discovering LCAS: LCAS offers additional functionality between VCAT
       capable sources and sinks.  Hence the LCAS capabilities of VCAT
       enabled path termination points can be useful to know in advance
       of component signal setup.

       Currently there is no mechanism to ask for an LCAS enabled end
       point nor is there a way to find out if the other end is LCAS
       enabled until after the connection is established.  This is a
       problem if we specifically want hitless dynamic resizing or fast

       graceful degradation for a VCG.

2.2.  Client to End Point Mappings

    Fixed Client to End point Mapping: Per client signal there is a
       VC-n-Xv circuit in which the X VC-n termination points are
       dedicated to this client signal.  At any point in time, Xa (active
       members) out of Xp (provisioned members) VC-n termination points may
       be set up to carry client traffic.
       For example when VCAT is deployed on a Router, the VCG connects
       directly to one STM-N interface port (in absence of a HO or LO switch
       fabric in the router).  The transport network may then transport the
       individual VCs  via one or more routes. Diverse routing will incur a
       differtial delay.

Bernstein, et al.        Expires April 14, 2006                 [Page 5]

Internet-Draft            GMPLS, VCAT and LCAS              October 2005

    Variable Client to End point Mapping: For a set of M client signals
       there are M*VC-n-Xv VCAT endpoints sharing a set of N (N>M) VC-n
       termination points.  It is possible that M*X > N (example: M=10, X=7,
       N=64); i.e. there may be a kind of overbooking.  Implication: must be
       able to accommodate multiple different sized VCGs at an "interface".
       For example an STM-64 interface can support many different VC-4-Xv
       groups, providing the total number of VCs does not exceed the 
interface
       total capacity.

    Implications: In both these cases we can have more than one VCG per 
GMPLS
       link.  In general it is the responsibility of the signaling entity at
       the source and destination ends to choose the appropriate VC-n
       termination points for the VCG and in the case of "variable client
       mapping" to perform needed internal configuration.  However multiple
       VCGs per GMPLS link or GMPLS addressed entity introduces an
       unresolvable ambiguity when disjoint connections are set up or
       dynamic resizing is applied since there is currently no "VCG
       identifier" in GMPLS signaling.

2.3.  VCAT configuration without LCAS (MI_LCASEnable=false)

    Base Configuration: For VCAT to operate the sink end needs to be
       informed of how many components are in the VCG.  It has no
       other way of knowing if it is currently receiving all components
       intended to be in the group.

       Fixed sized co-routed groups are supported with current GMPLS
       signaling.  Diversely routed groups are not currently supported.

    Group Resizing: Additions or removals of components from a non-LCAS VCG
       are not hitless, that is data loss will occur while the source and
       sink are reprovisioned as to the number of members in the group.

       Currently not supported within GMPLS.  In particular, with each
       addition or removal of a component the sink end point needs to be
       told the expected number of components in the group.

    Failure Conditions: Failure of a component must detected external to
       VCAT system.  The entire group is rendered inoperable until the 
failed
       component is taken out of service (or replaced) by 
re-provisioning both
       source and sink to that effect.

       Currently not supported within GMPLS.  The source and sink need 
to be told
       what component has failed and remove it from service.

Bernstein, et al.        Expires April 14, 2006                 [Page 6]

Internet-Draft            GMPLS, VCAT and LCAS              October 2005

2.4.  VCAT configuration with LCAS (MI_LCASEnable=true)

    Base Configuration: Sink end (and source end) are first configured with
       the value of Xp (the provisioned number of members), out of Xm (the
       technology specific maximum number of members) with Xm ³ Xp.  LCAS
       then determines automatically the number of active members Xa and
       puts them into service for the group.

NOTE: The value of Xm is not only technology dependent, it can also be
implementation dependent. E.g. in a routerinterface with STM-64 line 
rate for a VC-4-Xv based VCG Xm = 64 and not 256. Xm cannot be 
provisioned, it can be retreived from the VCG (as well as Xa).

       Currently both co-routed and diversely routed VCGs can be
       supported if there is no VCG ambiguity.

    Component Addition: When a new component signal has to be added to a
       VCG the following procedure applies.

       1.	Establish a connection from Source to Sink for the member to 
be added.
	2.	Provision the Source to use the ‘new’ member as one of the active 
group (Xp -> Xp+1). This entails sending the ADD command by the new member.
	3.	Provision the Sink to recognize the ‘new’ member of the VCG (Xp -> 
Xp+1).

	The order of doing the above is not important. When the ADD command is 
received by the sink it will return an ‘OK’ to the Source at which time 
the Source will use all active members (old + new) to transport the 
client traffic.

       This procedure does not affect the already established LCAS members,
            that is, client traffic is not sent on the new component 
until the
            LCAS procedure is complete;

       This can be supported within GMPLS if, after GMPLS has successfully
            established a potential new component, the source end
            LCAS is (internally) told to add it to the group.

    Component Removal: When a component is removed the following procedure
           applies:

	1. 	On receipt of a remove command (for a particular member) from the 
management system, LCAS Source will stop using that member; the Sink 
will recognize that that member no longer carrier client traffic and 
will use only the remaining members to reconstitute the client signal. 
Note: The current LCAS protocol allows for the ‘decrease’ command to be 
initiated at either the LCAS source or the LCAS sink; if it is initiated 
at the sink there will be a hit to the reconstructed data.
	2.	The connection, source provisioning and sink provisioning of that 
member can then be removed from the VCG.

Bernstein, et al.        Expires April 14, 2006                 [Page 7]

Internet-Draft            GMPLS, VCAT and LCAS              October 2005

       3.  The component connection can be, if needed, removed from the
           transport network.

       This can be supported within GMPLS if, before GMPLS tears down a
       component, LCAS is told (local to source end) to remove the
       component from service in the group.

    Component Failure: When a component fails:

	1.	The LCAS sink detects the failure (how this is done is outside the 
scope of this ID) and informs the source of this failure via the member 
status (MST)information.  :

       2.	The source then takes the failed component out of service and 
uses only the remaining ‘good’ members to transport the client traffic 
(Xa -> Xa-1). Note: No re-sequencing of the VCG is done at this time.

       When the failed component is repaired, LCAS can automatically add
       the repaired component back to the group, or alternatively a new
       component can be added to bring the group back to its original
       size.  Note that component failure is not hitless, but note the
       fast notification times of [BernDiegoRabbat].

       Currently supported since no action required of GMPLS.

2.5.  Component Signal Configuration Scenarios

    Here we use the term "group" to refer to the entire VCG and
    the terminology "set" and "subset" to refer to the collection of
    potential VCG member signals.  Note that all assesments of
    whether a scenario is currently supported assumes either (a) a single
    VCG per GMPLS addressable entity, or (b) a mechanism is in
    place to disambiguate multiple VCGs (see Section 2.2).

    Fixed, Co-routed: A fixed bandwidth VCG, with all members 
transported over
       the same route.  This is the case where the
       intended bandwidth of the VCG does not change and all
       member signals follow the same route.  The intent here is the
       capability to allocate the "right" amount of bandwidth.

       Currently supported in GMPLS.

    Fixed, Diverse-routes: A fixed bandwidth VCG, with the members 
transported
       over at least two different routes.  The intent here is additional
       resilience and graceful degradation in the case of failure.

Bernstein, et al.        Expires April 14, 2006                 [Page 8]

Internet-Draft            GMPLS, VCAT and LCAS              October 2005

       If LCAS is present this scenario is supported under GMPLS.  Not
       supported without LCAS since we need two-way communications of
       some type between source and sink to coordinate which members are
       to be used in the group in a failure scenario.

    Dynamic, Co-routed: A dynamic VCG (bandwidth can be increased
       or decreased via the addition or removal of member signals),
       with all the members transported over the same route.  Intent here is
       dynamic sizing of bandwidth.

       If LCAS present this scenario is currently supported by GMPLS.
       Implications: LCAS is needed for hitless resizing.  Note before
       LCAS can do its part of getting traffic over the modified VCG, 
the two VCAT/LCAS endpoints need to be configured (Xp -> Xp+1 or Xp -> 
Xp-1); this requires either "communication" between the two
       endpoints (when one of the endpoints is configured by call/
       connection controller, or simple communication of the call/
       connection controller with both endpoints.  Without LCAS we still
       need two way communications between source and sink to coordinate
       which members are used in the group and changes will not be
       hitless.

    Dynamic, Diverse-routes: A dynamic VCG, with the members transported 
over at
       least two different routes.  Intent here is dynamic resizing and
       resilience.

       Currently support and implications similar to the "dynamic, co-
       routed" and "fixed, diverse-routes" cases.

    Shared Pool: Two or more VCGs between the same source and sink
       who desire to share a pool of component signals between them.
       Each VCG may have a dedicated set of members, and may also
       obtain additional members from a "common pool" of components.
       Note that at any given point in time a component signal can belong
       to at most one VCG.  The intent here is to allow dynamic
       resizing of VCGs via the sharing of a pool of established
       component signals without requiring complete circuit provisioning,
       i.e., only the group membership of the component signal would change.

       Currently not supported by GMPLS.  Implications: a communications
       mechanism between source and sink to indicate during a "change"
       which group a component should now belong.

Bernstein, et al.        Expires April 14, 2006                 [Page 9]

Internet-Draft            GMPLS, VCAT and LCAS              October 2005

3.  Possible Extensions to GMPLS to support additional VCAT/LCAS
     scenarios

    Here we look at what might be reasonable to add to GMPLS to support
    the interest scenarios of Section 2 that were not currently covered.

3.1.  Mechanisms for Discovery of VCAT/LCAS

    Would like to get both VCAT and LCAS capability of end systems via
    routing...

    Would like to be able to specifically ask for LCAS capability via
    signaling...

3.2.  Mechanism to Support Multiple Client to End Point Mappings

    This is a very important capability and it is very similar to one
    that is being proposed in the end-to-end signaling for recovery I-D.
    In particular the ASSOCIATION object.  Note, however, since there is
    a rather high probability that at some point we might use VCAT/LCAS
    with GMPLS based protection we would really need an ASSOCIATION
    object type specific to VCAT.  Association objects are not unique and
    therefore adding a new type to the Association object would make it a
    good candidate to support this requirement.

3.3.  Support for Component Signal Configuration Scenarios

    TBD based on analysis of use of admin-status object.  If the admin-
    status object is sufficient we will detail its use in this
    application since it is currently an optional object.

4.  References

    [1]  Bernstein, G., Caviglia, D., and R. Rabbat, "VCAT/LCAS in a
         Clamshell", To Be Published available at http://
         www.grotto-networking.com/pages/VCAT-in-a-Clamshell-DRAFT.pdf,
         October 2005.

    [2]  International Telecommunications Union, "Network node interface
         for the synchronous digital hierarchy (SDH)", ITU-
         T Recommendation G.707, December 2003.

    [3]  American National Standards Institute, "Synchronous Optical
         Network (SONET) - Basic Description including Multiplex
         Structure, Rates, and Formats", ANSI T1.105-2001, 2001.

    [4]  "Link capacity adjustment scheme (LCAS) for virtual concatenated
         signals", ITU-T Recommendation G.7042, February 2004.

Bernstein, et al.        Expires April 14, 2006                [Page 10]

Internet-Draft            GMPLS, VCAT and LCAS              October 2005

    [5]  "Virtual concatenation of plesiochronous digital hierarchy (PDH)
         signals", ITU-T Recommendation G.7043, July 2004.

    [6]  "Interfaces for the Optical Transport Network (OTN)", ITU-
         T Recommendation G.709, March 2003.

    [7]  Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T.
         Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
         August 1996.

    [8]  "Information technology - Telecommunications and information
         exchange between systems - Local and metropolitan area networks
         - Specific requirements - Part 3: Carrier sense multiple access
         with collision detection (CSMA/CD) access method and physical
         layer specifications", IEEE Standard 802.3, March 2002.

    [9]  Bernstein, G., Rajagopalan, B., and D. Saha, "Optical Network
         Control: Archtecture, Protocols", Addison-Wesley, 2004.

Bernstein, et al.        Expires April 14, 2006                [Page 11]

Internet-Draft            GMPLS, VCAT and LCAS              October 2005

Appendix A.  Acknowledgements

    The authors would like to thank Maarten Vissers for extensive reviews
    and contributions to this draft.

Bernstein, et al.        Expires April 14, 2006                [Page 12]

Internet-Draft            GMPLS, VCAT and LCAS              October 2005

Authors' Addresses

    Greg Bernstein
    Grotto Networking

    Phone: +1 510 573 2237
    Email: [email-masked]

    Diego Caviglia
    Marconi

    Email: [email-masked]

    Richard Rabbat
    Fujitsu

    Phone: +1 408 530 4537
    Email: [email-masked]

Bernstein, et al.        Expires April 14, 2006                [Page 13]

Internet-Draft            GMPLS, VCAT and LCAS              October 2005

Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.  Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the use of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR repository at
    http://www.ietf.org/ipr.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at

    [email-masked].

Disclaimer of Validity

    This document and the information contained herein are provided on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

    Copyright (C) The Internet Society (2005).  This document is subject
    to the rights, licenses and restrictions contained in BCP 78, and
    except as set forth therein, the authors retain all their rights.

Acknowledgment

    Funding for the RFC Editor function is currently provided by the
    Internet Society.

Bernstein, et al.        Expires April 14, 2006                [Page 14]