[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

   Network Working Group                     D. Papadimitriou (Alcatel)
   Internet Draft                            N. Sprecher      (Siemens)
                                             J. Cho              (ETRI)
   Expires: July 2006                        L. Andersson    (Acreo AB)
                                             D. Fedyk, D.Allan (Nortel)
                                             A. Takács       (Ericsson)
                                             D. Caviglia     (Ericsson)

                                                          February 2006


               Label Encoding Solution Decoder and Analysis
           for GMPLS-controlled Ethernet Label Switching (GELS)

                  draft-dimitri-gels-solution-eval-00.txt


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.

   For potential updates to the above required-text see:
   http://www.ietf.org/ietf/1id-guidelines.txt

Abstract

   This document introduces the functional criteria as a decoder ring
   for the selection of GELS label encoding. After detailing each
   proposed label encoding, each solution is analyzed against these
   criteria.



D.P. GELS                Expires - July 2006                 [Page 1]


Solution Decoder and Analysis for GELS                        Feb 2006


Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [i].

   Reader is also assumed to be familiar with the GELS framework [GELS-
   FRM].

1. Terminology

   L2SC Label Switch Router (LSR): LSR whose interfaces are capable to
   recognize Layer 2 frame boundaries and can switch data based on the
   content of the Layer 2 frame header. In the context of this document,
   L2SC interfaces are limited to Ethernet interfaces.

   Ethernet Label Edge Router (E-LER): LER that resides either at the
   edge of the provider's GMPLS network (a.k.a. Provider Edge or PE) or
   at the edge to customer's network (a.k.a. Customer Edge or CE). In
   the former case, the Ethernet LER interfaces the customer’s network
   equipment. The E-LER has the functionality required for initiating
   and terminating point-to-point and point-to-multipoint Ethernet
   connectivity across the GMPLS network.

   Ethernet Label Switching Router (E-LSR): LSR that either resides at
   the core of the provider's GMPLS network (a.k.a. Provider node or P)
   or at the edge to provider's GMPLS network (a.k.a. Provider Edge or
   PE). In the former case, the Ethernet LSRs have no direct interfaces
   towards the customers' networks. The Ethernet LSR performs Ethernet
   label switching operation by means of a LIB configured by GMPLS.

   Ethernet Label Switched Path (LSP): Label Switched Path established
   between two Ethernet LERs (ingress and egress) using GMPLS signaling
   or between one ingress Ethernet LER and multiple egress LERs. In the
   former case, one refers to a point-to-point Ethernet LSP and in the
   latter to a point-to-multipoint Ethernet LSP.

   Label Information Base (LIB): table that specifies associations
   between incoming and outgoing Ethernet Labels included in Layer 2
   frame headers and outgoing ports. If different to the incoming label
   it also specifies the outgoing label.

   Connection Oriented Ethernet: defined by LSPs having a single source
   (ingress Ethernet LERs) and one or multiple destinations (egress
   Ethernet LERs). LSPs must be created before any Ethernet PDUs can be
   sent, but exist independently of whether any PDUs are being sent.
   There is no further routing choice within the LSP. These LSPs
   maintain ordering of Ethernet PDUs sent from source.



D.P. GELS                Expires - July 2006                 [Page 2]


Solution Decoder and Analysis for GELS                        Feb 2006


2. Functional Criteria

   This section attempts to set functional criteria for examining,
   analyzing and comparing the optional solutions listed in Section 3.
   Naturally, the first and the most important criterion should be
   compliance with the GELS requirements [GELS-REQ].

   At time of writing, this document was not finalized; hence, it may be
   thus necessary to tune and adjust this section on completion of the
   requirement draft.

   A description of the criteria follows. These functional criteria are
   solution independent and intended to simplify the GELS solution (in
   terms of label encoding) selection process for implementing
   connection-oriented Ethernet. Note that the order in which the
   criteria are specified does not imply the order of importance.

2.1 Ethernet P2P and P2MP TE LSPs

   Point-to-point (uni and bi-directional) and point-to-multipoint
   (unidirectional) connections are defined by trails, which have the
   property of being directed with a single source and one or multiple
   destinations. Traffic flows should be identified by some connection
   identifiers rather than by explicitly listing source and destination
   addresses. This makes Ethernet frame switching substantially faster
   (as FIDs are just simple look-up tables and are easy to implement in
   the hardware).

   In a connection-oriented Ethernet environment, p2p and p2mp
   connections must be used to construct all other networking services
   like mp2p and mp2mp services (see Section 2.3). That is, in
   connection-oriented Ethernet, p2p and p2mp connections are the
   primary focus that determines the underlying Ethernet label encoding
   scheme.

   Connection-oriented Ethernet enables the setting up of p2p and p2mp
   LSPs based on the service definition and the enforcement of the SLA.
   Connection oriented Ethernet also requires pre-provisioning of the
   network connections and that the required resources are pre-allocated
   and reserved. The solutions should enable realization of the Traffic
   Engineering resource-oriented (to optimize the network resource
   usage) and traffic-oriented (delay, jitter, loss, etc.) performance
   objectives based on the service definition to enforce the SLA.

2.2 Ethernet LSP Merging and LSP Multiplexing

   LSP merging is referred when at a network element multiple point-to-
   point LSP segments are joined into a single point-to-point LSP



D.P. GELS                Expires - July 2006                 [Page 3]


Solution Decoder and Analysis for GELS                        Feb 2006


   segment in a way that no further differentiation between the original
   LSP segments is possible.

   LSP multiplexing is the case when the joined point-to-point LSP
   segments can be differentiated later on in particular at the common
   receiver. There are two cases of multiplexing:
   - a separate label is assigned on a per sender basis
   - a common label is assigned independently of the sender

   The GELS framework discusses local vs. domain-wide labels
   (identifiers). While local labels provide simple method for LSP
   merging and multiplexing, usage of domain-wide labels results in
   dependence to the structure and the nature of the label.

   It must be noted that merging in contrast to multiplexing does not
   preserve the possibility to identify the source of the corresponding
   LSP(s).

   LSP merging and multiplexing deliver a way to provide mp2p services
   but impact network operation and maintenance requirements:
   (1) ability to identify specific faulty connections (using OAM
   mechanisms)
   (2) ability to police individual senders and connections.

   Therefore, LSP merging and multiplexing are optional capabilities to
   be supported by the solution.

