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

Versions: 00 01

Network Working Group                                       L. Andersson
Internet-Draft                                                  Acreo AB
Expires: April 24, 2006                                 D. Papadimitriou
                                                                 Alcatel
                                                        October 21, 2005


Use of the Gnerealized Multi-Protocol Label Switching control plane for
                point-to-point Ethernet Label Switching
                  draft-andersson-gels-bof-prep-01.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.

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

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document proposes starting a work within the IETF to apply the
   Generalized Multi-Protocol Label Switching (GMPLS) control plane to
   Ethernet Label Switching and to make extensions to the GMPLS control
   plane protocols as necessary for this application.  This will be done
   based on the protocols developed by the MPLS and CCAMP working groups
   in the IETF.  Ethernet Label Switching will use the data plane



Andersson & Papadimitriou  Expires April 24, 2006               [Page 1]


Internet-Draft          Ethernet Label Switching            October 2005


   encodings as specified by the IEEE 802 standards.

   This document intends to gather the information necessary to have a
   "GMPLS Ethernet Label Switching" BoF in Vancouver.

   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 [RFC2119].


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Objectives and scope . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Objectives . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.3.  Out of Scope . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Description  . . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.2.  Core Ethernet  . . . . . . . . . . . . . . . . . . . . . .  9
     3.3.  Ethernet transport . . . . . . . . . . . . . . . . . . . .  9
     3.4.  Ethernet Label Switching Concepts  . . . . . . . . . . . . 10
       3.4.1.  Modeling concepts  . . . . . . . . . . . . . . . . . . 10
       3.4.2.  Deployment concepts  . . . . . . . . . . . . . . . . . 10
       3.4.3.  Packets and Frames . . . . . . . . . . . . . . . . . . 11
       3.4.4.  Ethernet Labels  . . . . . . . . . . . . . . . . . . . 11
       3.4.5.  IEEE 802.1Q terminology  . . . . . . . . . . . . . . . 14
     3.5.  Related work in IETF . . . . . . . . . . . . . . . . . . . 15
       3.5.1.  RFC 3032 (MPLS over Ethernet)  . . . . . . . . . . . . 15
       3.5.2.  RFC 3916 (Ethernet over Pseudo-Wire (PW))  . . . . . . 16
       3.5.3.  TRILL Approach . . . . . . . . . . . . . . . . . . . . 16
       3.5.4.  Positioning of Ethernet Label Switching  . . . . . . . 17
   4.  General requirements . . . . . . . . . . . . . . . . . . . . . 19
   5.  Data plane . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     5.1.  Data plane requirements  . . . . . . . . . . . . . . . . . 20
     5.2.  Relationship to IEEE 802 . . . . . . . . . . . . . . . . . 20
   6.  Control Plane  . . . . . . . . . . . . . . . . . . . . . . . . 22
     6.1.  Control Plane requirements . . . . . . . . . . . . . . . . 22
       6.1.1.  Link management requirments  . . . . . . . . . . . . . 22
       6.1.2.  Routing requirements . . . . . . . . . . . . . . . . . 22
       6.1.3.  Signalling requirements  . . . . . . . . . . . . . . . 22
       6.1.4.  Control channel requirements . . . . . . . . . . . . . 22
     6.2.  Cooperation with CCAMP WG  . . . . . . . . . . . . . . . . 22
     6.3.  Cooperation with other Working Groups  . . . . . . . . . . 23
       6.3.1.  Common review  . . . . . . . . . . . . . . . . . . . . 23
       6.3.2.  Working groups . . . . . . . . . . . . . . . . . . . . 23



Andersson & Papadimitriou  Expires April 24, 2006               [Page 2]


Internet-Draft          Ethernet Label Switching            October 2005


       6.3.3.  Potential overlap with other working groups  . . . . . 23
   7.  Expected outcome . . . . . . . . . . . . . . . . . . . . . . . 24
     7.1.  Milestones . . . . . . . . . . . . . . . . . . . . . . . . 24
     7.2.  Documents  . . . . . . . . . . . . . . . . . . . . . . . . 24
       7.2.1.  Framework  . . . . . . . . . . . . . . . . . . . . . . 25
       7.2.2.  Routing Extensions . . . . . . . . . . . . . . . . . . 25
       7.2.3.  Signaling Extensions . . . . . . . . . . . . . . . . . 25
       7.2.4.  Routing Applicability  . . . . . . . . . . . . . . . . 25
       7.2.5.  Signaling Applicability  . . . . . . . . . . . . . . . 25
       7.2.6.  OAM features . . . . . . . . . . . . . . . . . . . . . 25
       7.2.7.  Ethernet Label switching MIB . . . . . . . . . . . . . 25
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
     9.1.  Attacks on the Data Plane  . . . . . . . . . . . . . . . . 27
     9.2.  Attacks on the Control Plane . . . . . . . . . . . . . . . 27
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 29
     11.2. Informative References . . . . . . . . . . . . . . . . . . 29
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
   Intellectual Property and Copyright Statements . . . . . . . . . . 32






























Andersson & Papadimitriou  Expires April 24, 2006               [Page 3]


Internet-Draft          Ethernet Label Switching            October 2005


