Internet Engineering Task Force (IETF) D. Fedyk Request for Comments: 6060 Alcatel-Lucent Category: Standards Track H. Shah ISSN: 2070-1721 Ciena N. Bitar Verizon A. Takacs Ericsson March 2011 Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)
AbstractThis specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework and describes the technology- specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE). The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point-to-point (P2P) and point-to-multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. 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/rfc6060. Copyright Notice Copyright (c) 2011 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 1. Introduction ....................................................3 1.1. Co-Authors .................................................3 2. Terminology .....................................................4 2.1. PBB-TE and GMPLS Terminology ...............................5 2.2. Conventions Used in This Document ..........................6 3. Creation and Maintenance of PBB-TE Paths Using GMPLS ............6 3.1. Shared Forwarding ..........................................9 3.2. P2P Connections Procedures for Shared Forwarding ..........10 4. Specific Procedures ............................................10 4.1. P2P Ethernet LSPs .........................................10 4.1.1. P2P Path Maintenance ...............................11 4.2. P2MP Ethernet-LSPs ........................................12 4.3. PBB-TE Ethernet Label .....................................12 4.4. Protection Paths ..........................................13 4.5. Service Instance Identification ...........................13 5. Error Conditions ...............................................15 5.1. ESP-VID-Related Errors ....................................15 5.1.1. Invalid ESP-VID Value in the PBB-TE Ethernet Label .....................................15 5.1.2. Allocated ESP-VID Range is Exhausted ...............16 5.2. Invalid MAC Address .......................................16 6. Security Considerations ........................................16 7. IANA Considerations ............................................17 8. References .....................................................17 8.1. Normative References ......................................17 8.2. Informative References ....................................19 9. Acknowledgments ................................................19
IEEE802.1Qay] standard supports the establishment of explicitly routed traffic engineered paths within Provider Backbone Bridged (PBB) networks. PBB-TE allows the disabling of: - the Spanning Tree Protocol - unknown destination address forwarding - source address learning for administratively selected VLAN Identifiers. With PBB-TE an external provisioning system or control plane can be used to configure static entries in the managed objects of bridges and so establish traffic engineered paths in the network. Generalized MPLS (GMPLS) [RFC3945] is a family of control plane protocols designed to operate in connection oriented and traffic engineering transport networks. GMPLS is applicable to a range of network technologies including L2SC networks (Layer 2 Switching Capable). The purpose of this document is to specify extensions for a GMPLS-based control plane to manage PBB-TE explicitly routed traffic engineered paths. This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework document [RFC5828].
Nurit Sprecher Nokia Siemens Networks, GmbH & Co. KG COO RTP IE Fixed 3 Hanagar St. Neve Ne'eman B, 45241 Hod Hasharon, Israel EMail: firstname.lastname@example.org Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: email@example.com IEEE802.1ah] [IEEE802.1Qay]: - BCB Backbone Core Bridge - BEB Backbone Edge Bridge - B-MAC Backbone MAC - B-VID Backbone VLAN ID - B-VLAN Backbone VLAN - CBP Customer Backbone Port - CCM Continuity Check Message - CNP Customer Network Port - C-MAC Customer MAC - C-VID Customer VLAN ID - C-VLAN Customer VLAN - ESP Ethernet Switched Path - ESP-MAC SA ESP Source MAC Address - ESP-MAC DA ESP Destination MAC Address - ESP-VID ESP VLAN ID - Eth-LSP Ethernet Label Switched Path - IB-BEB A BEB comprised of both I- and B-components - I-SID Ethernet Service Instance Identifier - TAG An Ethernet Header Field with Type and Values - MAC Media Access Control - PBB Provider Backbone Bridges - PBB-TE Provider Backbone Bridges Traffic Engineering - PIP Provider Instance Port - PNP Provider Network Port - PS Protection Switching - P2P Point-to-Point - P2MP Point-to-Multipoint - SVL Shared VLAN Learning
- TESI Traffic Engineering Service Instance - VID VLAN ID - VIP Virtual Instance Port - VLAN Virtual LAN IEEE802.1Qay] defines some additional terminology to clarify the PBB-TE functions. We repeat these here in expanded context to translate from IEEE to GMPLS terminology. The terms "bridge" and "switch" are used interchangeably in this document. The signaling extensions described here apply equally well to a PBB-TE-capable bridge supporting GMPLS signaling or to a GMPLS- capable switch supporting Ethernet PBB-TE forwarding. - Ethernet Switched Path (ESP): A provisioned traffic engineered unidirectional connectivity path between two or more Customer Backbone Ports (CBPs) that extends over a Provider Backbone Bridge Network (PBBN). The path is identified by the 3-tuple <ESP-MAC DA, ESP-MAC SA, ESP- VID>. An ESP is point-to-point (P2P) or point-to-multipoint (P2MP). An ESP is analogous to a (unidirectional) point-to- point or point-to-multipoint LSP. We use the term Ethernet-LSP (Eth-LSP) for GMPLS established ESPs. - Point-to-Point ESP: An ESP between two CBPs. The ESP-DA and the ESP-SA in the ESP's 3-tuple identifier are the individual MAC addresses of the two CBPs. - Point-to-Multipoint ESP: An ESP among one root CBP and n leaf CBPs. The ESP-DA in the ESP's 3-tuple identifier is a group MAC address identifying the n leaf CBPs, and the ESP-SA is the individual MAC address of the root. - Point-to-Point PBB-TE Service Instance (P2P TESI): A service instance supported by two point-to-point ESPs where the ESPs' endpoints have the same CBP MAC addresses. The two unidirectional ESPs are forming a bidirectional service. The PBB-TE standard [IEEE802.1Qay] notes the following: for reasons relating to TE service monitoring diagnostics, operational simplicity, etc., the IEEE PBB-TE standard assumes that the point-to-point ESPs associated with a point-to-point TESI are
co-routed. Support for a point-to-point TE services that comprises non-co-routed ESPs is problematic, and is not defined in this standard. Hence, a GMPLS bidirectional LSP is analogous to a P2P TE Service Instance. We use the term "bidirectional Ethernet-LSP" for GMPLS-established P2P PBB-TE Service Instances. RFC2119]. Figure 1. A B-component refers to the structure and mechanisms that support the relaying of frames identified by Backbone VLANs in a Provider Backbone Bridge. An I-component refers to the structure and mechanisms that support the relaying of frames identified by service instances (I-SIDs) in a Provider Backbone Bridge. PBB and PBB-TE relay frames with added I-Component TAGs in the I-component and VLAN TAGs in the B-component. PBB and PBB-TE forward frames based on VLAN ID in the VLAN TAG (in the PBB case a B-VID) until the destination MAC address is supported locally by a B-component on this bridge indicating the destination has been reached. At that point, the B-VLAN tag is removed and processing or forwarding on the next TAG begins (in the PBB case an I-Component TAG) until the I-component identified by the I-SID is reached. At the I-component, the I-Component TAG is removed and the next Ethernet type identifies the TAG, etc. An Ethernet service supported by a PBB-TE TESI is always attached to a Customer Network Port (CNP) of the I-component. A Service Instance Identifier (I-SID) is assigned for the service. I-SIDs are only looked at by source and destination (edge) bridges, so I-SIDs are transparent to path operations and MAY be signaled. The I- and B-components have internal ports that are connected via an internal LAN. These internal ports are the Provider Instance Ports (PIPs) and
Customer Backbone Ports (CBPs). PIPs and CBPs are not visible outside the IB-BEB. ESPs are always originated and terminated on CBP ports and use the MAC address of that port. The I-component encapsulates the service frames arriving from the CNP by adding an I-SID and a complete Ethernet MAC header with an ESP-MAC DA and ESP-MAC SA. The B-component adds the ESP-VID. This document defines extensions to GMPLS to establish ESPs and TESIs. As can be seen from the above, this requires configuration of both the I- and B-components of the IB-BEBs connected by the ESPs. In the GMPLS control plane, TE Router IDs are used to identify the IB-BEBs and Backbone Core Bridges (BCBs), and TE Links describe links connected to PNPs and CNPs. TE Links are not associated with CBPs or PIPs. Note that since multiple internal CBPs may exist, an IB-BEB receiving a PATH message MUST be able to determine the appropriate CBP that is the termination point of the Eth-LSP. To this end, IB-BEBs SHOULD advertise the CNP TE Links in the GMPLS control plane and RSVP-TE signaling SHOULD use the CNP TE Links to identify the termination point of Eth-LSPs. An IB-BEB receiving a PATH message specifying one of its CNPs can locally determine which CBPs have internal connectivity to the I-component supporting the given CNP. In the case that there is more than one suitable CBP, and no I-SID information is provided in the PATH message or previously in the associated Call setup, then the IB-BEB can decide freely which CBP to assign to the requested connection. On the other hand, if there is information on the service (I-SID) that the given ESP will support, then the IB-BEB MUST first determine which PIP and associated CBP is configured with the I-SID and MUST assign that CBP to the ESP.
Backbone Edge Bridge (BEB) +------------------------------------------------------+ | <TE - Router ID > | | | | I-Component Relay B-Component Relay | | +-----------------------+ +---------------------+ | | | +---+ | | B-VID | | | | |VIP| | | +---+ +---+ | | <TE Link> | | +---+ | +---|CBP| |PNP|------ | | | | | +---+ +---+ | | | | +---+ +---+ | | | | | ------|CNP| |PIP|----+ | | | | | +---+ +---+ | | | | | +-----------------------+ +---------------------+ | | | | PBB Edge Bridge | +------------------------------------------------------+ ^--------Configured--------------^ ^-----------GMPLS or Configured------^ Figure 1: IB-BEBs and GMPLS Identifiers Control TE Router ID TE Router ID Plane | (TE Link) | V | V +----+ | +-----+ Data | | | | | Plane | | V label=ESP:VID/MAC DA | | -----N N----------------------------N N---------- | | PBB-TE | | \ Network | | / | Or +----+ /+-----+ Customer BCB ESP:MAC IB-BEB Facing Ethernet Ports Figure 2: Ethernet/GMPLS Addressing and Label Space PBB-TE defines the tuple of <ESP-MAC DA, ESP-MAC SA, ESP-VID> as a unique connection identifier in the data plane, but the forwarding operation only uses the ESP-MAC DA and the ESP-VID in each direction. The ESP-VID typically comes from a small number of VIDs dedicated to PBB-TE. ESP-VIDs can be reused across ESPs. There is no requirement that ESP-VIDs for two ESPs that form a P2P TESI be the same.
When configuring an ESP with GMPLS, the ESP-MAC DA and ESP-VID are carried in a generalized label object and are assigned hop by hop, but are invariant within a domain. This invariance is similar to GMPLS operation in transparent optical networks. As is typical with other technologies controlled by GMPLS, the data plane receiver MUST accept, and usually assigns, labels from its available label pool. This, together with the label invariance requirement mentioned above, result in each PBB-TE Ethernet Label being a domain-wide unique label, with a unique ESP-VID + ESP-MAC DA, for each direction. The following illustrates PBB-TE Ethernet Labels and ESPs for a P2P TESI. GMPLS Upstream Label <ESP:MAC1(DA), VID1> (60 bits) GMPLS Downstream Label <ESP:MAC2(DA), VID2> (60 bits) Upstream PBB-TE ESP 3-tuple <ESP:MAC1, MAC2, VID1> (108 bits) Downstream PBB-TE ESP 3-tuple <ESP:MAC2, MAC1, VID2> (108 bits) Table 1: Labels and ESPs RFC4655] or other planning style of tool with more complete knowledge of the network configuration is a way to impose pre-selection of shared forwarding with multiple paths using a single forwarding entry and optimizing for both
directions. In this scenario, the originating bridge uses the LABEL_SET and UPSTREAM_LABEL objects to indicate the selection of the shared forwarding labels at both ends.
To initiate a bidirectional Eth-LSP, the initiator of the PATH message MUST use the procedures outlined in [RFC3473] with the following specifics: 1) it MUST set the LSP encoding type to Ethernet (2) [RFC3471]. 2) it MUST set the LSP switching type to "802_1 PBB-TE", value 40. 3) it SHOULD set the Generalized Payload Identifier (G-PID) to Ethernet (33) [RFC3471]. 4) it MUST set the UPSTREAM_LABEL to the ESP-VID1/ESP-MAC1 tuple where the ESP-VID1 is administered locally for the local MAC address: MAC1. 5) it SHOULD set the LABEL_SET or SUGGESTED_LABEL if it chooses to influence the choice of ESP-VID/ESP-MAC DA. 6) it MAY carry an I-SID via Call/Connection ID [RFC4974]. Intermediate and egress bridge processing is not modified by this document, i.e., is per [RFC3473]. However, as previously stated, intermediate bridges supporting the 802_1 PBB-TE switching type MUST NOT modify LABEL values. The ESP-VID1/ESP-MAC1 tuple contained in the UPSTREAM_LABEL is used to create a static forwarding entry in the Filtering Database of bridges at each hop for the upstream direction. This behavior is inferred from the switching type, which is 802_1 PBB-TE. The port derived from the RSVP_HOP object and the ESP-VID1 and ESP-MAC1 included in the PBB-TE Ethernet Label constitute the static entry. At the destination, an ESP-VID (ESP-VID2) is allocated for the local MAC address: MAC2, the ESP-VID2/ESP-MAC2 tuple is passed in the LABEL object in the RESV message. As with the PATH message, intermediate bridge processing is per [RFC3473], and the LABEL object MUST be passed on unchanged, upstream. The ESP-VID2/ESP-MAC2 tuple contained in the LABEL object is installed in the forwarding table as a static forwarding entry at each hop. This creates a bidirectional Eth-LSP as the PATH and RESV messages follow the same path. RFC3209], the LSP ID in the sender template is updated as the new path is signaled. The procedures (including those for shared forwarding) are identical to those employed in establishing a new LSP, with the extended tunnel
ID in the signaling exchange ensuring that double booking of an associated resource does not occur. Where individual paths in a protection group are modified, signaling procedures MAY be combined with Protection Switching (PS) coordination to administratively force PS operations such that modification is only ever performed on the protection path. PS is a native capability of PBB-TE [IEEE802.1Qay] that can operate when two paths are set up between two common endpoints. RFC3473] and [RFC4875] could be adapted to signal P2MP LSPs for the source (point) to destination (multipoint) direction. Each one of the branches of the P2MP Eth-LSP would be associated with a reverse-path symmetric and congruent P2P Eth-LSP. Complete procedures for signaling bidirectional P2MP E-LSPs are out of scope for this document. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| ESP VID | ESP MAC (highest 2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESP MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: PBB-TE Ethernet Label This format MUST be used for both P2P and P2MP Eth-LSPs. For P2P Eth-LSPs, the fields specify a VID and a unicast MAC address; whereas, for P2MP Eth-LSPs, a VID and a group MAC address is carried in the label. The PBB-TE Ethernet Label is a domain-wide unique label and MUST be passed unchanged at each hop. This has similarity to the way in which a wavelength label is handled at an intermediate bridge that cannot perform wavelength conversion, and is described in [RFC3473].
RFC4872] and [RFC4873] using the ASSOCIATION and PROTECTION objects. RFC4974] MAY be used to create an association between the Eth-LSP endpoints prior to establishment of the LSP. The CALL_ATTRIBUTES object can be used during CALL signaling, as described in [RFC4974], to indicate properties of the CALL. The Service ID TLV, defined below, can be carried in the CALL_ATTRIBUTES object to indicate the I-SID to ESP mapping for the Eth-LSP that will be set up in association with the CALL. Alternatively, the GMPLS RSVP-TE PATH message can carry the I-SID association using the Service ID TLV in the LSP_ATTRIBUTES object [RFC5420] at the time of Eth-LSP signaling. Using this mechanism, it is possible to create the I-SID association, either when the path is set up or at a later time using a PATH refresh. A new Service ID TLV is defined for the CALL_ATTRIBUTES and LSP_ATTRIBUTES objects. The type value is 3 when carried in the CALL_ATTRIBUTES object and the type value is 2 when carried in the LSP_ATTRIBUTES object. The format is depicted below.
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 | Length (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | I-SID Set Object 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | I-SID Set Object n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Service ID TLV - I-SID Set Object: is used to define a list or range of I-SIDs. Multiple I-SID Set Objects can be present. At least one I-SID Set Object MUST be present. In most of the cases, a single I-SID Set Object with a single I-SID value is used. The I-SID Set Object is used to define a list or range of I-SIDs. The format of the I-SID Set Object is based on the LABEL_SET Object: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | I-SID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | I-SID n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: I-SID Set Object - Action: 8 bits The following actions are defined: list (0), range (1). When a range is defined, there are only two I-SIDs that follow the beginning I-SID and the end of the range I-SID. When list is defined, a number of I-SIDs may be defined. - Length: 16 bits This indicates the length of the I-SID Set object.
- I-SID: 24 bits The I-SID value identifies a particular backbone service instance. RFC3209]. Note that an originating bridge can reuse an ESP-VID with a different source or destination B-MAC address. By allocating a number of B-MACs and a number of ESP-VIDs, a large number of PBB-TE connections may be supported. Note, this error may be originated by any bridge along the path.
IEEE802.1Q] that have special meaning, processing, and follow specific forwarding rules. These addresses cannot be used for PBB-TE ESPs. In the case the PBB-TE Ethernet Label refers to such a MAC address, a bridge encountering the mismatch MUST immediately generate an error: Routing problem (24) / Unacceptable label value (6). Handling of this error is according to [RFC3209]. RFC4872] and [RFC4873] apply. A GMPLS-controlled Ethernet PBB-TE system assumes that users and devices attached to User-to-Network Interfaces (UNIs) may behave maliciously, negligently, or incorrectly. Intra-provider control traffic is trusted not to be malicious. In general, these requirements are no different from the security requirements for operating any GMPLS network. Access to the trusted network will only occur through the protocols defined for the UNI or Network-to-Network Interface (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 for the control plane, the data-plane security is decoupled from the control plane; 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 denial-of-service (DoS) attacks may be required on UNI ports. PBB-TE has been designed to interwork with legacy VLANs and the VLANs provide isolation from Ethernet legacy control planes. Where control-plane communications are point-to-point over links that employ 802.1AE Media Access Control Security [MACSEC], it may reasonably be determined that no further security measures are used. In other cases, it is appropriate to use control-plane security where it is deemed necessary to secure the signaling messages. GMPLS signaling security measures are described in [RFC3471] and [RFC3473], and they inherit security techniques applicable to RSVP-TE, as described in [RFC3209] and [RFC2205]. For a fuller overview of GMPLS security techniques, see [RFC5920]. RFC5420]. This new type has been registered as follows: Type: 2 Name: Service ID TLV Allowed on LSP_ATTRIBUTES: Yes Allowed on LSP_REQUIRED_ATTRIBUTES: No The Service ID TLV has been assigned value 3 in the Call Attributes TLV registry in the RSVP Parameters registry. It is carried in the CALL_ATTRIBUTES object (class = 202, C-Type = 1) defined by [RFC6001]. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 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 Swicthing (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. [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007. [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 2007. [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009. [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.
[IEEE802.1ah] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges", (2008) [IEEE802.1Q] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2005, May 19, 2006. [IEEE802.1Qay] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment : Provider Backbone Bridges Traffic Engineering", 2009. [MACSEC] "IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Security", IEEE 802.1AE-2006, August 18, 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. [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework", RFC 5828, March 2010. [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.