Internet Draft                                 Don Fedyk, Alcatel-Lucent
Category: Informational                                 Lou Berger, LabN
Expiration Date: March 1, 2010                Loa Andersson, Ericsson AB

                                                       September 1, 2009

      Generalized Multi-Protocol Label Switching (GMPLS) Ethernet
               Label Switching Architecture and Framework

              draft-ietf-ccamp-gmpls-ethernet-arch-05.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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/1id-abstracts.html

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

   This Internet-Draft will expire on March 1, 2010.

Copyright and License Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   There has been significant recent work in increasing the capabilities
   of Ethernet switches and Ethernet forwarding models. As a
   consequence, the role of Ethernet is rapidly expanding into
   "transport networks" that previously were the domain of other



Fedyk, et. al.                Informational                     [Page 1]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


   technologies such as Synchronous Optical Network (SONET)/Synchronous
   Digital Hierarchy (SDH), Time-Division Multiplex (TDM) and
   Asynchronous Transfer Mode (ATM). This document defines an
   architecture and framework for a Generalized GMPLS based control
   plane for Ethernet in this "transport network" capacity. GMPLS has
   already been specified for similar technologies. Some additional
   extensions to the GMPLS control plane are needed and this document
   provides a framework for these extensions.














































Fedyk, et. al.                Informational                     [Page 2]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


Table of Contents

    1      Introduction  ...........................................   4
    1.1    Terminology  ............................................   6
    1.1.1  Concepts  ...............................................   6
    1.1.2  Abbreviations and Acronyms  .............................   8
    2      Background  .............................................   8
    2.1    Ethernet Switching  .....................................   9
    2.2    Operations, Administration, and Maintenance (OAM)  ......  11
    2.3    Ethernet Switching Characteristics  .....................  12
    3      Framework  ..............................................  12
    4      GMPLS Routing and Addressing Model  .....................  14
    4.1    GMPLS Routing  ..........................................  15
    4.2    Control Plane Network  ..................................  15
    5      GMPLS Signaling  ........................................  16
    6      Link Management  ........................................  16
    7      Path Computation and Selection  .........................  18
    8      Multiple VLANs  .........................................  18
    9      Security Considerations  ................................  18
   10      IANA Considerations  ....................................  19
   11      References  .............................................  19
   11.1    Normative References  ...................................  19
   11.2    Informative References  .................................  19
   12      Acknowledgments  ........................................  21
   13      Author's Addresses  .....................................  21





















Fedyk, et. al.                Informational                     [Page 3]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


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