1.  Introduction

   This document proposes that the IETF undertakes a work to extend the
   existing protocols that constitute the Generalized Multi-Protocol
   Label Switching (GMPLS) control plane in such a way that this control
   plane may be used for Ethernet Label Switching.

   It also proposes that the extension of the GMPLS control plane SHALL
   be done is such a way that it is possible to create a multi-layer
   network dynamically controlled by a common control plane.  For the
   scope of this document at least one of the layer must be Ethernet,
   but a there is nothing that precludes that the same approach is used
   in non-Ethernet networks.

   The information collected in this document is intended for an
   "Ethernet Label Switching" BoF in Vancouver at the 64th IETF.  During
   this BOF we seek consensus for one of two alternatives:

   1.  that a new working group is started to undertake the work
       described here

       or

   2.  that the work we describe here is allocated to an existing
       working group

   The MPLS and CCAMP working groups have defined the use of MPLS and
   GMPLS protocols for control of several L2 technologies, e.g.  ATM and
   FR, and for circuit-oriented technologies such as SONET/SDH.  This
   has been done by extending the IETF signaling protocols e.g.  RSVP-TE
   and routing protocols e.g.  OSPF and IS-IS while their respective
   data plane has been left unchanged (see e.g.  RFC 3946 [RFC3946]).
   The same approach will be used when extending the GMPLS control plane
   for Ethernet Label Switching.

   However, the choice of how to specify an Ethernet label is not as
   straightforward as for other L2 technologies.  There is no designated
   VPI/VCI information field as in ATM or a DLCI information field as in
   Frame Relay that we can use.  There are however several options that
   can be considered and need to be compared before taking a decision,
   e.g. the Q-tag as specified in IEEE 802.1Q, the I-tag that currently
   is specified in IEEE 802.1ah or if we should go for a new "G-tag"
   ("GMPLS-tag") especially allocated for Ethernet Label Switching.
   This is further discussed in Section 3.4.4.

   Control of Ethernet networks by the control plane technologies as
   specified in GMPLS RFCs has been within the scope of the CCAMP
   working group since the start, at least to the extent that Ethernet



Andersson & Papadimitriou  Expires April 24, 2006               [Page 4]


Internet-Draft          Ethernet Label Switching            October 2005


   is used in transport and core networks (see Section 1.2 of
   [RFC3945]).  Part of this discussion was captured in
   [I-D.papadimitriou-ccamp-gmpls-ethernet-framework].  The work
   proposed in this document could be viewed both as a consolitdation
   and a continuation of the work started in [I-D.papadimitriou-ccamp-
   gmpls-ethernet-framework].













































Andersson & Papadimitriou  Expires April 24, 2006               [Page 5]


Internet-Draft          Ethernet Label Switching            October 2005


2.  Objectives and scope

   This section outlines the objectives and scope of the proposed work
   on Ethernet Label Switching.  A set of high level requirements are
   detailed in Section 4, Section 5.1 and Section 6.1.

2.1.  Objectives

   The objectives for the proposed work are listed below.  The list is
   not intended to be exhaustive, but to catch the major objectives.

   o  The key objective of the proposed work is to enable control of
      point-to-point connectivity through Ethernet networks by the GMPLS
      control plane as standardized by the IETF.  The standards are
      based on the work done in the CCAMP working group.

   o  It is an objective of the proposed work to contribute to the goal
      of making it possible to configure and operate multi-layer
      networks (MLNs).  This type of network is called multi-region
      network (MRN) in [I-D.shiomoto-ccamp-gmpls-mrn-requirements] and
      [I-D.papadimitriou-ccamp-gmpls-mrn-extensions].

   o  It is an objective of the work to build on the work done by other
      working groups within the IETF, in particular, the CCAMP WG.

   o  It is an objective of the proposed work to enable constraint based
      routing and explicit routing.

   o  It is an objective of the work to build on the work done by other
      Standards Developing Organizations (SDO), in particular the IEEE
      802.

   o  It is an objective of the proposed work to use the structure of
      the existing encoding of the Ethernet framing, number of bits and
      size of fields are left unchanged, though the coding of Ethernet
      label may add new semantics to one or more fields.

   o  It is an objective of the proposed work to achieve
      interoperabilitiy with legacy Ethernet switches

   o  It is an objective of the proposed work to retain the legacy
      functionality, e.g.  VLANs of Ethernet switches

   o  It is an objective of the proposed work that switches that are
      GMPLS Ethernet enabled support unlabeled frames






Andersson & Papadimitriou  Expires April 24, 2006               [Page 6]


Internet-Draft          Ethernet Label Switching            October 2005


2.2.  Scope

   o  The scope of the proposed work includes point-to-point (P2P)
      Ethernet LSPs.

   o  Traffic engineered P2P Ethernet LSPs are within scope for the
      proposed work.

   o  The scope of the proposed work includes setting up, removing,
      managing and operating Ethernet LSPs in core and transport
      networks.

   o  Defining format and value space for Ethernet labels (see
      Section 7.2) are within scope for the proposed work.  Support for
      more than one label format is discussed in Section 3.4.4

2.3.  Out of Scope

   o  GMPLS Ethernet LSPs to the customer premises and/or to hosts are
      out of scope for the proposed work.

   o  GMPLS Ethernet Label Switching in access networks is out of scope
      for the proposed work.

   o  GMPLS Ethernet Label Switching in campus networks is out of scope
      for the proposed work.

   o  GMPLS Ethernet Label Switching in mobile and wireless networks is
      out of scope for the proposed work.

   o  Multicast and point-to-multipoint LSPs, both Traffic Engineered
      and non-Traffic Engineered are out of scope for the proposed work.

   o  Changes to the Ethernet data plane are not planned within the
      proposed work.  To the extent such changes are necessary they need
      to be achieved through the mechanisms and methods defined by the
      IEEE.














Andersson & Papadimitriou  Expires April 24, 2006               [Page 7]


Internet-Draft          Ethernet Label Switching            October 2005


3.  Description

   This section includes a brief description of the positioning of
   Ethernet Label Switching, and its relationship with respect to MPLS
   and GMPLS.

   The original MPLS architecture (defined in RFC 3031 [rfc3031] and RFC
   3032 [rfc3032]) has been extended in RFC 3945 [rfc3945] to include
   LSRs whose forwarding plane recognizes neither packet, nor cell
   boundaries, and therefore, cannot forward data based on the
   information carried in either packet, or cell headers.  Specifically,
   such LSRs include devices where the switching decision is based on
   the L2 frame header.  Interfaces on these LSRs recognize frame
   boundaries (i.e. frame delimitation) and can switch data based on the
   content of the MAC frame header.  Such interfaces are referred to as
   Layer-2 Switch Capable (L2SC) interfaces.

   The Ethernet MAC frame header includes the EtherType, the different
   TAGs, and the MAC_DA/SA addresses.  In this context, a GMPLS Ethernet
   labeled frame is defined as an Ethernet MAC frame whose header
   encodes the label value.  Per the GMPLS architecture, a label's
   interpretation depends on the type of the link over which the label
   is used.  Therefore, GMPLS Ethernet switches need be able to
   correctly handle all types of Ethernet MAC frames, including the
   GMPLS labeled frames, to ensure inter-working with 802.1 bridges.  An
   extensive description of label distribution concepts are found in RFC
   3036 [rfc3036].  Ethernetlabel assignment , following the GMPLS
   choicie of signalling protocols RFC 3473 [rfc3473], mandates a
   downstream-on-demand label allocation and distribution, with ingress
   initiated ordered control, see RFC 3945 [rfc3945].