2.3 Services

   The solution should be capable of providing any connectivity service
   that is supported by standard Ethernet encapsulation (such as
   IP/MPLS, TDM, etc.).

   The solution should not constraint the connectivity services delivery
   by the network.

   The solution should provide efficient means to simplify the
   provisioning task in the following aspects:

   1. The label distribution and allocation process should have a
   minimum effect on the network so as to reduce provisioning overhead,
   as well as to relieve the network synchronization process.

   2. Network configuration, provisioning and adjustment should have a
   minimum effect on the network and services it delivers.

   3. The solution should support network trunks in order to simplify
   the delivery of services.



D.P. GELS                Expires - July 2006                 [Page 4]


Solution Decoder and Analysis for GELS                        Feb 2006


2.4 OAM

   The solutions should provide means to simplify the network operations
   maintenance task.

   The use Ethernet OAM is required to monitor the proper operation of
   the network.

   The solutions should provide a means to minimize the number of LSPs
   that should be monitored. Only network trunks (nesting LSPs) should
   be monitored and there is no specific requirement to monitor the
   services within the tunnels. Services may be monitored according to
   specific service requirements.

   The solutions should enable the support for OAM (IEEE 802.1ag)
   messages. The following mechanisms should be supported to detect
   failures or problems in the network and to ensure the correct
   operation of the network:
   1) Connectivity verification
   2) Alarm communication and handling
   3) Loopback tests
   4) Fault diagnosis (e.g. traceroute)

2.5 Resiliency

   Network resiliency is the network's ability to restore traffic
   following failure or attack, and is a critical factor in delivering
   reliable services.

   Guaranteed service in the form of SLAs requires a resilient network
   that instantaneously detects facility or node failures and
   immediately restores network operation to meet the terms of the SLA.

   The solution should provide mechanisms
   o) to match the sub 50 ms failover times required to maintain time-
   bounded services. The solutions should also support recovery
   mechanisms that save network resources, that is, without pre-
   provisioning of bandwidth. For this kind of recovery mechanisms the
   failover time can be higher that 50 ms.

   o) to protect against any failure in the network (including failure
   of boundary nodes in case of inter-domain operation).

   The recovery mechanisms are categorized as end-to-end LSP recovery
   (global protection), LSP segment recovery, and local LSP recovery.

   The solutions should assure the correct inter-working between control
   plane and data plane (e.g. port protection) recovery mechanism.



D.P. GELS                Expires - July 2006                 [Page 5]


Solution Decoder and Analysis for GELS                        Feb 2006


2.6 Inter-domain

   The solutions should enable the provisioning of Ethernet LSPs over
   inter-domains. The peering and the client/server interconnection
   modes are considered, as follows:

   (i) Peering mode: Peering is a way of interconnection, where the
   interfacing between the domains/operators is defined by UNI/E-NNIs.
   Moreover, peering networks exchange traffic at the same networking
   layer, that is layer N traffic arriving for domain A will be
   forwarded in domain B as layer “N” traffic as well. It is possible to
   further subdivide this mode depending on which topology (addresses,
   resources, etc.) information are exchanged across the UNI/E-NNI
   interface.

   (ii) Client-server mode: The client/server mode of interconnection,
   the server operator provides a networking service that delivers the
   client’s traffic. Essentially, the client’s traffic resides on layer
   N and it transported transparently across the server layer N-1. The
   identifiers from the client layer and the server are independent. A
   natural example of this mode of operation is an Ethernet flow (layer
   N) transported via an SDH/SONET circuit (layer N-1).

   In certain scenarios, there may be a need to combine together
   different LSPs such that in the data plane, a single end-to-end LSP
   is realized and all traffic from one LSP is switched onto the other
   LSP. This operation is called LSP stitching [STITCHING].

   The solutions should support LSP stitching.

2.7 Scalability

2.7.1 MAC Address

   By nature, a solution for connection-oriented Ethernet should be
   agnostic with regard to MAC address learning such as to eliminate the
   FIB flush associated with topology change and flooding operations,
   which lead to slow recovery and convergence.

2.7.2 VLAN ID (VID)

   The scalability of the solution should not be impacted by the limited
   space of VLAN identifier (VID).

2.7.3 Ethernet Frame Switching

   Ethernet frame switching should be independent of the destination MAC
   address and SHOULD NOT rely on the customers' destination MAC
   addresses.


D.P. GELS                Expires - July 2006                 [Page 6]


Solution Decoder and Analysis for GELS                        Feb 2006



2.7.4 Label

   The scalability of the label value space (and hence its encoding)
   constraints the number of LSPs that can be concurrently provisioned.
   The solutions should therefore provide label value and encoding that
   allow a satisfactory number of LSPs to be provisioned [GELS-REQ].

   In addition, the Ethernet label is encoded in the Ethernet MAC frame
   header. Therefore, the size of the label affects the frame and the
   length of the payload.

   Scalability also depends on the size of the label and its implication
   on the Ethernet frame header size, e.g. MAC encapsulation (DA_B-MAC)
   in combination with B-TAG etc. or S-TAG (S-VID).

2.7.5 LSP Hierarchy

   LSP hierarchy can be used to improve the network scalability, the
   solutions should assure that label encoding is not constraining
   Forwarding adjacency LSP establishment [RFC 4206].

2.8 Backward compatibility with IEEE 802.1

   The label encoding techniques MUST make use of the structure of the
   standard IEEE 802.1 Ethernet frame and frame header.

   The encoding solution should not modify the format of the standard
   Ethernet frame or the standard Ethernet frame header but may add new
   semantics to one or more fields.

   Where the solution should co-exist with IEEE 802.1 bridge control and
   management functionalities on the same network element it should be
   backward compatible with legacy Ethernet bridges. In this case, GMPLS
   Ethernet switches need to be capable of handling all types of
   Ethernet MAC frames, including GMPLS-labeled frames, to ensure their
   co-existence with legacy Ethernet switches.