1. Introduction

   There has been significant recent work in increasing the capabilities
   of Ethernet switches. As a consequence, the role of Ethernet is
   rapidly expanding into "transport networks" that previously were the
   domain of other technologies such as SONET/SDH TDM and ATM.  The
   evolution and development of Ethernet capabilities in these areas is
   a very active and ongoing process.

   Multiple organizations have been active in extending Ethernet
   technology to support transport networks.  This activity has taken
   place in the Institute of Electrical and Electronics Engineers (IEEE)
   802.1 Working Group, the International Telecommunication Union (ITU)
   and the Metro Ethernet Forum (MEF).  These groups have been focusing
   on Ethernet forwarding, Ethernet management plane extensions and the
   Ethernet Spanning Tree Control Plane, but not on an explicitly
   routed, constraint based control plane.

   In the forwarding plane context, extensions have been, or are being,
   defined to support different transport Ethernet forwarding models,
   protection modes, and service interfaces.  Examples of such
   extensions include [802.1ah], [802.1Qay], [G.8011] and [MEF.6]. These
   extensions allow for greater flexibility in the Ethernet forwarding
   plane and, in some cases, the extensions allow for a departure from
   forwarding based on Ethernet spanning tree. For example, in the
   [802.1Qah] case, greater flexibility in forwarding is achieved
   through the addition of a "provider" address space.  [802.1Qay]
   supports the use of provisioning systems and network control
   protocols that explicitly select traffic engineered paths.

   This document provides a framework for GMPLS Ethernet Label switching
   (GELS). GELS will likely require more than one switching type to
   support the different models, and as the GMPLS procedures that will
   need to be extended are dependent on switching type, these will be
   covered in the technology specific documents.

   In the provider bridge model developed in the IEEE 802.1ad project
   and amended to the IEEE 802.1Q standard [802.1Q], an extra Virtual
   Local Area Network (VLAN) identifier (VID) is added. This VLAN is
   referred to as the Service VID, (S-VID and is carried in a Service



Fedyk, et. al.                Informational                     [Page 4]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


   TAG (S-TAG). In provider backbone bridges (PBB) [802.1ah] a backbone
   VID (B-VID) and B-MAC header with a Service Instance (I-TAG)
   encapsulates a customer Ethernet frame or a service Ethernet frame.

   In the IEEE 802.1Q standard the terms Provider Backbone Bridges (PBB)
   and Provider Backbone Bridged Network (PBBN) are used in the context
   of these extensions.

   An example of Ethernet protection extensions can be found in
   [G.8031].  Ethernet operations, administration, and maintenance (OAM)
   is another important area that is being extended to enable provider
   Ethernet services.  Related extensions can be found in [802.1ag] and
   [Y.1731].

   An Ethernet based service model is being defined within the context
   of the Metro Ethernet Forum (MEF) and International Telecommunication
   Union (ITU).  [MEF.6] and [G.8011] provide parallel frameworks for
   defining network-oriented characteristics of Ethernet services in
   transport networks.  These framework documents discuss general
   Ethernet connection characteristics, Ethernet User-Network Interfaces
   (UNIs) and Ethernet Network-Network Interfaces (NNIs). [G.8011.1]
   defines the Ethernet Private Line (EPL) service and [G.8011.2]
   defines the Ethernet Virtual Private Line (EVPL) service. [MEF.6]
   covers both service types.  These activities are consistent with the
   types of Ethernet switching defined in [802.1ah].

   The Ethernet forwarding and management plane extensions allow for the
   disabling of standard Ethernet spanning tree but do not define an
   explicitly routed, constraint based control plane.  For example
   [802.1Qay] is an amendment to IEEE 802.1Q that explicitly allows for
   traffic engineering of Ethernet forwarding paths.

   The IETF's GMPLS work provides a common control plane for different
   data plane technologies for Internet and telecommunication service
   providers. The GMPLS architecture is specified in RFC3945 [RFC3945].
   The protocols specified for GMPLS can be used to control "Transport
   Network" technologies, e.g. Optical and TDM networks. GMPLS can also
   be used for packet and Layer 2 Switching (frame/cell based networks.

   This document provides a framework for use of GMPLS to control
   "transport" Ethernet Label Switched Paths (Eth-LSP).  Transport
   Ethernet adds new constraints which require it to be distinguished
   from the previously specified technologies for GMPLS. Some additional
   extensions to the GMPLS control plane are needed and this document
   provides a framework for these extensions.  All extensions to support
   Eth-LSPs will build on the GMPLS architecture and related
   specifications.




Fedyk, et. al.                Informational                     [Page 5]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


   This document introduces and explains GMPLS control plane use for
   transport Ethernet and the concept of the Ethernet Label Switched
   Path (Eth-LSP).  The data plane aspects of Eth-LSPs are outside the
   scope of this document and IETF activities.

   The intent of this document is to reuse and align with as much of the
   GMPLS protocols as possible.  For example, reusing the IP control
   plane addressing allows existing signaling, routing, LMP and path
   computation to be used as specified.  The GMPLS protocols support
   hierarchical LSPs as well as contiguous LSPs. Also, GMPLS protocol
   mechanisms support a variety of networks from peer to peer to UNIs
   and NNIs. Additions to existing GMPLS capabilities will only be made
   to accommodate features unique to transport Ethernet.


1.1. Terminology

1.1.1. Concepts

   The following are basic Ethernet and GMPLS terms:

     o Asymmetric Bandwidth

       This term refers to a property of a Bidirectional service
       instance may have differing bandwidth allocation in each
       direction.

     o Bidirectional Congruent LSP

       This term refers to the property of a bi-directional LSP that
       uses only the same nodes, ports, and links in both directions.
       Ethernet data planes are normally bi-directional or reverse path
       congruent.

     o Contiguous Eth-LSP

       A contiguous Eth-LSP is an Eth-LSP that maps one to one with an
       another LSP at a VLAN boundary. Stitched LSPs are contiguous
       LSPs.

     o Eth-LSP

       This term refers to Ethernet switched paths that may be
       controlled via GMPLS.







Fedyk, et. al.                Informational                     [Page 6]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


     o Hierarchical Eth-LSP

       Hierarchical Eth-LSPs aggregate Eth-LSPs by creating a hierarchy
       of Eth-LSPs.

     o In-band GMPLS Signaling

       In-band GMPLS Signaling is IP based control messages which are
       sent on the native Ethernet links encapsulated by a single hop
       Ethernet header. Logical links that use a dedicated VID on the
       same physical links would be considered In-band signaling.

     o Out-of-band GMPLS Signaling

       Out-of-band GMPLS Signaling is IP based control messages which
       are sent between Ethernet switches that uses some other links
       other than the Ethernet data plane links. Out of band signaling
       typically shares a different fate from the data links.

     o Point-to-point (P2P) Traffic Engineering (TE) Service Instance

       An TE service instance made up from two P2P unidirectional Eth-
       LSPs.

     o Point-to-multipoint (P2MP) Traffic Engineering (TE) Service
       Instance

       An TE service Instance supported by a set of LSPs which comprises
       one P2MP LSP from a root to n leaves plus a Bidirectional
       Congruent point-to-point (P2P) LSP from each of the leaves to the
       root.

     o Shared forwarding

       Shared forwarding is a property of a data path where a single
       forwarding entry (VID + DMAC) may be used for frames from
       multiple sources (SMAC). Shared forwarding does not change any
       data plane behavior. Shared forwarding saves forwarding database
       (FDB) entries only.  Shared forwarding offers similar benefits to
       merging in the data plane. However in shared forwarding the
       Ethernet data packets are unchanged when using shared forwarding.
       With shared forwarding dedicated control plane states for all
       Eth-LSP are maintained regardless of shared forwarding entries.








Fedyk, et. al.                Informational                     [Page 7]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


1.1.2. Abbreviations and Acronyms

   The following abbreviations and acronyms are used in this document:

   CCM             Continuity Check Message
   CFM             Connectivity Fault Management
   DMAC            Destination MAC Address
   Eth-LSP         Ethernet Label Switched Path
   I-SID           Service Identifier
   LMP             Link Management Protocol
   MAC             Media Access Control
   MP2MP           Multipoint to multipoint
   NMS             Network Management System
   OAM             Operations, Administration and Maintenance
   PBB             Provider Backbone Bridges [802.1ah]
   PBB-TE          Provider Backbone Bridges Traffic Engineering
                   [802.1Qay]
   P2P             Point to Point
   P2MP            Point to Multipoint
   QoS             Quality of Service
   SMAC            Source MAC Address
   S-TAG           A service TAG defined in the 802.1 Standard
                   [802.1Q]
   TE              Traffic Engineering
   TAG             An Ethernet short form for a TAG Header
   TAG Header      An extension to an Ethernet frame carrying
                   priority and other information.
   TSpec           Traffic specification
   VID             VLAN Identifier
   VLAN            Virtual LAN


2. Background

   This section provides background to the types of switching and
   services that are supported within the defined framework.  The former
   is particularly important as it identifies the switching functions
   that GMPLS will need to represent and control. The intent is for this
   document to allow for all standard forms of Ethernet switching and
   services.

   The material presented in this section is based on both finished and
   on-going work taking place in the IEEE 802.1 Working Group, the ITU
   and the MEF.  This section references and, to some degree, summarizes
   that work.  This section is not a replacement for, or an
   authoritative description of that work.





Fedyk, et. al.                Informational                     [Page 8]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


2.1. Ethernet Switching

   In Ethernet switching terminology, the bridge relay is responsible
   for forwarding and replicating the frames.  Bridge relays forward
   frames based on the Ethernet header fields: Virtual Local Area
   Network (VLAN) Identifiers (VID) and Destination Media Access Control
   (DMAC) address. PBB [802.1ah] has also introduced a Service Instance
   tag (I-TAG).  Across all the Ethernet extensions (already referenced
   in the Introduction), multiple forwarding functions, or service
   interfaces, have been defined using the combination of VIDs, DMACs,
   and I-TAGs.  PBB [802.1ah] provides a breakdown of the different
   types of Ethernet switching services. Figure 1 reproduces this
   breakdown.

                              PBB Network
                             Service Types
                          _,,-'    |    '--.._
                    _,.-''         |          `'--.._
              _,.--'               |                 `'--..
        Port based              S-tagged              I-tagged
                               _,-     -.
                            _.'          `.
                         _,'               `.
                     one-to-one           bundled
                                         _.-   =.
                                     _.-'        ``-.._
                                 _.-'                 `-..
                            many-to-one              all-to-one
                                                          |
                                                          |
                                                          |
                                                     Transparent

                Figure 1: Ethernet Switching Service Types

   The switching types are defined in Clause 25 of [802.1ah].  While not
   specifically described in [802.1ah], the Ethernet services being
   defined in the context of [MEF.6] and [G.8011] also fall into the
   types defined in Figure 1 (with the exception of the newly defined I-
   tagged service type).

   [802.1ah] defines a new I-tagged service type but does not
   specifically define the Ethernet services being defined in the
   context of [MEF.6] and [G.8011] which are also illustrated in Figure
   1.

   To summarize the definitions:




Fedyk, et. al.                Informational                     [Page 9]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


   o Port based
     This is a frame based service that supports specific frame types,
     no Service VLAN tagging, with MAC address based switching.

   o S-tagged
     There are multiple Service VLAN tag (S-tag) aware services,
     including:

     + one-to-one
       In this service, each VLAN identifier (VID) is mapped into a
       different service.

     + Bundled
       Bundled S-tagged service supports the mapping of multiple VIDs
       into a single service and include:

       * many-to-one
         In this frame based service, multiple VIDs are mapped into the
         same service.

       * all-to-one
         In this frame based service, all VIDs are mapped into the same
         service.

         - transparent
           This is a special case, all frames are mapped from a single
           incoming port to a single destination Ethernet port.

   o I-tagged
     The edge of a PBBN consists of a combined backbone relay (B-
     component relay) and service instance relay (I-component relay).
     An I-Tag contains a service identifier (24 bit I-SID) and priority
     markings as well as some other fields.  An I-Tagged service is
     typically between the edges of the PBBN and terminated at each edge
     on an I-component that faces a customer port so the service is
     often not visible except at the edges.  However, since the I-
     component relay involves a distinct relay, it is possible to have a
     visible I-Tagged Service by separating the I component relay from
     the B-component relay.  Two examples where it makes sense to do
     this are: an I-Tagged service between two PBBNs and as an
     attachment to a customer's Provider Instance Port.


   In general, the different switching types determine which of the
   Ethernet header fields are used in the forwarding/switching function,
   e.g. VID only or VID and DMACs.  The switching type may also require
   the use of additional Ethernet headers or fields. Services defined
   for UNIs tend to use the headers for requesting service (service



Fedyk, et. al.                Informational                    [Page 10]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


   delimiter) and are relevant between the customer site and network
   edge.

   In most bridging cases, the header fields cannot be changed, but some
   translations of VID field values are permitted, typically at the
   network edges.

   Across all service types, the Ethernet data plane is bi-directional
   congruent. This means that the forward and reverse paths share the
   exact same set of nodes, ports and bi-directional links.  This
   property is fundamental. The 802.1 group has maintained this bi-
   directional congruent property in the definition of Connectivity
   Fault Management (CFM) which is part of the overall Operations
   Administration and Management (OAM) capability.


2.2. Operations, Administration, and Maintenance (OAM)

   Robustness is enhanced with the addition of data plane OAM to provide
   both fault and performance management.

   Ethernet OAM messages [802.1ag] and [Y.1731], rely on data plane
   forwarding for both directions.  Determining a broken path or
   misdirected packet in this case relies on OAM following the Eth-LSP.
   These OAM message identifiers are dependent on the data plane so they
   work equally well for provisioned or GMPLS controlled paths.

   Ethernet OAM currently consists of:
   Defined in both [802.1ag & Y.1731]:
   - CCM/RDI: Connectivity Check, Remote Defect Indication
   - LBM/LBR: Loopback Message, Loopback Reply
   - LTM/LTR: Link trace Message, Link trace Reply
   - VSM/VSR: Vendor-specific extensions Message/Reply

   Additionally defined in [Y.1731]:
   - AIS:        Alarm Indication Signal
   - LCK:        Locked Signal
   - TST:        Test
   - LMM/LMR:    Loss Measurement Message/Reply
   - DM/DMM/DMR: Delay Measurement
   - EXM/EXR:    Experimental
   - APS, MCC:   Automatic Protection Switching, Maintenance
                 Communication Channel

   These functions are supported across all the Standardized Eth-LSP
   formats.





Fedyk, et. al.                Informational                    [Page 11]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


2.3. Ethernet Switching Characteristics

   Ethernet is similar to MPLS it encapsulates different packet and
   frame types for data transmission.  In Ethernet, the encapsulated
   data is referred to as MAC client data.  The encapsulation is an
   Ethernet MAC frame with a header, a source address, destination
   address, optional VLAN identifier, Type and length on the front of
   the MAC client data with optional padding and a Frame Check Sequence
   at the end of the frame.

   The type of MAC client data is typically identified by an "Ethertype"
   value. This is an explicit type indication but Ethernet also supports
   an implicit type indication.

   Ethernet bridging switches Ethernet based on the Frame destination
   MAC address and VLAN. The VLAN identifies a virtual set of Bridges
   and LANs.  The address is assumed to be unique and invariant within
   the VLAN. MAC addresses are often globally unique but this is not
   necessary for bridging.


3. Framework

   As defined in the GMPLS Architecture [RFC3945], the GMPLS control
   plane can be applied to a technology by controlling the data plane
   and switching characteristics of that technology. The architecture
   includes a clear separation between a control plane and a data plane.
   Control plane and data plane separation allows the GMPLS control
   plane to remain architecturally and functionally unchanged while
   controlling different technologies.  The architecture also requires
   IP connectivity for the control plane to exchange information, but
   does not otherwise require an IP data plane.

   All aspects of GMPLS, i.e., addressing, signaling, routing and link
   management, may be applied to Ethernet switching.  GMPLS can provide
   control for traffic engineered and protected Ethernet service paths.
   This document defines the term "Eth-LSP" to refer to Ethernet service
   paths that are controlled via GMPLS. As is the case with all GMPLS
   controlled services, Eth-LSPs can leverage common traffic engineering
   attributes such as:

   - bandwidth profile;
   - forwarding priority level;
   - connection preemption characteristics;
   - protection/resiliency capability;
   - routing policy, such as an explicit route;
   - bi-directional service;
   - end-to-end and segment protection;



Fedyk, et. al.                Informational                    [Page 12]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


   - hierarchy

   The bandwidth profile may be used to set committed information rate,
   peak information rate, and policies based on either under-
   subscription or over-subscription.  Services covered by this
   framework MUST use a TSpec that follows the Ethernet Traffic
   parameters defined in [ETH-TSPEC].

   The GMPLS architecture, per [RFC3945], allowed for control of
   Ethernet bridges and other layer 2 technologies using the Layer-2
   Switch Capable (L2SC) switching type.  The control of Ethernet
   switching was not explicitly defined in [RFC3471], [RFC4202] or any
   other subsequent GMPLS reference document.

   In applying GMPLS to "transport" Ethernet, GMPLS will need to be
   extended to work with the Ethernet data plane and switching
   functions.  The definition of GMPLS support for Ethernet is multi-
   faceted due to the different forwarding/switching functions inherent
   in the different service types discussed in Section 2.1. In general,
   the header fields used in the forwarding/switching function, e.g. VID
   and DMAC, can be characterized as a data plane label.  In some
   circumstances these fields will be constant along the path of the
   Eth-LSP, and in others they may vary hop-by-hop or at certain
   interfaces only along the path. In the case where the "labels" must
   be forwarded unchanged, there are a few constraints on the label
   allocation that are similar to some other technologies such as lambda
   labels.

   The characteristics of the "transport" Ethernet data plane are not
   modified in order to apply GMPLS control.  For example, consider the
   IEEE 802.1Q [802.1Q] data plane: The VID is used as a "filter"
   pointing to a particular forwarding table, and if the DMAC is found
   in that forwarding table the forwarding decision is taken based on
   the DMAC. When forwarding using an Ethernet spanning tree, if the
   DMAC is not found the frame is broadcast over all outgoing interfaces
   for which that VID is defined.  This valid MAC checking and broadcast
   supports Ethernet learning.  A special case is when a VID is defined
   for only two ports on one bridge, effectively resulting in a p2p
   forwarding constraint, in this case all frames tagged with that VID
   received over one of these ports are forward over the other port
   without address learning.

   [802.1Qay]allows for turning off learning and hence the broadcast
   mechanism providing means to create explicitly routed Ethernet
   connections.

   This document does not define any specific format for an Eth-LSP
   label. Rather, it is expected that service specific documents will



Fedyk, et. al.                Informational                    [Page 13]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


   define any signaling and routing extensions needed to support a
   specific Ethernet service.  Depending on the requirements of a
   service, it may be necessary to define multiple GMPLS protocol
   extensions and procedures. It is expected that all such extensions
   will be consistent with this document.

   It is expected that key a requirement for service specific documents
   will be to describe label formats and encodings. It may also be
   necessary to provide a mechanism to identify the required Ethernet
   service type in signaling and a way to advertise the capabilities of
   Ethernet switches in the routing protocols. These mechanisms must
   make it possible to distinguish between requests for different
   paradigms including new, future, and existing paradigms.

   The Switching Type and Interface Switching Capability Descriptor
   share a common set of values and are defined in [RFC3945], [RFC3471],
   and [RFC4202] as indicators of the type of switching that should
   ([RFC3471]) and can ([RFC4202]) be performed on a particular link for
   an LSP.  Since the L2SC switching type may already be used by
   implementations performing layer 2 switching including Ethernet, to
   support the continued use of that switching type and those
   implementations, and to distinguish the different Ethernet switching
   paradigms, a new Ethernet switching type MUST be defined for each new
   Ethernet switching paradigm that is supported.

   For discussion purposes, we decompose the problem of applying GMPLS
   into the functions of Routing, Signaling, Link Management and Path
   Selection. It is possible to use some functions of GMPLS alone or in
   partial combinations. In most cases using all functions of GMPLS
   leads to less operational overhead than partial combinations.


4. GMPLS Routing and Addressing Model

   The GMPLS Routing and Addressing Model is not modified by this
   document.  GMPLS control for Eth-LSPs uses the Routing and Addressing
   Model described in [RFC3945].  Most notably this includes the use of
   IP addresses to identify interfaces and LSP end-points.  It also
   includes support for both numbered and unnumbered interfaces.

   In the case where another address family or type of identifier is
   required to support an Ethernet service, extensions may be defined to
   provide mapping to an IP address.  Support of Ethernet MUST strictly
   comply to the GMPLS protocol suite addressing as specific in RFC3471,
   RFC3473 and related.






Fedyk, et. al.                Informational                    [Page 14]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


4.1. GMPLS Routing

   GMPLS routing as defined in [RFC4202] uses IP routing protocols with
   the opaque TLV extensions for the purpose of distributing GMPLS
   related TE (router and link) information. As is always the case with
   GMPLS, TE information is populated with TE resources coordinated with
   LMP or from configured information. The bandwidth resources of the
   links are tracked as Eth-LSPs are set up. Interfaces supporting the
   switching of Eth-LSPs are identified using the appropriate Interface
   Switching Capabilities Descriptor.  As mentioned in Section 3, the
   definition of one or more new Interface Switching Capabilities to
   support Eth-LSPs is expected.  The L2SC Interface Switching
   Capabilities MUST NOT be used to represent interfaces capable of
   supporting Eth-LSPs defined by this document and subsequent documents
   in support of the transport Ethernet switching paradigms.  In
   addition, Interface Switching Capability specific TE information may
   be defined as needed to support the requirements of a specific
   Ethernet Switching Service Type.

   GMPLS Routing is an optional functionality but it is highly valuable
   in maintaining topology and distributing the TE database for path
   management and dynamic path computation.


4.2. Control Plane Network

   In order for a GMPLS control plane to operate, an IP connectivity
   network of sufficient capacity to handle the information exchange
   between the GMPLS routing and signaling protocols is necessary.

   One way to implement this is with an IGP that views each switch as a
   terminated IP adjacency. In other words, IP traffic and a simple
   routing table are available for the control plane but there is no
   requirement for needing a high performance IP data plane.

   This IP connectivity can be provided as a separate independent
   network (out of band) or integrated with the Ethernet switches (in-
   band).













Fedyk, et. al.                Informational                    [Page 15]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


5. GMPLS Signaling

   GMPLS signaling, see [RFC3471][RFC3473], is well suited to the
   control of Eth-LSPs and Ethernet switches.  Signaling enables the
   ability to dynamically establish a path from an ingress node to an
   egress node.  The signaled path may be completely static and not
   change for the duration of its lifetime. However, signaling also has
   the capability to dynamically adjust the path in a coordinated
   fashion after the path has been established. The range of signaling
   options from static to dynamic are under operator control.
   Standardized signaling also improves multi-vendor interoperability
   over simple management.

   GMPLS signaling supports the establishment and control of bi-
   directional and unidirectional data paths. Ethernet is bi-directional
   by nature and the CFM has been built to leverage this. Prior to CFM
   the emulation of a physical wire and the learning requirements also
   mandated bi-directional connections. Given this, Eth-LSPs MUST be bi-
   directional congruent. Eth-LSPs may be either P2P or P2MP (see
   [RFC4875]).  GMPLS signaling also allows for full and partial LSP
   protection; see [RFC4872] and [RFC4873].

   Note that standard GMPLS does not support different bandwidth in each
   direction of a bi-directional LSP. [GMPLS-ASYM], an Experimental
   document, provides procedures if asymmetric bandwidth bi-directional
   LSPs are required.


6. Link Management

   Link discovery has been specified for Ethernet in [802.1AB].  The
   benefits of running link discovery in large systems are significant.
   Link discovery may reduce configuration and reduce the possibility of
   undetected errors in configuration as well as exposing
   misconnections. However the 802.1AB capability is an optional
   feature, it is not necessarily operating before a link is
   operational, and it primarily supports the management plane.

   In the GMPLS context, LMP [RFC4204] has been defined to support GMPLS
   control plane link management and discovery features.  LMP also
   supports for the control plane the automated creation of unnumbered
   interfaces. If LMP is not used there is an additional configuration
   requirement for GMPLS link identifiers.  For large-scale
   implementations LMP is beneficial.  LMP also has optional fault
   management capabilities, primarily for opaque and transparent network
   technology.  With IEEE's newer CFM [802.1ag] and ITU's [Y.1731]
   capabilities, this optional capability may not be needed.  It is the
   goal of the GMPLS Ethernet architecture to allow the selection of the



Fedyk, et. al.                Informational                    [Page 16]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


   best tool set for the user
    needs. The full functionality of Ethernet CFM should be supported
   when using a GMPLS control plane.

   LMP and 802.1AB are relatively independent. The LMP capability should
   be sufficient to remove the need for 802.1AB but 802.1 AB can be run
   in parallel or independently if desired.  Figure 2 provides possible
   ways of using LMP, 802.1AB and 802.1ag in combination.

   Figure 2 illustrates the functional relationship of link management
   and OAM schemes.   It is expected that LMP would be used for control
   plane functions of link property correlation but that Ethernet
   mechanisms for OAM such as CFM, link trace etc would be used for data
   plane fault management and fault trace.

        +-------------+        +-------------+
        | +---------+ |        | +---------+ |
        | |         | |        | |         | |GMPLS
        | |  LMP    |-|<------>|-|  LMP    | |Link Property
        | |         | |        | |         | |Correlation
        | |  (opt)  | |GMPLS   | |  (opt)  | |
        | |         | |        | |         | | Bundling
        | +---------+ |        | +---------+ |
        | +---------+ |        | +---------+ |
        | |         | |        | |         | |
        | | 802.1AB |-|<------>|-| 802.1AB | |P2P
        | |  (opt)  | |Ethernet| |  (opt)  | |link identifiers
        | |         | |        | |         | |
        | +---------+ |        | +---------+ |
        | +---------+ |        | +---------+ |
        | |         | |        | |         | |End to End
   -----|-| 802.1ag |-|<------>|-| 802.1ag |-|-------
        | | Y.1731  | |Ethernet| | Y.1731  | |Fault Management
        | |  (opt)  | |        | |  (opt)  | |Performance
        | |         | |        | |         | |Management
        | +---------+ |        | +---------+ |
        +-------------+        +-------------+
             Switch 1    link      Switch 2

                 Figure 2: Logical Link Management Options











Fedyk, et. al.                Informational                    [Page 17]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


7. Path Computation and Selection

   GMPLS does not specify a specific method for selecting paths or
   supporting path computation. GMPLS allows for a wide range of
   possibilities supported from very simple path computation to very
   elaborate path coordination where a large number of coordinated paths
   are required.  Path computation can take the form of paths being
   computed in a fully distributed fashion, on a management station with
   local computation for rerouting, or on more sophisticated path
   computation servers.

   Eth-LSPs may be supported using any path selection or computation
   mechanism. As is the case with any GMPLS path selection function, and
   common to all path selection mechanisms, the path selection process
   should take into consideration Switching Capabilities and Encoding
   advertised for a particular interface. Eth-LSPs may also make use of
   the emerging path computation element and selection work; see
   [RFC4655]


8. Multiple VLANs

   This document allows for the support the signaling of Ethernet
   parameters across multiple VLANs supporting both contiguous Eth-LSP
   and Hierarchical Ethernet LSPs. The intention is to reuse GMPLS
   hierarchy for the support of Peer to Peer models, UNIs and NNIs.


9. Security Considerations

   The architecture for GMPLS controlled "transport" Ethernet assumes
   that the network consists of trusted devices, but does not require
   that the ports over which a UNI are defined are trusted, nor does
   equipment connected to these ports trusted. In general, these
   requirements are no different from the security requirements for
   operating any GMPLS network. Access to the trusted network SHALL only
   occur through the protocols defined for the UNI or NNI or through
   protected management interfaces.

   When in-band GMPLS signaling is used for the control plane the
   security of the control plane and the data plane may affect each
   other.  When out-of-band GMPLS signaling is used the control plane
   the data plane security is decoupled from the control plane and
   therefore the security of the data plane has less impact on overall
   security.

   Where GMPLS is applied to the control of VLAN only, the commonly
   known techniques for mitigation of Ethernet DOS attacks may be



Fedyk, et. al.                Informational                    [Page 18]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


   required on UNI ports.

   For a more comprehensive discussion on GMPLS security please see the
   MPLS and GMPLS Security Framework [SECURITY].  It is expected that
   solution documents will include a full analysis of the security
   issues that any protocol extensions introduce.


10. IANA Considerations

   No new values are specified in this document.


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.

   [RFC3471] Berger, L. (editor), "Generalized MPLS Signaling
             Functional Description", January 2003, RFC3471.

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

   [RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in
             Support of Generalized MPLS", RFC 4202, October 2005


11.2. Informative References

   [G.8031] ITU-T Draft Recommendation G.8031, Ethernet Protection
            Switching.

   [G.8011] ITU-T Draft Recommendation G. 8011, Ethernet over
            Transport - Ethernet services framework.

   [RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label
             Switching (GMPLS) Architecture", RFC 3495.

   [802.1AB] "IEEE Standard for Local and Metropolitan Area
              Networks, Station and Media Access Control
              Connectivity Discovery" (2004).





Fedyk, et. al.                Informational                    [Page 19]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


   [802.1ag] "IEEE Standard for Local and Metropolitan Area
              Networks - Virtual Bridged Local Area Networks
              - Amendment 5:Connectivity Fault Management",
              (2007).

   [802.1ah] "IEEE Standard for Local and Metropolitan Area
              Networks - Virtual Bridged Local Area Networks
              - Amendment 6: Provider Backbone Bridges", (2008)

   [802.1Qay] "IEEE standard for Provider Backbone Bridge Traffic
              Engineering", work in progress.

   [802.1Q] "IEEE standard for Virtual Bridged Local Area Networks
            802.1Q-2005", May 19, 2006

   [RFC4204] Lang. J. Editor, "Link Management Protocol (LMP)"
             RFC4204, October 2005

   [MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services
           Definitions - Phase I".

   [MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet
            Services Attributes Phase 1".

   [RFC4875] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to
             Multipoint TE LSPs", IETF RFC 4875, May 2007

   [RFC4655] Farrel, A. et.al., "Path Computation Element (PCE)
             Architecture", RCF 4655, August 2006.

   [RFC4872] Lang et.al., "RSVP-TE Extensions in support of
             End-to-End Generalized Multi-Protocol Label Switching
             (GMPLS)-based Recovery ", RFC 4872, May 2007.

   [RFC4873] Berger, L. et.al.,"MPLS Segment Recovery", RFC 4873, May
             2007.

   [Y.1731] ITU-T Draft Recommendation Y.1731(ethoam), " OAM
            Functions and Mechanisms for Ethernet based Networks ",
            work in progress.

   [GMPLS-ASYM] Berger, L. et al., "GMPLS Asymmetric Bandwidth
                Bidirectional LSPs", work in progress.

   [ETH-TSPEC] Papadimitriou, D., "Ethernet Traffic Parameters", work
               in progress.





Fedyk, et. al.                Informational                    [Page 20]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-arch-05.txt  September 1, 2009


   [SECURITY] Luyuan Fang, Ed., " Security Framework for MPLS
              and GMPLS Networks", work in progress.


12. Acknowledgments

   There were many people involved in the initiation of this work prior
   to this document. The GELS framework draft and the PBB-TE extensions
   drafts were two drafts the helped shape and justify this work. We
   acknowledge the work of these authors of these initial drafts:
   Dimitri Papadimitriou, Nurit Sprecher, Jaihyung Cho, Dave Allan,
   Peter Busschbach, Attila Takacs, Thomas Eriksson, Diego Caviglia,
   Himanshu Shah, Greg Sunderwood, Alan McGuire, Nabil Bitar.

   George Swallow contributed significantly to this document.


13. Author's Addresses

   Don Fedyk
   Alcatel-Lucent
   Groton, MA, 01450
   Phone: +1-978-467-5645
   Email: donald.fedyk@alcatel-lucent.com

   Lou Berger
   LabN Consulting, L.L.C.
   Phone: +1-301-468-9228
   Email: lberger@labn.net

   Loa Andersson
   Ericsson AB
   Phone: +46 10 717 52 13
   Email: loa.andersson@ericsson.com

















Fedyk, et. al.                Informational                    [Page 21]

Generated on: Tue Sep 1 11:27:49 EDT 2009