3.1.  Scenarios

   In the CCAMP working a design team was chartered to look into
   different Ethernet GMPLS scenarios.  In the report from the design
   team [I-D.papadimitriou-ccamp-gmpls-ethernet-framework] four
   different scenarios were discussed.  The four different scenarios
   addressed the problem space from very separate starting points.

   While the discussion in this section of what is in and out of scope,
   stricly only applies to the CCAMP working group charter, we have not
   indications that the scope will radically change even if we were to
   take the work to another working group.  It is therefore assumed that
   what is within scope for the CCAMP working group is also within scope
   for any working group working on GMPLS controlled Ethernet, and vice
   versa.

   Scenario 1, GMPLS for access and aggregation networks, were



Andersson & Papadimitriou  Expires April 24, 2006               [Page 8]


Internet-Draft          Ethernet Label Switching            October 2005


   considered to be out of scope.  The reason for this is that the scope
   of the present any work on Ethernet Label Switching needs to follows
   the guidelines in the CCAMP working group charter i.e.  "The CCAMP
   working group coordinates the work within the IETF defining a common
   control plane and a separate common measurement plane for physical
   path and core tunneling technologies of Internet and telecom service
   providers (ISPs and SPs), e.g.  O-O and O-E-O optical switches, ATM
   and Frame Relay switches, MPLS, GRE, in cooperation with the MPLS
   WG."

   It is not that given access and aggregation networks are are
   environments where GMPLS controlled label swtiching is suitable.  An
   assessment of GMPLS applicability in access and aggregation networks
   should be the first step.  Once we have this assessment , given that
   it is positive, a decision if this something IETF wants to undertake
   could be taken.  It is however not within scope for the proposed
   work.

   Scenario 2, GMPLS for Metro and Metro Core networks are within scope,
   but the scenario as described focused on use of the VLAN-id as
   Ethernet label.  For a number of reasons this were considered
   creating a solution before we've addressed the requirements.

   The solution proposed in scenario 2 should be revisisted when a
   solution is discussed, to assess if it is possible and beneficial to
   use, partly use or accomodate the solution proposed for Metro and
   Metro core networks in the approach discussed in this document.

   Scenario 3 and 4 are similar the difference lies more in
   applicability than requirements.  Scenario 3 addresses the case where
   a common control plane is used for all dynamically controlled network
   layers, while scenario 4 addresses transport networks only.  Scenario
   4 might be considered a subset of scenario 3, while scenario 2 could
   be considered a subset of both or either of scenario 3 and 4.

3.2.  Core Ethernet

   Ethernet Label Switching for core Ethernet aligns closely with
   scenario 3 as it was describe in the report from the design team
   [I-D.papadimitriou-ccamp-gmpls-ethernet-framework], i.e. the model
   with a common control plane (common routing and signaling protocols)
   for IP (packet), Ethernet (frame) and optical parts of a network.

3.3.  Ethernet transport

   The Ethernet Label Switching for Transport networks aligns closely
   with scenario 4 as it was describe in the report from the design team
   [I-D.papadimitriou-ccamp-gmpls-ethernet-framework].  This model is



Andersson & Papadimitriou  Expires April 24, 2006               [Page 9]


Internet-Draft          Ethernet Label Switching            October 2005


   limited to scenarios where the Ethernet LSP is carried over circuits
   (e.g.  SDH/Sonet).

3.4.  Ethernet Label Switching Concepts

3.4.1.  Modeling concepts

   When modeling an MPLS network, we talk about two different types of
   nodes, a Label Edge Router (LER) and a Label Switching Router (LSR)
   and the links between them.  In GMPLS controlled Ethernet networks we
   might talk about Ethernet LERs and Ethernet LSRs.

   o  Ethernet LER - an Ethernet LER is a function that can take an
      incoming Ethernet frame and add or remove the Ethernet label.

   o  Ethernet LSR - an Ethernet LSR is a function that can take an
      incoming labeled Ethernet frame and swap the Ethernet label.

   A more comprehensive MPLS terminology is found in RFC 3031 [rfc3031].

3.4.2.  Deployment concepts

   In actual deployments the LER and LSR concepts is not that useful.
   This is because both function could very well be co-located in the
   same "box".

   o  A switch could take an incoming un-labeled packet and switch to an
      interface that is not labeled controlled, i.e. "normal" Ethernet
      switching.

   o  The switch could also take the incoming frame from a non-labeled
      controlled interface (or an Ethernet frame that originates within
      the switch) and switch it to a labeled controlled interface while
      adding the Ethernet label, i.e. the LER function.

   o  The switch could also take the incoming frame from a labeled
      controlled interface and switch it to a non-labeled controlled
      interface while removing the Ethernet label, i.e. the LER
      function.  It is concievable that the non-label control interface
      is an internal interface within the switch and that the frame is
      destined to the switch.

   o  The switch could also take the incoming frame from a labeled
      controlled interface and switch it to a labeled controlled
      interface while swapping the Ethernet label, i.e. the LSR
      function.

   In a deployment an LSP originates on an ingress LSR and terminates on



Andersson & Papadimitriou  Expires April 24, 2006              [Page 10]


Internet-Draft          Ethernet Label Switching            October 2005


   a egress LSR, for point-to-point bi-directional LSPs the same pair
   LSRs acts both as ingress and egress LSRs.