2.9 Applicability

   The solutions should be examined for each network scenario. It may be
   that a specific solution is found to be more appropriate for a
   certain network scenario while a different solution is more suitable
   for another type of scenario.

   The solutions should be examined with respect to their deployment in
   the following types of networks:
   1) Metro access and Metro aggregation networks
   2) Metro core


D.P. GELS                Expires - July 2006                 [Page 7]


Solution Decoder and Analysis for GELS                        Feb 2006


   3) Core and transport networks

   These scenarios should enable services to scale effectively as the
   customer base grows, in order to minimize capital expenditures and
   drive down operational costs.

2.10 Security

   The solution should provide a means to protect the network from the
   following threats:
   1) Vulnerability to unwanted connectivity (through malicious
   attacks).
   2) MAC spoofing and MAC attacks.
   3) VLAN ID attacks.

   The threats that concern the control plane are described in section
   5.4.1 of [GELS-FRM] and are not relevant in the present context.

3. Solution Description

   GMPLS makes use of the structure of the standard IEEE 802.1 Ethernet
   frame. The Ethernet label is inserted in the Ethernet encapsulation
   and is part of the Ethernet MAC frame header. A GMPLS Ethernet-
   labeled frame is defined as an Ethernet MAC frame whose header
   encodes the label value. The coding of the Ethernet label does not
   modify the format of the standard Ethernet frame, although it may add
   new semantics to one or more fields. The switching decision is based
   on the label part of the Ethernet frame header. Figure 4 depicts a
   logical view of the protocol layers.

                         +---------------------------+
                         |         Payload           |
                         +---------------------------+
                         |         Ethernet          |
                         +---------------------------+
                         |         Physical          |
                         +---------------------------+

                 Figure 4: Logical Protocol Layering Model


   The Ethernet MAC frame header includes the EtherType, different VLAN
   TAGs, as well as the destination and source MAC addresses.

   GMPLS functionality can co-exist with IEEE 802.1 bridge control and
   management functionalities on the same network element. The common
   network resources should be either pre-partitioning or dynamically
   selected.



D.P. GELS                Expires - July 2006                 [Page 8]


Solution Decoder and Analysis for GELS                        Feb 2006


   The architecture allows different label encoding techniques. A
   specific encoding technique may be selected according to the
   capability of the GMPLS-enabled Ethernet network element and/or to
   the capability of the label-controlled Ethernet interface, etc.

   Ethernet label and label switching technique must be extensible for
   the establishment and support of multiple-domain Ethernet LSP, point-
   to-multipoint LSPs (carrying Ethernet multicast traffic) and easily
   support exchange of Ethernet broadcast traffic.

   The following techniques are considered as candidate for the encoding
   of the Ethernet label.

3.1 S-VID Translation

3.1.1 Label Encoding

   This link-local label technique makes us of the IEEE 802.1ad S-VID
   (amendment to IEEE Std 802.1Q-1998) S-VID translation mechanism.

   The idea behind this solution is to prevent the control plane from
   dealing with any MAC address space specifics such as to ensure
   independence and transparency to the data plane addressing specifics.

   This results in a straightforward re-use of the GMPLS Unified control
   plane and TE mechanisms. Indeed, an Ethernet LSR behaves as any other
   LSR currently manageable by a GMPLS-based control plane.

   Figure 5 depicts the format of the standard IEEE 802.1ad Ethernet
   frame.

                                TAG
                             ---------
                            /         \
   +-----------+------------+----+----+----+---------------+--------+
   |           |            |    |    |    |               |        |
   | MAC Dest  |  MAC Src   |TPID|TCI |LEN\|    Payload    | FCS    |
   | Address   |  Address   |    |    |Type|               |        |
   |           |            |    |    |    |               |        |
   +-----------+------------+----+----+----+---------------+--------+

                Figure 5: Standard IEEE 802.1Q Frame Format

   The TAG protocol Identifier (TPID) is a 16-bit length field which is
   set a value of 0x88a8 to identify the frame as an IEEE 802.1ad tagged
   frame. The TAG Control Information (TCI) is a 16-bit length field.





D.P. GELS                Expires - July 2006                 [Page 9]


Solution Decoder and Analysis for GELS                        Feb 2006


   In this technique, the Ethernet label is encoded in the TCI field of
   the S-VLAN TCI (see Figure 6). The length of the Ethernet label is 12
   bits providing for a label space of 4k values per link.

   S-VID translation is used in this technique. S-VID processing is
   supported on most Ethernet switches. MAC address learning may be
   inhibited, depending on the behavior of the forwarding entity.

   Figure 6 depicts the S-VLAN TAG Control Information (TCI)

                    Oct:  1               2
                         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         | PCP |D|       VID             |
                         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    bit:  8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

                           Figure 6: TCI Format

   The Priority Code Point (PCP) is a 3-bit length field, which is used
   to convey priority and drop eligibility parameters. This 3-bit field
   refers to the 802.1p priority.

   The PCP can be used in order to encode DiffServ parameters assuring
   the DiffServ support for Ethernet LSP.  In other words can be used as
   the EXP filed of the MPLS shim header.

   The D bit (1 bits) is the Drop Eligible Indicator (DEI) bit.

   The VLAN Identifier (VID) is a 12-bit length field uniquely
   identifying the VLAN to which the frame belongs. Its value can be
   between 0 and 4.095.

3.1.2 Functional Behavior

   When a frame/packet enters an ingress PE via a CE-PE interface, the
   PE processes the incoming traffic flow by performing a number of pre-
   processing operations on the frame. The pre-processing operations may
   include, for example, VID translation, VID insertion/stripping, etc.
   These operations are beyond the scope of this document.

   The pre-processed frame is then presented to the ingress E-LER
   function. The latter takes an incoming pre-processed frame, if
   necessary adapts it to an Ethernet frame, adds an Ethernet label and
   forwards it via the appropriate label-controlled interface over a
   Ethernet point-to-point or point-to-multipoint LSP.

   Throughout the GMPLS-controlled Ethernet network, Ethernet LSRs
   switches labeled Ethernet frames via the appropriate interface based
   on the ingress port and the S-VID Ethernet label, which is encoded in


D.P. GELS                Expires - July 2006                [Page 10]


