doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc6004.txt b/doc/rfc/rfc6004.txt
new file mode 100644
index 0000000..1bda59a
--- /dev/null
+++ b/doc/rfc/rfc6004.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         L. Berger
+Request for Comments: 6004                                          LabN
+Category: Standards Track                                       D. Fedyk
+ISSN: 2070-1721                                           Alcatel-Lucent
+                                                            October 2010
+
+
+       Generalized MPLS (GMPLS) Support for Metro Ethernet Forum
+                 and G.8011 Ethernet Service Switching
+
+Abstract
+
+   This document describes a method for controlling two specific types
+   of Ethernet switching via Generalized Multi-Protocol Label Switching
+   (GMPLS).  This document supports the types of switching corresponding
+   to the Ethernet services that have been defined in the context of the
+   Metro Ethernet Forum (MEF) and International Telecommunication Union
+   (ITU) G.8011.  Specifically, switching in support of Ethernet private
+   line and Ethernet virtual private line services are covered.  Support
+   for MEF- and ITU-defined parameters is also covered.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger & Fedyk               Standards Track                    [Page 1]
+
+RFC 6004            GMPLS Support for MEF and G.8011        October 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 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
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Overview ...................................................3
+      1.2. Conventions Used in This Document ..........................4
+   2. Common Signaling Support ........................................5
+      2.1. Ethernet Endpoint Identification ...........................5
+           2.1.1. Endpoint ID TLV .....................................5
+                  2.1.1.1. Procedures .................................6
+      2.2. Connection Identification ..................................6
+           2.2.1. Procedures ..........................................6
+      2.3. Traffic Parameters .........................................7
+           2.3.1. L2 Control Protocol TLV .............................7
+      2.4. Bundling and VLAN Identification ...........................9
+   3. EPL Service .....................................................9
+      3.1. EPL Service Parameters .....................................9
+   4. EVPL Service ...................................................10
+      4.1. EVPL Generalized Label Format .............................10
+      4.2. Egress VLAN ID Control and VLAN ID Preservation ...........11
+      4.3. Single Call - Single LSP ..................................11
+      4.4. Single Call - Multiple LSPs ...............................11
+   5. IANA Considerations ............................................12
+      5.1. Endpoint ID Attributes TLV ................................12
+      5.2. Line LSP Encoding .........................................12
+      5.3. Ethernet Virtual Private Line (EVPL) Switching Type .......12
+   6. Security Considerations ........................................13
+   7. References .....................................................13
+      7.1. Normative References ......................................13
+      7.2. Informative References ....................................14
+   Acknowledgments ...................................................14
+
+
+
+
+
+
+Berger & Fedyk               Standards Track                    [Page 2]
+
+RFC 6004            GMPLS Support for MEF and G.8011        October 2010
+
+
+1.  Introduction
+
+   [MEF6] and [G.8011] provide parallel frameworks for defining network-
+   oriented characteristics of Ethernet services in transport networks.
+   The framework discusses general Ethernet connection characteristics,
+   Ethernet User-Network Interfaces (UNIs) and Ethernet Network-Network
+   Interfaces (NNIs).  Within this framework, [G.8011.1] defines the
+   Ethernet Private Line (EPL) service and [G.8011.2] defines the
+   Ethernet Virtual Private Line (EVPL) service. [MEF6] covers both
+   service types.  [MEF10.1] defines service parameters and [MEF11]
+   provides UNI requirements and framework.
+
+   [MEF6] and [G.8011] are focused on service interfaces and not the
+   underlying technology used to support the service.  For example,
+   [G.8011] refers to the defined services being transported over one of
+   several possible "server layers".  This document focuses on the types
+   of switching that may directly support these services and provides a
+   method for GMPLS-based control of such switching technologies.  This
+   document defines the GMPLS extensions needed to support such
+   switching, but does not define the UNI or External NNI (E-NNI)
+   reference points.  See [RFC6005] for a description of the UNI
+   reference point.  This document makes use of the traffic parameters
+   defined in [RFC6003] and the generic extensions defined in [RFC6002].
+
+1.1.  Overview
+
+   This document uses a common approach to supporting the switching
+   corresponding to the Ethernet services defined in [MEF6], [G.8011.1],
+   and [G.8011.2].  The approach builds on standard GMPLS mechanisms to
+   deliver the required control capabilities.  This document reuses the
+   GMPLS mechanisms specified in [RFC3473] and [RFC4974].  The document
+   uses the extensions defined in [RFC6002].
+
+   Two types of connectivity between Ethernet endpoints are defined in
+   [MEF6] and [G.8011]: point-to-point (P2P) and multipoint-to-
+   multipoint (MP2MP). [MEF6] uses the term Ethernet Line (E-line) to
+   refer to point-to-point virtual connections, and Ethernet LAN (E-LAN)
+   to refer to multipoint-to-multipoint virtual connections.  [G.8011]
+   also identifies point-to-multipoint (P2MP) as an area for "further
+   study".  Within the context of GMPLS, support is defined for point-
+   to-point unidirectional and bidirectional Traffic Engineering Label
+   Switched Paths (TE LSPs), see [RFC3473], and unidirectional point-to-
+   multipoint TE LSPs, see [RFC4875].
+
+   Support for P2P and MP2MP services is defined by [G.8011] and
+   required by [MEF11].  Note that while [MEF11] and [G.8011] discuss
+   MP2MP, [G.8011.1] and [G.8011.2] only define support for P2P.  There
+   is a clear correspondence between E-Line/P2P service and GMPLS P2P TE
+
+
+
+Berger & Fedyk               Standards Track                    [Page 3]
+
+RFC 6004            GMPLS Support for MEF and G.8011        October 2010
+
+
+   LSPs, and support for such LSPs is included in the scope of this
+   document.  There is no such clear correspondence between E-LAN/MP2MP
+   service and GMPLS TE LSPs.  Although, it is possible to emulate this
+   service using multiple P2P or P2MP TE LSPs, the definition of support
+   for MP2MP service is left for future study and is not addressed in
+   this document.
+
+   [MEF11] defines multiple types of control for UNI Ethernet services.
+   In MEF UNI Type 1, services are configured manually.  In MEF UNI Type
+   2, services may be configured manually or via a link management
+   interface.  In MEF UNI Type 3, services may be established and
+   managed via a signaling interface.  From the MEF perspective, this
+   document, along with [RFC6005], is aimed at the network control
+   needed to support the MEF UNI Type 3 mode of operation.
+
+   [G.8011.1], [G.8011.2], and [MEF11], together with [MEF10.1], define
+   a set of service attributes that are associated with each Ethernet
+   connection.  Some of these attributes are based on the provisioning
+   of the local physical connection and are not modifiable or selectable
+   per connection.  Other attributes are specific to a particular
+   connection or must be consistent across the connection.  The approach
+   taken in this document to communicate these attributes is to exclude
+   the static class of attributes from signaling.  This class of
+   attributes will not be explicitly discussed in this document.  The
+   other class of attributes is communicated via signaling and will be
+   reviewed in the sections below.  The major attributes that will be
+   supported in signaling include:
+
+      - Endpoint identifiers
+      - Connection identifiers
+      - Traffic parameters (see [RFC6003])
+      - Bundling / VLAN IDs map (EVPL only)
+      - VLAN ID Preservation (EVPL only)
+
+   Common procedures used to support Ethernet LSPs are described in
+   Section 2 of this document.  Procedures related to the signaling of
+   switching in support of EPL services are described in Section 3.
+   Procedures related to the signaling of switching in support of EVPL
+   services are described in Section 4.
+
+1.2.  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].
+
+
+
+
+
+
+Berger & Fedyk               Standards Track                    [Page 4]
+
+RFC 6004            GMPLS Support for MEF and G.8011        October 2010
+
+
+2.  Common Signaling Support
+
+   This section describes the common mechanisms for supporting GMPLS
+   signaled control of LSPs that provide Ethernet connections as defined
+   in [MEF11], [G.8011.1], and [G.8011.2].
+
+   Except as specifically modified in this document, the procedures
+   related to the processing of RSVP objects are not modified by this
+   document.  The relevant procedures in existing documents, such as
+   [RFC3473], MUST be followed in all cases not explicitly described in
+   this document.
+
+2.1.  Ethernet Endpoint Identification
+
+   Ethernet endpoint identifiers, as they are defined in [G.8011] and
+   [MEF10.1], differ significantly from the identifiers used by GMPLS.
+   Specifically, the Ethernet endpoint identifiers are character based
+   as opposed to the GMPLS norm of being IP address based.
+
+   The approach taken by this document to address this disparity
+   leverages the solution used for connection identification, see
+   Section 2.2 and [RFC4974], and a new CALL_ATTRIBUTES TLV defined in
+   this document.  The solution makes use of the [RFC4974] short Call
+   ID, and supports the Ethernet endpoint identifier similar to how
+   [RFC4974] supports the long Call ID.  That is, the SENDER_TEMPLATE
+   and SESSION objects carry IP addresses and a short Call ID, and long
+   identifiers are carried in the CALL_ATTRIBUTES object.  As with the
+   long Call ID, the Ethernet endpoint identifier is typically only
+   relevant at the ingress and egress nodes.
+
+   As defined below, the Ethernet endpoint identifier is carried in the
+   CALL_ATTRIBUTES object in a new TLV.  The new TLV is referred to as
+   the Endpoint ID TLV.  The processing of the Endpoint ID TLV parallels
+   the processing of the long Call ID in [RFC4974].  This processing
+   requires the inclusion of the CALL_ATTRIBUTES object in a Notify
+   message.
+
+2.1.1.  Endpoint ID TLV
+
+   The Endpoint ID TLV follows the Attributes TLV format defined in
+   [RFC6001].  The Endpoint ID TLV has the following format:
+
+
+
+
+
+
+
+
+
+
+Berger & Fedyk               Standards Track                    [Page 5]
+
+RFC 6004            GMPLS Support for MEF and G.8011        October 2010
+
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Type (30)           |      Length (variable)        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Endpoint ID                          |
+   |                              ...                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type and Length fields are defined in [RFC6001].  Note that as
+   defined in [RFC6001], the Length field is set to length of the whole
+   TLV including the Type, Length, and Endpoint ID fields.
+
+   Endpoint ID
+
+      The Endpoint ID field is a variable-size field that carries an
+      endpoint identifier, see [MEF10.1] and [G.8011].  This field MUST
+      be null padded as defined in [RFC6001].
+
+2.1.1.1.  Procedures
+
+   The use of the Endpoint ID TLV is required during Call management.
+   When a Call is established or torn down per [RFC4974], a
+   CALL_ATTRIBUTES object containing an Endpoint ID TLV MUST be included
+   in the Notify message along with the long Call ID.
+
+   Short Call ID processing, including those procedures related to Call
+   and connection processing, is not modified by this document and MUST
+   proceed according to [RFC4974].
+
+2.2.  Connection Identification
+
+   Signaling for Ethernet connections follows the procedures defined in
+   [RFC4974].  In particular, the Call-related mechanisms are used to
+   support endpoint identification.  In the context of Ethernet
+   connections, a Call is only established when one or more LSPs
+   (connections in [RFC4974] terms) are needed.  An LSP will always be
+   established within the context of a Call and, typically, only one LSP
+   will be used per Call.  See Section 4.4 for the case where more than
+   one LSP may exist within a Call.
+
+2.2.1.  Procedures
+
+   Any node that supports Ethernet connections MUST be able to accept
+   and process Call setups per [RFC4974].  Ethernet connections
+   established according to this document MUST treat the Ethernet
+   (virtual) connection identifier as the long "Call identifier (ID)",
+
+
+
+
+Berger & Fedyk               Standards Track                    [Page 6]
+
+RFC 6004            GMPLS Support for MEF and G.8011        October 2010
+
+
+   described in [RFC4974].  The short Call ID MUST be used as described
+   in [RFC4974].  Use of the LINK_CAPABILITY object is OPTIONAL.  Both
+   network-initiated and user-initiated Calls MUST be supported.
+
+   When establishing an Ethernet connection, the initiator MUST first
+   establish a Call per the procedures defined in [RFC4974].  LSP
+   management, including removal and addition, then follows [RFC4974].
+   As stated in [RFC4974], once a Call is established, the initiator
+   SHOULD establish at least one Ethernet LSP.  Also, when the last LSP
+   associated with a Call is removed, the Call SHOULD be torn down per
+   the procedures in [RFC4974].
+
+2.3.  Traffic Parameters
+
+   Several types of service attributes are carried in the traffic
+   parameters defined in [RFC6003].  These parameters are carried in the
+   FLOWSPEC and TSPEC objects as discussed in [RFC6003].  The service
+   attributes that are carried are:
+
+      - Bandwidth Profile
+      - VLAN Class of Service (CoS) Preservation
+      - Layer 2 Control Protocol (L2CP) Processing (see Section 2.3.1)
+
+   Ethernet connections established according to this document MUST use
+   the traffic parameters defined in [RFC6003] in the FLOWSPEC and TSPEC
+   objects.  Additionally, the Switching Granularity field of the
+   Ethernet SENDER_TSPEC object MUST be set to zero (0).
+
+2.3.1.  L2 Control Protocol TLV
+
+   [MEF10.1], [G.8011.1], and [G.8011.2] define service attributes that
+   impact the layer two (L2) control protocol processing at the ingress
+   and egress.  [RFC6003] does not define support for these service
+   attributes, but does allow the attributes to be carried in a TLV.
+   This section defines the L2CP TLV to carry the L2CP-processing-
+   related service attributes.
+
+   The format of the L2 Control Protocol (L2CP) TLV is as follows:
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             Type=3            |           Length=8            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | IL2CP | EL2CP |                  Reserved                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+Berger & Fedyk               Standards Track                    [Page 7]
+
+RFC 6004            GMPLS Support for MEF and G.8011        October 2010
+
+
+      See [RFC6003] for a description of the Type and Length fields.
+      Per [RFC6003], the Type field MUST be set to three (3), and the
+      Length field MUST be set to eight (8) for the L2CP TLV.
+
+      Ingress Layer 2 Control Processing (IL2CP): 4 bits
+
+         This field controls processing of Layer 2 Control Protocols on
+         a receiving interface.  Valid usage is service specific, see
+         [MEF10.1], [G.8011.1], and [G.8011.2].
+
+         Permitted values are:
+
+      Value  Description           Reference
+      -----  -----------           ---------
+        0    Reserved
+        1    Discard/Block         [MEF10.1], [G.8011.1], and [G.8011.2]
+        2    Peer/Process          [MEF10.1], [G.8011.1], and [G.8011.2]
+        3    Pass to EVC/Pass      [MEF10.1], [G.8011.1], and [G.8011.2]
+        4    Peer and Pass to EVC  [MEF10.1]
+
+      Egress Layer 2 Control Processing (EL2CP): 4 bits
+
+   This field controls processing of Layer 2 Control Protocols on a
+   transmitting interface.  When MEF services are used a value of 1 MUST
+   be used, other valid usage is service specific, see [G.8011.1] and
+   [G.8011.2].
+
+   Permitted values are:
+
+   Value  Description             Reference
+   -----  -----------             ---------
+     0    Reserved
+     1    Based on IL2CP Value    [MEF10.1]
+     2    Generate                [G.8011.1] and [G.8011.2]
+     3    None                    [G.8011.1] and [G.8011.2]
+     4    Reserved
+
+      Reserved: 24 bits
+
+   This field is reserved.  It MUST be set to zero on transmission and
+   MUST be ignored on receipt.  This field SHOULD be passed unmodified
+   by transit nodes.
+
+   Ethernet connections established according to this document MUST
+   include the L2CP TLV in the [RFC6003] traffic parameters carried in
+   the FLOWSPEC and TSPEC objects.
+
+
+
+
+
+Berger & Fedyk               Standards Track                    [Page 8]
+
+RFC 6004            GMPLS Support for MEF and G.8011        October 2010
+
+
+2.4.  Bundling and VLAN Identification
+
+   The control of bundling and listing of VLAN identifiers is only
+   supported for EVPL services.  EVPL service specific details are
+   provided in Section 4.
+
+3.  EPL Service
+
+   Both [MEF6] and [G.8011.1] define an Ethernet Private Line (EPL)
+   service.  In the words of [G.8011.1], EPL services carry "Ethernet
+   characteristic information over dedicated bandwidth, point-to-point
+   connections, provided by SDH, ATM, MPLS, PDH, ETY or OTH server layer
+   networks".  [G.8011.1] defines two types of Ethernet Private Line
+   (EPL) services.  Both types present a service where all data
+   presented on a port is transported to the corresponding connected
+   port.  The types differ in that EPL type 1 service operates at the
+   MAC frame layer, while EPL type 2 service operates at the line (e.g.,
+   8B/10B) encoding layer. [MEF6] only defines one type of EPL service,
+   and it matches [G.8011.1] EPL type 1 service.  Signaling for LSPs
+   that support both types of EPL services are detailed below.
+
+3.1.  EPL Service Parameters
+
+   Signaling for the EPL service types only differ in the LSP Encoding
+   Type used.  The LSP Encoding Type used for each are:
+
+      EPL Service     LSP Encoding Type (Value)  Reference
+      -----------     -------------------------  ---------
+      Type 1/MEF      Ethernet (2)               [RFC3471]
+      Type 2          Line (e.g., 8B/10B)(14)    [RFC6004]
+
+   The other LSP parameters specific to EPL Service are:
+
+      Parameter       Name (Value)       Reference
+      --------------  -----------------  ------------------
+      Switching Type  DCSC (125)         [RFC6002]
+      G-PID           Ethernet PHY (33)  [RFC3471][RFC4328]
+
+   The parameters defined in this section MUST be used when establishing
+   and controlling LSPs that provide EPL service type Ethernet
+   switching.  The procedures defined in Section 2 and the other
+   procedures defined in [RFC3473] for the establishment and management
+   of bidirectional LSPs MUST be followed when establishing and
+   controlling LSPs that provide EPL service type Ethernet switching.
+
+
+
+
+
+
+
+Berger & Fedyk               Standards Track                    [Page 9]
+
+RFC 6004            GMPLS Support for MEF and G.8011        October 2010
+
+
+4.  EVPL Service
+
+   EVPL service is defined within the context of both [G.8011.2] and
+   [MEF6].  EVPL service allows for multiple Ethernet connections per
+   port, each of which supports a specific set of VLAN IDs.  The service
+   attributes identify different forms of EVPL services, e.g., bundled
+   or unbundled.  Independent of the different forms, LSPs supporting
+   EVPL Ethernet type switching are signaled using the same mechanisms
+   to communicate the one or more VLAN IDs associated with a particular
+   LSP (Ethernet connection).
+
+   The relevant [RFC3471] parameter values that MUST be used for EVPL
+   connections are:
+
+      Parameter          Name (Value)       Reference
+      --------------     -----------------  ------------------
+      Switching Type     EVPL (30)          [RFC6004]
+      LSP Encoding Type  Ethernet (2)       [RFC3471]
+      G-PID              Ethernet PHY (33)  [RFC3471][RFC4328]
+
+   As with EPL, the procedures defined in Section 2 and the other
+   procedures defined in [RFC3473] for the establishment and management
+   of bidirectional LSPs MUST be followed when establishing and
+   controlling LSPs that provide EVPL service type Ethernet switching.
+
+   LSPs that provide EVPL service type Ethernet switching MUST use the
+   EVPL Generalized Label Format per Section 4.1, and the Generalized
+   Channel_Set Label Objects per [RFC6002].  A notable implication of
+   bundled EVPL services and carrying multiple VLAN IDs is that a Path
+   message may grow to be larger than a single (fragmented or non-
+   fragmented) IP packet.  The basic approach to solving this is to
+   allow for multiple LSPs which are associated with a single Call, see
+   Section 2.2.  The specifics of this approach are describe below in
+   Section 4.4.
+
+4.1.  EVPL Generalized Label Format
+
+   Bundled EVPL services require the use of a service-specific label,
+   called the EVPL Generalized Label.  For consistency, non-bundled EVPL
+   services also use the same label.
+
+   The format for the Generalized Label (Label Type value 2) used with
+   EVPL services is:
+
+
+
+
+
+
+
+
+Berger & Fedyk               Standards Track                   [Page 10]
+
+RFC 6004            GMPLS Support for MEF and G.8011        October 2010
+
+
+      0                   1
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Rsvd  |        VLAN ID        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Reserved: 4 bits
+
+         This field is reserved.  It MUST be set to zero on transmission
+         and MUST be ignored on receipt.  This field SHOULD be passed
+         unmodified by transit nodes.
+
+      VLAN ID: 12 bits
+
+         A VLAN identifier.
+
+4.2.  Egress VLAN ID Control and VLAN ID Preservation
+
+   When an EVPL service is not configured for both bundling and VLAN ID
+   preservation, [MEF6] allows VLAN ID mapping.  In particular, the
+   single VLAN ID used at the incoming interface of the ingress may be
+   mapped to a different VLAN ID at the outgoing interface at the egress
+   UNI.  Such mapping MUST be requested and signaled based on the
+   explicit label control mechanism defined in [RFC3473] and clarified
+   in [RFC4003].
+
+   When the explicit label control mechanism is not used, VLAN IDs MUST
+   be preserved, i.e., not modified, across an LSP.
+
+4.3.  Single Call - Single LSP
+
+   For simplicity in management, a single LSP SHOULD be used for each
+   EVPL type LSP whose Path and Resv messages fit within a single
+   unfragmented IP packet.  This allows the reuse of all standard LSP
+   modification procedures.  Of particular note is the modification of
+   the VLAN IDs associated with the Ethernet connection.  Specifically,
+   [RFC6002], make-before-break procedures SHOULD be used to modify the
+   Channel_Set LABEL object.
+
+4.4.  Single Call - Multiple LSPs
+
+   Multiple LSPs MAY be used to support an EVPL service connection.  All
+   such LSPs MUST be established within the same Call and follow Call-
+   related procedures, see Section 2.2.  The primary purpose of multiple
+   LSPs is to support the case in which the related objects result in a
+   Path message being larger than a single unfragmented IP packet.
+
+
+
+
+
+Berger & Fedyk               Standards Track                   [Page 11]
+
+RFC 6004            GMPLS Support for MEF and G.8011        October 2010
+
+
+   When using multiple LSPs, all LSPs associated with the same Call/EVPL
+   connection MUST be signaled with the same LSP objects with the
+   exception of the SENDER_TEMPLATE, SESSION, and label-related objects.
+   All such LSPs SHOULD share resources.  When using multiple LSPs, VLAN
+   IDs MAY be added to the EVPL connection using either a new LSP or
+   make-before-break procedures, see [RFC3209].  Make-before-break
+   procedures on individual LSPs SHOULD be used to remove VLAN IDs.
+
+   To change other service parameters it is necessary to re-signal all
+   LSPs associated with the Call via make-before-break procedures.
+
+5.  IANA Considerations
+
+   IANA has assigned new values for namespaces defined in this document
+   and summarized in this section.  The registries are available from
+   http://www.iana.org.
+
+5.1.  Endpoint ID Attributes TLV
+
+   IANA has made the following assignment in the "Call Attributes TLV"
+   section of the "RSVP Parameters" registry.
+
+   Type  Name         Reference
+   ----  -----------  ---------
+   2    Endpoint ID   [RFC6004]
+
+5.2.  Line LSP Encoding
+
+   IANA has made the following assignment in the "LSP Encoding Types"
+   section of the "GMPLS Signaling Parameters" registry.
+
+   Value   Type                                 Reference
+   -----   ---------------------------          ---------
+      14   Line (e.g., 8B/10B)                  [RFC6004]
+
+5.3.  Ethernet Virtual Private Line (EVPL) Switching Type
+
+   IANA has made the following assignment in the "Switching Types"
+   section of the "GMPLS Signaling Parameters" registry.
+
+   Value   Type                                      Reference
+   -----   ------------------------------------      ---------
+      30   Ethernet Virtual Private Line (EVPL)      [RFC6004]
+
+   The assigned value has been reflected in IANAGmplsSwitchingTypeTC of
+   the IANA-GMPLS-TC-MIB available from http://www.iana.org.
+
+
+
+
+
+Berger & Fedyk               Standards Track                   [Page 12]
+
+RFC 6004            GMPLS Support for MEF and G.8011        October 2010
+
+
+6.  Security Considerations
+
+   This document introduces new message object formats for use in GMPLS
+   signaling [RFC3473].  It does not introduce any new signaling
+   messages, nor change the relationship between Label Switching Routers
+   (LSRs) that are adjacent in the control plane.  As such, this
+   document introduces no additional security considerations to those
+   discussed in [RFC3473].
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+              Tunnels", RFC 3209, December 2001.
+
+   [RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Signaling Functional Description", RFC
+              3471, January 2003.
+
+   [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Signaling Resource ReserVation Protocol-
+              Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
+              January 2003.
+
+   [RFC4003]  Berger, L., "GMPLS Signaling Procedure for Egress
+              Control", RFC 4003, February 2005.
+
+   [RFC4974]  Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS)
+              RSVP-TE Signaling Extensions in Support of Calls", RFC
+              4974, August 2007.
+
+   [RFC6001]  Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard,
+              D. and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol
+              Extensions for Multi-Layer and Multi-Region Networks
+              (MLN/MRN)", RFC 6001, October 2010.
+
+   [RFC6002]  Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Data
+              Channel Switching Capable (DCSC) and Channel Set Label
+              Extensions", RFC 6002, October 2010.
+
+   [RFC6003]  Papadimitriou, D., "Ethernet Traffic Parameters," RFC
+              6003, October 2010.
+
+
+
+
+Berger & Fedyk               Standards Track                   [Page 13]
+
+RFC 6004            GMPLS Support for MEF and G.8011        October 2010
+
+
+7.2.  Informative References
+
+   [G.8011]   ITU-T G.8011/Y.1307, "Ethernet over Transport Ethernet
+              services framework", August 2004.
+
+   [G.8011.1] ITU-T G.G.8011.1/Y.1307.1, "Ethernet private line
+              service", August 2004.
+
+   [G.8011.2] ITU-T G.8011.2/Y.1307.2, "Ethernet virtual private line
+              service", September 2005.
+
+   [MEF6]     The Metro Ethernet Forum, "Ethernet Services Definitions -
+              Phase I", MEF 6, June 2004.
+
+   [MEF10.1]  The Metro Ethernet Forum, "Ethernet Services Attributes
+              Phase 2", MEF 10.1, November 2006.
+
+   [MEF11]    The Metro Ethernet Forum , "User Network Interface (UNI)
+              Requirements and Framework", MEF 11, November 2004.
+
+   [RFC4328]  Papadimitriou, D., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Signaling Extensions for G.709 Optical
+              Transport Networks Control", RFC 4328, January 2006.
+
+   [RFC4875]  Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
+              Yasukawa, Ed., "Extensions to Resource Reservation
+              Protocol - Traffic Engineering (RSVP-TE) for Point-to-
+              Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May
+              2007.
+
+   [RFC6005]  Berger, L. and D. Fedyk,"Generalized MPLS (GMPLS) Support
+              for Metro Ethernet Forum and G.8011 User Network Interface
+              (UNI)", RFC 6005, October 2010.
+
+Acknowledgments
+
+   Dimitri Papadimitriou provided substantial textual contributions to
+   this document and coauthored earlier versions of this document.
+
+   The authors would like to thank Evelyne Roch, Stephen Shew, and Yoav
+   Cohen for their valuable comments.
+
+
+
+
+
+
+
+
+
+
+Berger & Fedyk               Standards Track                   [Page 14]
+
+RFC 6004            GMPLS Support for MEF and G.8011        October 2010
+
+
+Authors' Addresses
+
+   Lou Berger
+   LabN Consulting, L.L.C.
+   Phone: +1-301-468-9228
+   EMail: lberger@labn.net
+
+   Don Fedyk
+   Alcatel-Lucent
+   Groton, MA 01450
+   Phone: +1-978-467-5645
+   EMail: donald.fedyk@alcatel-lucent.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger & Fedyk               Standards Track                   [Page 15]
+