3.4.3.  Packets and Frames

   Multi-layer GMPLS potentially crosses the border between the IP layer
   and the Ethernet layer.  In both layer information encapsulated
   (layer specific information added before and/or after the payload) is
   carried from one node to another.  In Ethernet we talk about such
   entities as "frames" while they are called "packets" in the IP layer.
   Ethernet Label Switching intends to use a label inserted in the
   Ethernet encapsulation.
   Note need to reformulate the last sentence!

3.4.4.  Ethernet Labels

   In this section some of the proposals on how to define an Ethernet
   label are outlined and discussed.  Some of the arguments for and
   against, though it is unlikely that it is exhaustive list, are given.
   It is too early to take a decision, but some alternatives has been
   discussed at some length, e.g. in the L2SC design team and the CCAMP
   working group.

   The proposals listed here are possibly not the only proposals, but at
   least they cover the main ideas that have been discussed.  Two key
   questions that is unresolved is the size of the of the label space,
   and if we need a TTL or not (in a source initiated ordered label
   control assignment using a loop detection mechanism such as the RRO a
   is TTL normally not needed).

   o  use the MPLS shim header

      This approach makes use of the shim header label as specified in
      RFC 3032 [rfc3032].  The good thing is that this is proven to work
      and since we are talking about Ethernet it is always possible to
      introduce a new label stack between the L3 payload and the
      Ethernet encapsulation.  However this would require the Ethernet
      switch to swap, push and pop labels as well as re-write source and
      destination MAC-addresses at each hop.

      When switching on the shim header this is strictly not GMPLS
      controlled Ethernet Label Switching, it is the Label Switching as
      it was defined for the packet part of the network.  In this mode
      of operation the Ethernet frame starts/terminates at each hop, and
      the destination and source address is changed in each hop.

   o  use the Q-tag and switch on the VLAN ID




Andersson & Papadimitriou  Expires April 24, 2006              [Page 11]


Internet-Draft          Ethernet Label Switching            October 2005


      This approach has been discussed over some time.  One argument
      that have been put forward in favor of this approach is that VLAN
      ID processing can be handled by "all" Ethernet switches.  There
      are two drawbacks that has been put forward: the label space is
      relatively small (12 bits) and it makes it impossible to
      simultaneously use normal VLAN IDs in GMPLS controlled Ethernet
      Label Switching networks as the semantic of the VLAN ID is
      modified.
      From a conceptual point of view a VLAN ID is not something an
      Ethernet switch takes a switching decision on, what happens is
      rather that the domain over which the MAC-address learning is done
      is limited (by definition, a VLAN delimits a broadcast domain).  A
      classical Ethernet switch performs MAC address learning using the
      unknown unicast frame forwarding.  When a frame with an Q-tag/VLAN
      ID arrives to a switch over an interface with that VLAN configured
      and the switch doesn't have the destination MAC-address cached,
      that frame will be forwarded (flooded) over all interfaces with
      that VLAN configured.  When the switch sees traffic in the other
      direction coming in over one of the interfaces over which the
      traffic was flooded, the switch learns the combination of source
      address and interface and places it in the MAC-address cache.  As
      long as the MAC-address remains in the MAC-address cache incoming
      frame will be forwarded over a single interface only.
      VLANid is not the switching criteria, but a limitation of the
      switching domain.  The implication is that enabling VLAN ID
      switching would require disabling MAC learning and MAC_DA based
      forwarding.

   o  use a proprietary MAC-address space

      To create unique MAC-addresses the IEEE assigns three bytes OUIs
      (Organizational Unit Identifier).  This OUI can be used to create
      unique MAC-addresses that can be assigned to equipment
      manufactured by a vendor.  The OUI is used as the first three
      bytes of the six byte MAC-address.
      The idea here is that IETF should apply for an OUI and use it to
      indicate that the rest of the MAC-address is the Ethernet label.
      The good thing about this proposal is that it leaves a
      comparatively large space for the label value (three bytes).  It
      is even possible that the label space is large enough to make
      "label swapping" necessary, if this is the case an estimate of the
      n-squared problem and the amount of state in the switches.
      On the negative side is that requires re-writing of source and
      destination MAC-addresses once the frame enters/leaves the GMPLS
      controlled Label Switching Ethernet network.  If the destination
      is only modified this leaves asymmetric encoding between the
      MAC_SA and MAC_DA.  It also changes completely processing of this
      field compared to its current usage.  Note also that this encoding



Andersson & Papadimitriou  Expires April 24, 2006              [Page 12]


Internet-Draft          Ethernet Label Switching            October 2005


      is not extensible since based on a fragmentation of an existing
      information field.
      There are number of issues that needs to be discussed with this
      proposal, e.g. introperability with existing switches and with
      switches that is both GMPLS and non-GMPLS controlled.

   o  use a new TPID (tag protocol identifier)

      A Q-tag is structured the following way.  The first two bytes is a
      "tag protocol identifier" with the value 0x8100 that indicates a
      (C-)VLAN tag in the next two bytes including 3 priority bits
      (Priority Code-Points), a 1-bit Canonical Format Indicator and a
      12-bit VLAN id.
      The idea here is to apply for a new TPID, and use the 13 bits of
      the last two bytes as a label and keep the 3 priority bits.  The
      label space would be 8192 labels.  The strength with this
      proposals is two-fold.  First there is no change in semantic from
      already existing and defined TAGs.  Then, forwarding based on MAC-
      address or re-writing is not necessary, on the other hand there
      are certain effects on the Ethernet forwarding plane.  Use of the
      IEEE802.1 Q-tag will apply to IEEE802.1ad switches.
      In this mode of operation the source and destination MAC-addresses
      of the MAC frames remain unchanged over the entire length of the
      Ethernet LSP, the same as for the Ethertype..

   o  use the I-tag that will be specified in IEEE802.1ah

      There is currently not enough information available on this, but
      it is certainly worth investigating since it will give us a label
      space of 20 bits.