Solution Decoder and Analysis for GELS                        Feb 2006


   the standard IEEE 802.1 frame header. The switching operation
   replaces the S-VID Ethernet label before the frame is transmitted.
   Frames that are received with an unknown S-VID Ethernet label are
   silently discarded. The forwarding decision is based on the
   information residing in the FIB. This table may be configured by the
   GMPLS control plane.

   The egress E-LER terminates the Ethernet LSP by removing the S-VID
   label from incoming frames received on a label-controlled interface,
   if necessary extracts the payload, and presents the frame for
   appropriate post-processing operations. Post-processing may include,
   for example, VID translation, VID insertion/ stripping, etc. These
   operations are beyond the scope of this specification. The frame is
   then appropriately forwarded towards its destination via the
   appropriate label-controlled interface.

   The S-VID Ethernet label is part of the Ethernet MAC frame header and
   has link local scope. The same S-VID Ethernet label can be reused on
   different interface. The coding of the S-VID Ethernet label does not
   modify the format of the standard Ethernet frame, although it may add
   new semantics to one or more fields. No modification is made to the
   layers over which the Ethernet payload may be transmitted.

   The S-VID Ethernet labels are assigned and interpreted locally and
   have local significance. This does not preclude the assignment of the
   same S-VID Ethernet label value by consecutive hops. The S-VID
   Ethernet labels can be used for the establishment and the support
   of Ethernet LSPs over multiple domains and for the support of point-
   to-multipoint Ethernet LSPs) to carry Ethernet multicast traffic.

   End-to-end Ethernet connectivity can be used to provide any service
   that is supported by standard Ethernet. These services are mapped in
   the Ethernet LERs to an appropriate Ethernet LSP. The Ethernet frame
   is extended with the S-VID Ethernet label when it is sent over the
   Ethernet LSP. With Ethernet services, the C-VID (included in the C-
   TAG) may, as an option, be transmitted transparently over the
   Ethernet LSP (i.e. preserved over the network), depending on the
   service definition.

3.1.3 Control Plane

   GMPLS signaling is used to configure the S-VIDs along the nodes
   traversed by the Ethernet point-to-point or point-to-multipoint LSP.

   The idea behind this solution is to prevent the control plane from
   dealing with any MAC address space specifics such as to ensure
   independence and transparency to the data plane addressing specifics.
   GMPLS is used to configure the 12-bit S-VID label during Ethernet LSP
   provisioning.


D.P. GELS                Expires - July 2006                [Page 11]


Solution Decoder and Analysis for GELS                        Feb 2006



   This results in a straightforward re-use of the GMPLS unified control
   plane and TE mechanisms. Indeed, an Ethernet LSR behaves as any other
   LSR currently manageable by a GMPLS-based control plane.

   This technique may coexist with Ethernet bridging in the same network
   or on the same network element. On the same port, GMPLS controlled
   Ethernet label switching method and Ethernet bridging may coexist as
   long as the S-VID space is configurable (to discriminate between the
   switching and bridging ranges). A future work will be undertaken to
   automate this configuration process using RSVP-TE protocol (for inst.
   by extending the capability of the label set object).

3.2 Stacked VLAN TAGs (QinQ) Translation

3.2.1 Label Encoding

   Figure 7 depicts the format of the IEEE 802.1ad Ethernet frame with
   Stacked VLAN TAGs (QinQ).

                            S-TAG     C-TAG
                          --------   -------
                         /        \ /       \
   +----------+----------+----+----+----+----+----+---------------+---+
   |          |          |    |    |    |    |    |               |   |
   | MAC Dest |  MAC Src |TPID|TCI |TPID|TCI |LEN\|    Payload    |FCS|
   |  Address |  Address |    |    |    |    |Type|               |   |
   |          |          |    |    |    |    |    |               |   |
   +----------+----------+----+----+----+----+----+---------------+---+

         Figure 7: Standard IEEE 802.1ad Format with Stacked VLAN.

   In this technique the concatenation of the S-VID (i.e. the VID of the
   S-TAG) and the C-VID (i.e. the VID of the C-TAG) is used as the
   Ethernet label, resulting in a unique 24-bit length label.

   This technique makes use of VID translation. Neither MAC learning nor
   flooding for the range of VIDs are required.

3.2.2 Functional Behavior

   The Stacked VLAN TAG translation functional behavior is the same as
   the S-VID translation functional behavior (see Section 3.1.1), except
   for the label space, which is wider (24 bits). For details about the
   functional behavior, refer to section 3.1.1 above, replacing the term
   'S-VID Ethernet label' with the term 'Stacked VLAN TAG Ethernet
   label'. In cases where the 4.096 link local S-VID label space is too
   small, the stacked VLAN Ethernet label can be used.



D.P. GELS                Expires - July 2006                [Page 12]


Solution Decoder and Analysis for GELS                        Feb 2006


   Note that when the stacked VLAN Ethernet label is used for the
   Ethernet LSP, only a small address range belonging to the outer VLAN
   tag has to be assigned to the GMPLS-controlled Ethernet Label
   switching. The available VLAN range for bridging services is
   therefore hardly affected, while the GMPLS-controlled Ethernet Label
   switching can use the full address range of the inner tag.

3.2.3 Control Plane

   The idea behind this solution is to prevent the control plane from
   dealing with any MAC address space specifics such as to ensure
   independence and transparency to the data plane addressing specifics.
   GMPLS is used to configure the 24-bit label during Ethernet LSP
   provisioning.

   This results in a straightforward re-use of the GMPLS unified control
   plane and TE mechanisms. Indeed, an Ethernet LSR behaves as any other
   LSR currently manageable by a GMPLS-based control plane.

3.3  Concatenated VID/MAC Domain-wide labels

3.3.1 Label Encoding

   In this technique, the concatenation of the VID (encoded in the TCI
   immediately following the DA and SA MACs) and the Destination MAC
   Address (DA MAC) is used as the Ethernet label, resulting in a unique
   60-bit label. The VID can be a Q-TAG (Ethertype for TCI=0x8100), a
   802.1ad S-TAG (Ethertype for TCI=0x8a88) or a 802.1ah B-TAG
   (Ethertype TBD) depending on the network context. This technique
   provides for a private sub-network labeling solution as the MAC
   address space is "sub-network specific". This solution mandates
   enforcement of unicast only traffic exchange for the specified (pre-
   configured) VID range.

   In order to use the unique 60-bit label, the normal mechanisms by
   which Ethernet populates the forwarding table for the allocated range
   of VIDs should be disabled, for example, MAC learning and flooding
   are disabled for an allocated VID range, blocking is disabled, etc.
   GMPLS is used to configure the 60-bit label. The control plane is
   required to ensure loop freeness for the LSPs.

   Note that having a label encoding technique which uses a network wide
   label space definition requires that the support of the whole network
   in this technique, even in case of multiple domains.

