diff options
Diffstat (limited to 'doc/rfc/rfc6004.txt')
| -rw-r--r-- | doc/rfc/rfc6004.txt | 843 |
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] + |