3.4.4.1.  Label stack encoding

   A label stack is defined as an ordered set of labels, this means that
   for each of the proposed solution here above a "label stacking"
   method could be defined:

   o  when using the Q-tag and switch on the VLAN ID: techniques for
      nesting Q-tags ("Q-in-Q") will work for the Ethernet Labels make a
      two-level label stacking possible

   o  when using the new TPID a similar method could be considered with
      a larger flexibility in terms of number of levels

   o  when using MAC-address space a two level stack of labels could be
      considered in analogy to the MAC-in-MAC approach currently under
      development by the IEEE (802.1ah)




Andersson & Papadimitriou  Expires April 24, 2006              [Page 13]


Internet-Draft          Ethernet Label Switching            October 2005


   However, the need of several entries in the label stack is still an
   open issue for GMPLS controlled Ethernet Label Switching.  Also, the
   number of aggregation levels such environment would have to support
   (i.e. nesting) is also a related open discussion point.

3.4.5.  IEEE 802.1Q terminology

   Below the terminology related to IEEE 802.1Q is oulined, e.g. naming
   of the different fields and sub-fields.

3.4.5.1.  TAG Format



   Oct: 1               2               3               4
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               TPID            |              TCI              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   bit: 8             1 8             1 8             1 8             1


   IEEE 802.1 Q-tag format

   Figure 1

   TPID (16 bits): TAG Protocol Identification
   TCI (16 bits): TAG Control Information

3.4.5.2.  C-VLAN TAG Control Information (TCI)



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


   C-VLAN TAG Control Information

   Figure 2

   PCP (3 bits): Priority Code Point conveying priority & drop
   eligibility parameters
   C (1 bit): Canonical Format Indicator (CFI)
   VID (12 bits): VLAN Identifier




Andersson & Papadimitriou  Expires April 24, 2006              [Page 14]


Internet-Draft          Ethernet Label Switching            October 2005


3.4.5.3.  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


   S-VLAN TAG Control Information

   Figure 3

   PCP (3 bits): Priority Code Point conveying priority & drop
   eligibility parameters
   D (1 bits): Drop Eligible Indicator (DEI) bit
   VID (12 bits): VLAN Identitifer

3.5.  Related work in IETF

   GMPLS control of Ethernet switches (as described in this document) is
   based on the Ethernet MAC frame header.  The difference with other
   approaches currently worked in the context of other IETF working
   groups are briefly described in the following paragraphs.

3.5.1.  RFC 3032 (MPLS over Ethernet)

   The difference between GMPLS control of Ethernet switches (as
   described in this document) and MPLS transport over Ethernet links as
   described in [RFC3032] is that in the latter packets are labeled
   using MPLS shim headers.  Labeled packets are then encapsulated in
   Ethernet frames and targeted at the next IP/MPLS LSR along the path
   of the LSP.  At the incoming LSR interface, the Ethernet header is
   stripped and forwarding takes place based on the encapsulated MPLS
   label.  At each hop, forwarding operation of native L3 packets is
   done using labels and consists in looking up an incoming label to
   determine the outgoing label, encapsulation, port, and other data
   handling information.

   When the Ethernet header is stripped of it also implies that a new
   Ethernet header has to be created to carry the packet between each
   MPLS hop.  It should also be noted that one hop on an MPLS LSP could
   correspond to several hops through the Ethernet network.






Andersson & Papadimitriou  Expires April 24, 2006              [Page 15]


Internet-Draft          Ethernet Label Switching            October 2005


3.5.2.  RFC 3916 (Ethernet over Pseudo-Wire (PW))

   In [RFC3916], Ethernet frames are encapsulated and transported over a
   packet-switched network using PSN tunnels (e.g.  IP or MPLS tunnels).
   Therefore, the forwarding is based on packet headers.

   In single segment PW, the PW label is used a mux/demux label and does
   not enter into forwarding at intermediate LSRs through which the PSN
   tunnel is established.  For multi-segment PW, the PW label is
   inserted at the PE originating the PW i.e. the source PE, and is
   switched at each intermediate PE until it reaches the PE terminating
   the MS-PW, i.e. the destination PE.

   By definition, a PW starts and ends on a PE, comparatively the
   Ethernet Label Switching solution is meant to run in soft-permanent
   mode (i.e. between PEs) but also in a switched mode i.e. between CEs.

   An Ethernet pseudowire is indistinguishable from a point-to-point
   Ethernet link, the fact MPLS is one of the techniques that is used to
   implement PWs is of no consequence for the work on GMPLS controlled
   Ethernet Label Switching, the Ethernet PWs are listed for reference
   purposes only.

3.5.3.  TRILL Approach

   The TRILL working group has been recently formed to address the
   shortages of Ethernet networks using the spanning tree protocol.  As
   such, the TRILL WG is intended to deliver a solution to this problem
   for "CAMPUS" networks (even if its scope could be larger) by defining
   an "intermediate" technology between IP and Ethernet MAC layer to
   circumvent the drawbacks of the latter (in particular wrt to 802.1d
   and related).

   A specific difference compared to the TRILL WG is that the latter has
   been chartered to provide a solution without explicitly being able to
   run on existing IP routers as a software upgrade.  On the other hand,
   it is expected that a GMPLS capable LSR (acting as Ethernet LER)
   would be able to initiate/terminate Ethernet LSPs across an Ethernet
   LSR network.

   A further difference between TRILL, at least as it is currently
   chartered, is that TRILL aims for shortest-path routing of frames
   (connectionless) in multi-hop IEEE 802.1-compliant Ethernet networks
   with arbitrary topologies while GMPLS controlled Ethernet Label
   Switching aims for constraint based routing and explicit routing.






Andersson & Papadimitriou  Expires April 24, 2006              [Page 16]


Internet-Draft          Ethernet Label Switching            October 2005