3.3.2 Functional Behavior

   Invariant VID/MAC domain-wide labels are proposed such as to enable
   reuse the IEEE 802.1 compliant hardware and forwarding and provide


D.P. GELS                Expires - July 2006                [Page 13]


Solution Decoder and Analysis for GELS                        Feb 2006


   VLAN independent point-to-point LSPs. Aspects of the profile used
   are:

   1) That the ether-relay filter database (forwarding tables) can be
   configured with static entries by a management system or control
   plane
   2) That static entries are not tied to any internal forwarding
   identifier (FID) or spanning tree
   3) That Ethernet LSRs may be VLAN partitioned such that a unique
   topology per VLAN is possible a.k.a. independent VLAN learning (IVL)
   4) The ability to disable MAC learning by VLAN ID
   5) The ability to disable spanning tree by VLAN ID
   6) The MAC addressed interfaces in the Ethernet frame header are
   provider owned addresses and not related to customer MAC
   terminations.
   7) The VLAN ID space is the provider administered VLAN ID space

   A pre-provisioned portion of the VLAN ID set (referred to as the
   connection-oriented Ethernet VLAN ID subset) is decoupled from the
   IEEE 802.1 spanning tree, and the use of the VIDs in this subset is
   confined to unicast forwarding to guard against configuration errors
   such that any loop free constraint for the connection-oriented
   Ethernet VLAN ID subset has been removed. This  subset is available
   across the whole GMPLS-controlled Ethernet domain. The topology for
   each of the delegated VIDs corresponds to the complete physical mesh
   of the Ethernet subnetwork, and unique connectivity instance (P2P or
   MP2P multiplex) to each MAC address is possible per VID.

   One way to think of the meaning of a VID out of the pre-provisioned
   VLAN ID subset is as an instance identifier for unique connectivity
   to the specified MAC. This permits a plurality of uniquely routed
   paths up to the connection-oriented Ethernet VLAN ID subset size to
   any given MAC. Although VIDs are nominally thought of as global
   identifiers for a VLAN, for the purposes of labeled Ethernet frame
   forwarding, they behave as single modifiers bound to the destination
   MAC address. Since MAC addresses are unique with in the scope of the
   connected network, the VID-MAC tuple becomes a unique 60-bit label
   that can be destination administered (see Label Encoding).

   The ability to multiplex paths traveling to the same destination is a
   desirable property to conserve forwarding state. This creates MP2P
   connectivity as a tree of P2P connections rooted at a destination.
   These multiplexed paths share a common VID-DA-MAC tuple yet retain
   the identity of the source due to the inclusion of the SA-MAC. The
   SA-MAC may be interpreted at the end of the path for additional
   operations or when capturing packets at other points on the paths.
   This is a useful property from the point of view of OAM fault and
   performance management at the expense of performing SA-MAC address
   lookup on a per-interface basis.


D.P. GELS                Expires - July 2006                [Page 14]


Solution Decoder and Analysis for GELS                        Feb 2006



   This technique is designed such as to relax a number of constraints
   for the routing of MP2P connectivity:
   - maintains the Ethernet encoding of priority information per-packet
   permitting an Ethernet analogy to E-LSPs
   - requires uni-directional paths which share the same physical
   resources but allows independent VID assignments.
   - allows resource reservation independently in both directions.

   Provisioned LSPs are identified from originating to terminating
   provider MAC interface. The service offered to the end points of an
   Ethernet "connection" configured as outlined above is the ability to
   transport any payload that can be identified via Ethernet LLC
   multiplexing. A non exhaustive list would be:
   -  client Ethernet MAC frames (802.1ah, under IEEE 802.1 definition)
   -  MPLS
   -  IP, IPX, etc.

   This technique mandates enforcement of unicast only traffic exchange
   for the specified (pre-configured) VID range. Meaning that server
   layer multicast replication of client multicast traffic is not
   supported, although client multicast traffic may still be
   encapsulated and transported P2P using this technique.

3.3.3 Control plane

   GMPLS is used for the control of the point-to-point paths. We
   recognize the requirement for a single control plane to manage the
   point-to-multipoint paths as well (for multicast traffic). However
   such objective is outside the scope of this document.

   Using this label encoding technique, a portion of the VLAN ID space
   in an IVL capable switch is delegated to a control or management
   plane. The control plane is used to directly populate the filter
   database with (VID)-(DA-MAC)-(egress port) tuples to configure
   unicast forwarding of Ethernet frames. A given (VID)-(DA-MAC) tuple
   resolving to a single egress port on a Ethernet LSR, and a connection
   being composed of a contiguous set of Ethernet LSRs configured this
   way.

   The goal of bringing the work to the IETF is to use GMPLS as the
   unified GMPLS control plane for point to point LSPs.  GMPLS can take
   the role of the control plane that populates the Ether-relay filter
   database. The following GMPLS extensions are foreseen for GMPLS
   support:
   -  use of the upstream label object to establish bi-directional paths
   -  optional use of suggested label
   -  use of the association object for signaling of protection switched
   paths


D.P. GELS                Expires - July 2006                [Page 15]


Solution Decoder and Analysis for GELS                        Feb 2006


   -  definition of a new label object C-type for the VID-MAC tuple
   label

4. Comparison

   Two techniques are currently proposed as solutions for the GELS,
   VID/DA MAC switching (using VID/DA MAC domain wide invariant labels)
   and VID switching (using VID/stacked VID link local labels).

   The former (see Section 3.3) makes use of a 60-bit domain-wide label
   which is built from the concatenation of the 48-bit destination MAC
   address of the provider edge node (DA B-MAC) and the 12-bit provider
   VID (B-VID). This solution is referred to as solution 1.

   The latter (see section 3.1 and 3.2) makes use of one of the
   following local labels: the 802.1ad 12-bit S-VID, and the 24-bit
   label which is created from the 802.1ad stacked VLAN (Q-in-Q). The
   characteristics of a domain-wide label and of a local scope label are
   described and analyzed in the GELS framework. This solution is
   referred to as solution 2.

   This section attempts to examine, analyze and compare the candidate
   solutions which are described in Section 3 according to the criteria
   listed in Section 2. Note that for both techniques, the analysis and
   comparison assume the use of GMPLS for enabling the provisioning and
   maintenance of the Ethernet LSPs, in both techniques.

   Note also that the third solution class (MAC-only labels) may be
   considered in future version of this document.

4.1 Ethernet P2P and P2MP TE LSPs

   Both solutions provide for Connection Oriented Ethernet. In both
   techniques the network is pre-configured with the connections and the
   resources are allocated and preserved. In both techniques the traffic
   flow is identified by a connection identifier (label).

   Solution 1 handles unidirectional and bi-directional point-to-point
   Traffic Engineered Ethernet LSPs. However, it does not handle
   unidirectional point-to-multipoint Traffic Engineered Ethernet LSPs.
   The VID space is dedicated to unicast purposes due to the IVL
   capability, which is based on unicast forwarding corroding to the B-
   VID/B-MAC tuple. Note that while in general, VID spaces should be
   independent of the type of the traffic, here, the VID dedicated space
   is enforced for unicast purposes. So, multicast traffic support is to
   provided by the legacy connectionless Ethernet forwarding.





D.P. GELS                Expires - July 2006                [Page 16]


Solution Decoder and Analysis for GELS                        Feb 2006


   Solution 2 handles unidirectional and bi-directional point-to-point
   Traffic Engineered Ethernet LSPs and unidirectional point-to-
   multipoint Traffic Engineered Ethernet LSPs.

   Both solutions enable Traffic Engineering to optimize the network
   resource usage.

4.2 Ethernet LSP Merging and LSP Multiplexing

   In Solution 1 due to the nature of the label which is constructed
   from the DA B-MAC address and the B-VID, connections may be
   multiplexed along the way to the destination. However, due to the
   label structure there is no possibility to avoid data plane merging
   that violates the end-to-end guaranteed BW per LSP. Although the
   Ethernet encoding of priority information is reserved per-packet, the
   end-to-end guaranteed bandwidth for a specific LSP can be violated
   and used by other LSPs multiplexed into the same path (for example
   with higher priority packets). In order to avoid Ethernet LSP
   multiplexing and in order to guarantee end-to-end bandwidth per LSP a
   different label should be assigned to each LSP (e.g. either a
   different DA B-MAC address should be assigned to each LSP or a
   different B-VID should be assigned to each LSP).

   Solution 2 provides end-to-end QoS with guaranteed bandwidth and
   controlled jitter and delay based on the service definition to
   enforce the SLA. Solution 2 provides a simple method for
   multiplexing: each Ethernet LSR should assign a unique label to each
   particular source (label assigned on a per sender basis).

4.3 Services

   In Solution 1, frames are mapped at the Ethernet LER to LSPs
   according to the port on which the frames were received or according
   to the outer VID.

   In Solution 2, frames are mapped at the Ethernet LER to LSPs
   according to the port on which the frames were received and the VID
   of the outer VID.

   Both solutions are capable to provide any connectivity service that
   is supported by standard Ethernet encapsulation (such as IP/MPLS,
   TDM, etc.).

   The solutions are positioned as follows for what it concerns service
   provisioning and maintenance:

   o) In Solution 1, a pool of unique MAC addresses and a range of VIDs
   should be configured at the provider Ethernet LER. LERs should also
   manage VID/MAC address relation. The label has a domain wide


D.P. GELS                Expires - July 2006                [Page 17]


Solution Decoder and Analysis for GELS                        Feb 2006


   significance. Any modification to a label or addition of a new label
   is circulated across the network.

   In Solution 2, only a range of VIDs that should be used for switching
   purposes technique should be configured at each Ethernet LSR. When an
   Ethernet LSP is provisioned across the network, each node along the
   path arbitrarily allocates a free label for the LSP. The label has
   only link local significance.

   o) Both solutions provide network trunks (nesting LSPs) in order to
   simplify the delivery of services across the network. Theoretically
   the number of services that may be transmitted within the tunnels is
   unlimited.

   o) Both solutions employ OAM and provide a means to minimize the
   number of LSPs to be monitored. Only network trunks should be
   actively monitored. Services may be monitored according to specific
   service requirements.

   With Solution 2 (12-bit), up to 4K tunnels may be provisioned per
   port. Within each port up to 4K services can be delivered. With
   Solution 2 (24-bit), up to 16M tunnels may be provisioned per port.
   Other combinations are possible as well. Using this solution, LSPs
   can also be used to deliver services (with no tunneling). This
   capability has a benefit in particular network scenarios, where there
   is no need for the overhead of tunnel provisioning and superfluous
   encapsulation.

4.4 OAM

   Solution 1 requires unicast CC OAM messages which are currently not
   defined or implemented. Moreover, when using this solution, the SA-
   MAC can be captured at intermediate Ethernet LSRs or at the egress
   Ethernet LER to detect misconnectivity where traffic from one LSP is
   leaked into another LSP. Note that misconnectivity can occur due to
   misconfigurations.

   Solution 2 enables the support of OAM (IEEE 802.1ag) messages, to
   ensure the correct operation of the network. CC OAM frames are
   transmitted within the LSP and will reach their destination. Each LSP
   is identified by an end-to-end connection identifier (5-tuple). The
   customer's information may be interpreted to detect misconnectivity.
   OAM messages are sent along the path to detect failures or problems
   in the network.

4.5 Resiliency

   Both Solutions provide mechanisms for matching the sub 50 ms failover
   times required for maintaining time-bounded services.


D.P. GELS                Expires - July 2006                [Page 18]