3.5.4.  Positioning of Ethernet Label Switching

   The positioning of the present approach compared to the approaches
   detailed in the present section depicted in the following figure:




   +--------------+         +---------------+          +---------------+
   |   Payload    |         |   Payload     |          |    Payload    |
   +--------------+         +---------------+          +---------------+
   | Ethernet MAC |         |   MPLS Label  |          | TRILL header  |
    --------------           ---------------            ---------------
   |   PW Label   |         | Ethernet MAC  |          | Ethernet MAC  |
    --------------           ---------------            ---------------
   |  PSN Tunnel  |         |      PHY      |          |      PHY      |
   +--------------+         +---------------+          +---------------+

    PW Approach                MPLS Approach             TRILL Approach


    +---------------+
    |    Payload    |
     ---------------
    | Ethernet MAC  |
     ---------------
    |      PHY      |
    +---------------+

        ELS Approach




   Ethernet Label Switching in context

   Figure 4

   Compared to other approaches, Ethernet Label Switching provides an
   integrated label encoding as part of the Ethernet MAC frame header.
   No introduction of additional switching layer or forwarding layer is
   considered.  Compared to the PW approach however, Ethernet label
   switching is positioned as a tunneling technology.  This observation
   becomes even more important when considering Ethernet LSR interfacing
   classical Ethernet environment i.e. in order to avoid supporting
   complex interaction(s) between IEEE 802.1 protocols at Ethernet LERs
   the latter are expected to behave transparently.  This means that
   Ethernet IEEE 802.1 control frames are processed as any other user



Andersson & Papadimitriou  Expires April 24, 2006              [Page 17]


Internet-Draft          Ethernet Label Switching            October 2005


   frame.

   On the other hand, the Ethernet Label switching approach provides a
   simple mean for extending the Ethernet data plane capabilities with
   the "well accepted" carried functionalities such as automated
   provisioning, traffic-engineering, QoS parameter signaling,
   differentiated routing and re-routing.  It has to be emphasized that
   the major difference between the TRILL approach is that the data
   plane functionality is only enhanced such as to provide a "label
   switching" behavior, all other capabilities are inherited from the
   use of the associated GMPLS control plane.

   Another remarkable property of the Ethernet label switching is that
   it is able to work in both Switched (i.e. equivalent to ATM SVC mode)
   and Soft-permanent mode (i.e. equivalent to ATM SPVC mode).  Compared
   to the other approaches only the MPLS one is able to deliver a
   similar behavior between routers (or more generally when the labeled
   packets carry a L3 payload).  All other approaches are meant to work
   on SPVC mode only i.e. between PEs (or their equivalent).  As such
   the Ethernet label switching capability would be gradually deployable
   by first considering SPVC network capability and further consider
   extension of the GMPLS control plane deployment on CEs.

   In brief, the Ethernet label switching approach can be seen as a way
   to position Ethernet as a carrier-grade tunneling technology without
   modifying the relationship with the carried payload or the layers
   over which Ethernet payload can be transported.
























Andersson & Papadimitriou  Expires April 24, 2006              [Page 18]


Internet-Draft          Ethernet Label Switching            October 2005


4.  General requirements

   1.  For Ethernet Label Switching it SHALL be possible to use traffic
       engineering methods defined for MPLS and GMPLS.

   2.  For Ethernet Label Switching it SHALL be possible to use recovery
       methods defined for MPLS and GMPLS.

   3.  GMPLS is based on the IP routing and addressing models, in part.
       IPv4 and/or IPv6 addresses are used to identify L2SC interfaces.
       As it is not viable to associate an IP address with each end of
       each L2SC interface, GMPLS scalability enhancement to addressing
       must be re-usable: unnumbered links and link bundling.

   4.  GMPLS control plane information exchange between adjacent
       Ethernet LSRs and control plane information processing MUST be
       independent of the control channel implementation.

   5.  Control plane resilience mechanisms defined for GMPLS control
       plane (e.g.  RSVP engine graceful restart) SHALL be re-usable for
       Ethernet LSR






























Andersson & Papadimitriou  Expires April 24, 2006              [Page 19]


Internet-Draft          Ethernet Label Switching            October 2005


5.  Data plane

   Note: This section should include a discussion of the relevant
   Ethernet standards, at least IEEE 802.1Q, 802.1p, 802.1ad and
   802.1ah.

   Note: It also should include a discussion of the any data plane
   issues within scope.

5.1.  Data plane requirements

   1.  In current IEEE 802.1Q networks it is possible to create Virtual
       LANs, by adding a VLAN-id to the Ethernet frame.  The effect of
       the VLAN-id is that the scope of the broadcast domain will be
       limited and broadcast frames will only be sent to a subset of the
       hosts connected to the network.  This functionality MUST remain
       unchanged when the GMPLS control plane is introduced.

   2.  The Ethernet MAC frame structure must be left unchanged i.e.
       composed by Ethernet MAC frame header; a Payload and an FCS.  The
       former must remain structured such as to include the MAC_DA,
       MAC_SA one or more TAGs and the EtherType.  Ethernet TAG must
       still include a TPID (TAG Protocol ID) and a TCI (TAG Control
       Information). 802.1Q and 802.1ad include as part of the former an
       Ethertype value.

   3.  It is assumed that the current physical medium (known as Ethernet
       PHY) over which Ethernet labeled frames could be transmitted are
       left unchanged and be forward compatible with the 802.3
       specifications.

   4.  The MAC address space, size (6 bytes), format and semantic are
       left unchanged and must still support unicast, multicast and
       broadcast format and semantic.

   5.  The proposed Ethernet label format and switching must be such as
       to leave IEEE 802.1ag CFM operations independent

   6.  MTU size: the size of the Ethernet labeled frame falls into the
       revision of the IEEE P802.3as Ethernet Frame Expansion.

   7.  Note: Do we need to add further requirements?

5.2.  Relationship to IEEE 802

   The relationship between other SDOs and the IETF is managed by the
   Internet Architecture Board (IAB).  There is a long-standing liaison
   relationship between the IETF and the IEEE 802.  The proposed work



Andersson & Papadimitriou  Expires April 24, 2006              [Page 20]


Internet-Draft          Ethernet Label Switching            October 2005


   will leverage this relationship.  However, it might be necessary to
   form even closer cooperation in this area.  We don't see that this
   needs to take the form of establishing a new formal liaison
   relationship between the two organizations, but could very well be
   managed as part of the existing relationship.

   Note: The IETF liaison to the IEEE is Bernard Aboba, and we will
   bring the issues around the IETF/IEEE relationship and the proposed
   work to him and discuss whether it is necessary to appoint further
   people to work with the liaison relationship.

   If and when the IETF undertake the proposed work, we will need to
   coordinate closely with some of the IEEE 802.1 projects, especially
   802.1ad and 802.1ah.  The preliminary and informal contacts taken so
   far are very promising.

   Note: We had a very short discussion with Paul Condon (chairman of
   the 802.1) and he indicated that the necessary channels are
   available.

   Note: IEEE liaison (suggested Bernard Adoba)






























Andersson & Papadimitriou  Expires April 24, 2006              [Page 21]


Internet-Draft          Ethernet Label Switching            October 2005


6.  Control Plane

   -

6.1.  Control Plane requirements

   Note: This section is for further study.

6.1.1.  Link management requirments

   Note: For further study

6.1.2.  Routing requirements

   Note: For further study

6.1.3.  Signalling requirements

   Note: For further study

6.1.4.  Control channel requirements

   Note: For further study

6.2.  Cooperation with CCAMP WG

   Note: Cooperation with CCAMP (suggested Kireeti and Adrian)

   The IETF Common Control and Measurement Plane (CCAMP) working group
   coordinates the work within the IETF for defining a common control
   plane and a measurement plane for ISP and SP core tunneling
   technologies.  This includes, but is not limited to, defining
   signaling protocols and measurement protocols such that they support
   multiple physical path and tunnel technologies using input from
   technology- specific working groups such as the MPLS working group;
   protocol-independent metrics and parameters for describing links and
   paths that can be carried in protocols.

   The CCAMP Working group addresses, among others, a generalized
   technology, referred to as GMPLS, where labels are defined in such a
   way that they will be compatible with the technology they are
   transported over.  The CCAMP working group work focuses on common
   methods across a broad spectrum of switching technologies.  Base
   GMPLS signaling (RFC 3471 [rfc3471] and RFC 3473 [rfc3473]) and
   routing ([I-D.ietf-ccamp-gmpls-routing], and [I-D.ietf-ccamp-ospf-
   gmpls-extensions]) are output of the CCAMP WG.  [I-D.ietf-isis-gmpls-
   extensions] is the product of the IS-IS Working Group.  Documents
   that propose extensions or changes to protocols that have been



Andersson & Papadimitriou  Expires April 24, 2006              [Page 22]


Internet-Draft          Ethernet Label Switching            October 2005


   specified by the CCAMP working group, e.g., documents that specify
   new GMPLS methods or extensions and new GMPLS encapsulations MUST be
   handled by the CCAMP working group.

   One exception to this rule is when other IETF working group has been
   appointed, with the prerequisite CCAMP WG agreement, to handle
   extensions and/or changes to the protocols specified by the CCAMP
   working group.  The present work falls into this category.  This
   implies that any GMPLS protocol extension, or enhancement proposed in
   the context of this item must be revisited by the by the CCAMP WG
   such that the appropriate level of technical review is ensured.  To
   avoid extra delays and ensure right level of collaboration the review
   process must be conducted earlier before WG Last Call process.

6.3.  Cooperation with other Working Groups

6.3.1.  Common review

   Cooperation with other working groups, in particular protocol-
   specific WG (e.g.  IS-IS or OSPF) MUST involve the same review
   process.  This implies that any protocol extension, or enhancement
   proposed in the context of this work item must be revisited by the
   protocol-specific WGs such that the appropriate level of technical
   review is ensured.  To avoid extra delays and ensure right level of
   collaboration the review process must be conducted earlier before WG
   Last Call process.

6.3.2.  Working groups

   Cooperation is foreseen with the following Working Groups (in
   addition to the CCAMP WG): OSPF WG, IS-IS WG, MPLS WG and TRILL WG.

   Note: The specific list of working groups we need to co-ordinate and
   co-operate with needs to be finalized.

6.3.3.  Potential overlap with other working groups

   Note: This section is for further study.  Potentially the we that we
   need to discuss the relationship with TRILL further.












Andersson & Papadimitriou  Expires April 24, 2006              [Page 23]


Internet-Draft          Ethernet Label Switching            October 2005


7.  Expected outcome

   -

7.1.  Milestones

   Milestones are obviously related to progressing documents, we list
   the set of documents we think is necessary for completion of the
   proposed work see Section 3.4.4.

   o  milestone 0 - decision on the Ethernet label(s) format

   o  milestone 1 (possibly the Framework draft as working group
      document Section 7.2.1)

   o  milestone 2 (possibly the Signaling and Routing Extensions drafts
      as working ggroup documents Section 7.2.3 and Section 7.2.2)

   o  milestone 3 (possibly the Framework draft sent to the IESG to be
      published as an informational RFC, Section 7.2.1).

   o  milestone 4 (possibly OAM features and MIB drafts as working group
      document Section Section 7.2.6 and Section Section 7.2.7).

   o  milestone 5 (possibly the Signaling and Routing Applicability
      drafts as wg documents Section Section 7.2.5 and Section
      Section 7.2.4)

   o  milestone 6 (possibly the Signaling and Routing Extensions drafts
      sent to IESG to be published as PS RFC)

   o  milestone 7 (possibly OAM features and MIB drafts sent to IESG to
      be published as PS RFC)

   o  milestone 8 (possibly the Signaling and Routing Applicability
      drafts sent to the IESG to be published as an informational RFC,)

   Note: Dimitri is working on a first cut of the charter.

7.2.  Documents

   This section list documents that we believe should be included in the
   output from the proposed work.

   The documents are listed here tentatively, as the work progresses it
   might turn out that we want to re-arrange the content between the
   documents, merge or split documents.




Andersson & Papadimitriou  Expires April 24, 2006              [Page 24]


Internet-Draft          Ethernet Label Switching            October 2005