Solution Decoder and Analysis for GELS                        Feb 2006



   Due to the domain-wide nature of the label used in Solution 1,
   certain recovery mechanisms that are provided by the GMPLS can not be
   applied in case of domain-wide VID/MAC label (e.g. 1:1 fast reroute
   which apply two different labels for the protected and the detour
   LSPs, etc.).

   In case of LSPs over multiple domains (i.e. inter-domain), Solution 1
   can not protect against a failure of an edge node (which connects to
   other domains). This is true for each of the three recovery
   techniques (unless dual homing is supported, but this complicated
   solution should be proven to work).

   Solution 2 supports all three LSP recovery techniques: global (end-
   to-end), segment and local. This solution provides mechanism to
   protect against any failure in the network (including failure of
   boundary nodes in case of an inter-domain operation).

4.6 Inter-domain

   Both solutions enable the provisioning Ethernet LSPs across multiple
   domains (inter-domain). Both techniques support the peering and the
   client/server interconnection modes.

   In Solution 1, when peering is supported, the network trunk is
   terminated at the edge of a domain. The services may be processed
   according to one of the following VIDs: C-VID, or S-VID or I-SID. The
   I-SID may be translated to S-TAG, limiting to 4094 service instances
   across an E-NNI. It may be translated to a DMZ value, limiting to
   2**24 service instances across an E-NNI. In any case, note that as
   the 802.1ah is not final yet, the I-SID processing is not defined.

   The [CCAMP-ID-FRM] defines three options for signaling TE LSPs across
   multiple domains, as follows: LSP nesting (client/server mode),
   contiguous LSP (peering mode) and LSP stitching (peering mode).

   In Solution 1, the contiguous LSP option will probably not be
   supported because of the domain-wide nature of the label. If
   supported, the carriers' would have to offer each other globally
   unique label. In such a case, the label would come from each
   carrier's administrative space (MAC address of the terminating
   interface).

   In Solution 2, all the three signaling options are supported.

4.7 Scalability

4.7.1 MAC Address



D.P. GELS                Expires - July 2006                [Page 19]


Solution Decoder and Analysis for GELS                        Feb 2006


   Both solutions disable MAC learning for the VID range that is
   supported for connection-oriented Ethernet purposes. Thus, the flush
   FIB operation associated with topology change and flooding
   operations, which leads to slow recovery and convergence, is
   eliminated.

   The switching operation in both techniques is independent of the
   destination subscriber MAC address.

4.7.2 VLAN ID (VID)

   In Solution 1, the VID in conjunction to the DA B-MAC is used as
   domain-wide label. As specified above, in order to avoid the LSP
   multiplexing and guarantee end-to-end BW per LSP, a different label
   should be assigned to each LSP. Hence, either a different B-VID or a
   different DA B-MAC address should be assigned to each LSP between a
   particular pair of source and destination Ethernet LERs. In case of a
   different DA B-MAC address, it requires the provisioning of a pool of
   MAC addresses per pair (source and destination) of Ethernet LERs
   dependent on the required number of LSPs that should be provisioned
   between this pair of Ethernet LERs. In case of a different B-VID, it
   violates the VLAN scalability. The space of the VID is limited per
   node and a certain range of VIDs should be assigned to the bridging
   function (in order to provide for example multicast services, etc.).

   In Solution 2, the VID label has link local significance and can be
   reused on different interface (per interface label spaces similar to
   ATM’s VCI/VPI or MPLS’s label space). The label space can reach a
   maximum of 4K VIDs per port if the 12_bit S-VID labels is used and a
   maximum of 16M VIDs if 24-bit labels are used.

4.7.3 Ethernet Frame Switching

   Both solutions do not rely on the customers' destination MAC
   addresses.

4.7.4 Label

   Both solutions encode the Ethernet label as part of the Ethernet MAC
   frame header.

   Solution 1 makes use of the 802.1ah frame format: 48 bits SA B-MAC
   address, 48 bits DA B-MAC address, 32 bits B-TAG and 24-bit I-SID.
   The label being a combination of the DA B-MAC and the B-VID is 60-
   bits long.

   Solution 2 makes use of the 802.1ad frame format. This requires a 32-
   bit S-TAG to encode the S-VID label or 64-bit S-TAG + C-TAG to encode
   the extended the 24-bit label (composed by the S-VID and C-VID).


D.P. GELS                Expires - July 2006                [Page 20]


Solution Decoder and Analysis for GELS                        Feb 2006



   In solution 1, the label space has a 60-bit length and has a domain
   wide significance. The implication on the number of LSPs that can be
   provisioned in the network is not trivial. Theoretically, this number
   is 2^60. Practically, this requires a tedious provisioning effort.
   Depending on the connectivity, a varying set of MAC addresses should
   be manually configured.

   In solution 2, the number of LSPs that can be provisioned depends on
   the label type. With S-VIDs, up to 4K LSPs per port can be
   provisioned. With 24-bit labels up to 16M LSPs per port can be
   provisioned.

   In addition, the label length and space size also affects the
   implementation of the FID's lookup table. In Solution 1, the key to
   the lookup table is 60-bits long. In Solution 2, it is either 12-bits
   or 24-bits long.

4.7.5 LSP Hierarchy

   TBD.

4.8 Backward compatibility with IEEE 802.1

   Both label encoding techniques make use of the structure of the
   standard IEEE 802.1 Ethernet frame. Both solutions do not modify the
   format of the standard Ethernet frame, but do add new semantics to
   one or more fields.

4.9 Applicability

   1) Metro access and Metro aggregation networks

   The Metro access and the metro aggregation networks by nature are
   small networks which are characterized by having a small number of
   nodes deployed at the network. The role of that metro access/metro
   aggregation network is to provide connectivity between a user and a
   service platform (e.g. BRAS, edge router, etc.).

   Employing Solution 1 in such environment adds a lot of overhead in
   the network (e.g. MAC encapsulation), and increases CAPEX, without
   apparent benefits. The idea behind this solution is to increase CAPEX
   at the edge of the network in order to reduce CAPEX at the core of
   the network. In typical Metro access/Metro aggregation networks there
   are hardly any core routers (if at all) while there are many edge
   nodes.

   In addition, both DSLAMs and BRAS do not handle IEEE 802.1ah frames.
   They are only capable of extracting/adding one or two VLAN TAGs. It


D.P. GELS                Expires - July 2006                [Page 21]