7.2.1.  Framework

   Note: Framework (incl. data plane aspects)

   The framework is intended to capture terminology, architechture and
   requirements for GMPLS controlled Ethernet Label Switching.  The
   framework will also be the place where the format of the Ethernet
   label(s) will be documented.

7.2.2.  Routing Extensions

   Note: Routing extensions

7.2.3.  Signaling Extensions

   Note: Signaling extensions

7.2.4.  Routing Applicability

   Note: Routing applicability

7.2.5.  Signaling Applicability

   Note: Signaling applicability

7.2.6.  OAM features

   Note: OAM features

7.2.7.  Ethernet Label switching MIB

   Note: Ethernet Label Switching MIB



















Andersson & Papadimitriou  Expires April 24, 2006              [Page 25]


Internet-Draft          Ethernet Label Switching            October 2005


8.  IANA Considerations

   Note: This section placed here tentatively.
















































Andersson & Papadimitriou  Expires April 24, 2006              [Page 26]


Internet-Draft          Ethernet Label Switching            October 2005


9.  Security Considerations

   The BOF preparation document does not in itself add any new security
   aspects to the Internet.  However, below we list that reflects our
   current understanding of the security aspects we would have to
   consider if we were to undertake the proposed work.

   The document raises similar security issues such as with any other
   type of LSPs.  However, additional security threats have been
   identified:

   o  Possibility for the network to control the traffic injected by the
      client in the data plane (BPDU, Multicast, Broadcasts, etc.)

   o  Entry points induced by the possible coexistence of the two
      technologies (L2LSPs and usual Broadcast Ethernet mode)

9.1.  Attacks on the Data Plane

   Attacks on the data plane can be of the following form:

   o  modification of data traffic

   o  insertion of non-authentic data traffic

   o  Denial of Service (DoS) attacks

   o  traffic snooping

   Introduction of GMPLS signaling fro Ethernet LSP MUST prevent these
   attacks.  Moreover, as an Ethernet LSP is by nature a point-to-point
   tunnel, with a single entry point (head-end LSR) and exit point
   (tail-end LSR).  Policing (rate limit) and filtering is required only
   on the head-end LSR.

9.2.  Attacks on the Control Plane

   GMPLS Ethernet networks will inherit the security issues of IP
   networks similar to other GMPLS client networks, and the appropriate
   trust models MUST be supported.  Existing RSVP security mechanisms
   RFC 2207 [RFC2207] and RFC 3097 [RFC3097] should also be analyzed/
   evaluated in this context.









Andersson & Papadimitriou  Expires April 24, 2006              [Page 27]


Internet-Draft          Ethernet Label Switching            October 2005


10.  Acknowledgements

   We would like to thank the CCAMP working group L2SC design team,
   which joine3d the discussion on GMPLS controlled Ethernet Label
   Switching with great enthusiasm.

   We would also like to thanks Adrian Farrel for insightful major
   technical comments and extensive nit-picking.











































Andersson & Papadimitriou  Expires April 24, 2006              [Page 28]


Internet-Draft          Ethernet Label Switching            October 2005


11.  References

11.1.  Normative References

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

11.2.  Informative References

   [I-D.ietf-ccamp-gmpls-routing]
              Kompella, K. and Y. Rekhter, "Routing Extensions in
              Support of Generalized Multi-Protocol Label  Switching",
              draft-ietf-ccamp-gmpls-routing-09 (work in progress),
              October 2003.

   [I-D.ietf-ccamp-ospf-gmpls-extensions]
              Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
              of Generalized Multi-Protocol Label Switching",
              draft-ietf-ccamp-ospf-gmpls-extensions-12 (work in
              progress), October 2003.

   [I-D.ietf-isis-gmpls-extensions]
              Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support
              of Generalized MPLS", draft-ietf-isis-gmpls-extensions-19
              (work in progress), October 2003.

   [I-D.papadimitriou-ccamp-gmpls-ethernet-framework]
              Papadimitriou, D. and J. Choi, "A Framework for
              Generalized MPLS (GMPLS) Ethernet",
              draft-papadimitriou-ccamp-gmpls-ethernet-framework-00
              (work in progress), July 2005.

   [I-D.papadimitriou-ccamp-gmpls-mrn-extensions]
              Papadimitriou, D., "Generalized Multi-Protocol Label
              Switching (GMPLS) Protocol Extensions for  Multi-Region
              Networks (MRN)",
              draft-papadimitriou-ccamp-gmpls-mrn-extensions-01 (work in
              progress), February 2005.

   [RFC2207]  Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
              Data Flows", RFC 2207, September 1997.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, January 2001.



Andersson & Papadimitriou  Expires April 24, 2006              [Page 29]


Internet-Draft          Ethernet Label Switching            October 2005


   [RFC3036]  Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
              B. Thomas, "LDP Specification", RFC 3036, January 2001.

   [RFC3097]  Braden, R. and L. Zhang, "RSVP Cryptographic
              Authentication -- Updated Message Type Value", RFC 3097,
              April 2001.

   [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", RFC 3473, January 2003.

   [RFC3916]  Xiao, X., McPherson, D., and P. Pate, "Requirements for
              Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
              September 2004.

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

   [RFC3946]  Mannie, E. and D. Papadimitriou, "Generalized Multi-
              Protocol Label Switching (GMPLS) Extensions for
              Synchronous Optical Network (SONET) and Synchronous
              Digital Hierarchy (SDH) Control", RFC 3946, October 2004.

























Andersson & Papadimitriou  Expires April 24, 2006              [Page 30]


Internet-Draft          Ethernet Label Switching            October 2005


Authors' Addresses

   Loa Andersson
   Acreo AB

   Email: loa@pi.se


   Dimitri Papadimitriou
   Alcatel

   Email: dpapadimitriou@psg.com







































Andersson & Papadimitriou  Expires April 24, 2006              [Page 31]


Internet-Draft          Ethernet Label Switching            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
   ietf-ipr@ietf.org.


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.




Andersson & Papadimitriou  Expires April 24, 2006              [Page 32]


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