Solution Decoder and Analysis for GELS                        Feb 2006


   is thus appropriate to make use of these VLAN TAGs and perform VID
   switching using the same encapsulation than those provided by the
   DSLAM and the BRAS. Solution 2 is more appropriate for residential
   services, where the BRAS handle the two VLAN TAGs, which identify the
   customer. Hence, Solution 2 is more suitable for metro access/metro
   aggregation networks than Solution 1.

   2) Metro-core

   The metro core is a larger network and its role is to connect several
   metro access/metro aggregation networks.

   Both Solutions can be deployed at the metro-core networks. Both
   provide connection-oriented Ethernet with tunneling mechanisms. The
   selection of the specific technique that should be deployed should be
   based on the solution analysis described in this document.

   3) Core and Transport networks

   Same observation as for Metro-core applies.

4.10 Security

   In both techniques the number of network entry points is reduced.
   Policing and filtering are provided on the provider edge nodes. Some
   mechanisms may be provided at the network edges to rate limit the
   amount of traffic that can be transmitted into a given Ethernet LSP.

   Solution 1 switches on MAC addresses hence mandating the use of MAC-
   in-MAC encapsulation to resolve issues associated with MAC addresses.

   Solution 2 inherently eliminates security issues on MAC addresses
   (MAC spoofing and MAC attack) because it is agnostic to MAC
   addresses.

   Both solutions eliminate security issues associated with VLAN TAGs.
   At the provider edge, customers are attached to the provider network
   via particular VLANs on a particular port. Frames with other VLANs
   will be blocked. Across the network, only the VLAN Identifier(s)
   added by the provider edge node is/are inspected. Any other nested
   VLAN has no meaning across the provider network.

5. Conclusion

   The proposed solutions have been analyzed and compared according to
   the criteria, which were defined for this purpose.





D.P. GELS                Expires - July 2006                [Page 22]


Solution Decoder and Analysis for GELS                        Feb 2006


   According to the analysis, the solution that better complies to the
   GELS requirements, as well as better addresses the GELS motivations
   and objectives should be identifiable.

   It may be that different solutions have to be selected for example to
   satisfy different network scenarios or/and different applications. In
   such a case, a specific label encoding technique should be selected
   according to the capability of the GMPLS-enabled Ethernet network
   element and/or the capability of the label-controlled Ethernet
   interface. Hence, leaving the possibility for adopting different
   solutions for GELS. It may also be that the solutions complement each
   other, and for example should be deployed in different network areas.

   In any case, it is recommended that the GELS define an extensible
   solution which will leave room for future definitions, especially
   since the Carrier Grade Ethernet solution is currently under
   investigation by service providers.

   Please comment on the <gels@rtg.ietf.org> mailing list.

7. References

7.1.  Normative References

   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3209]       Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
                   V., and G. Swallow, "RSVP-TE: Extensions to RSVP
                   for LSP Tunnels", RFC 3209, December 2001.

   [RFC3477]       K.Kompella et al. "Signalling Unnumbered Links in
                   Resource ReSerVation Protocol - Traffic Engineering
                   (RSVP-TE)", RFC 3477, January 2003.

   [RFC3630]       D.Katz et al. "Traffic Engineering (TE) Extensions to
                   OSPF Version 2", RFC 3630, September 2003.

   [RFC3784]       H.Smit and T.Li, "Intermediate System to Intermediate
                   System (IS-IS) Extensions for Traffic
                   Engineering (TE)," RFC 3784, June 2004.

   [RFC3471]       Berger, L., "Generalized Multi-Protocol Label
                   Switching (GMPLS) Signaling Functional Description",
                   RFC 3471, January 2003.

   [RFC3473]       Berger, L., "Generalized Multi-Protocol Label
                   Switching (GMPLS) Signaling Resource ReserVation
                   Protocol-Traffic Engineering (RSVP-TE) Extensions",


D.P. GELS                Expires - July 2006                [Page 23]


Solution Decoder and Analysis for GELS                        Feb 2006


                   RFC 3473, January 2003.

   [RFC3945]      Mannie, E., "Generalized Multi-Protocol Label
                  Switching (GMPLS) Architecture", RFC 3945, October
                  2004.

7.2.  Informative References

   [MRN-REQ]      K.Shiomoto et al., "Requirements for GMPLS-based
                  Multi-Region Networks (MRN)", Work in Progress, draft-
                  ietf-ccamp-gmpls-mrn-reqs-00.txt.

8. Acknowledgments

9. Author's Addresses

   Dimitri Papadimitriou
   Alcatel
   Francis Wellesplein 1,
   B-2018 Antwerpen, Belgium
   Phone: +32 3 2408491
   Email: dimitri.papadimitriou@alcatel.be

   Nurit Sprecher
   Siemens AG (Seabridge Networks)
   3 Hanagar St. Neve Ne'eman B
   Hod Hasharon, 45241 Israel
   Email: nurit.sprecher@seabridgenetworks.com

   Jaihyung Cho
   Electronics and Telecommunications Research Institute (ETRI)
   161 Gajung-dong, Yuseong-gu
   Daejeon 305-350, Korea
   Phone: +82 42 860 5514
   Email:  jaihyung@etri.re.kr

   Loa Andersson
   Acreo AB
   Email: loa@pi.se

   Attila Takács
   Traffic Lab, Ericsson Research
   Ericsson Hungary Ltd.
   Laborc 1.
   Budapest, Hungary, H-1037
   Email: attila.takacs@ericsson.com


   Don Fedyk


D.P. GELS                Expires - July 2006                [Page 24]


Solution Decoder and Analysis for GELS                        Feb 2006


   Nortel Networks
   600 Technology Park
   Billerica, Massachusetts
   01821 U.S.A
   Phone: +1 (978) 288 3041
   Email: dwfedyk@nortel.com

   Dave Allan
   Nortel
   3500 Carling Ave.
   Ottawa, Ontario
   K1Y 4H7
   Phone: (613) 763-6362
   Email: dallan@nortel.com





































D.P. GELS                Expires - July 2006                [Page 25]


Solution Decoder and Analysis for GELS                        Feb 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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.

   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.


Intellectual Property

   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 ietf-
   ipr@ietf.org.











D.P. GELS                Expires - July 2006                [Page 26]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/