The IESG has approved the following document: - 'Generalized Multiprotocol Label Switching (GMPLS) control of Ethernet Provider Backbone Traffic Engineering (PBB-TE) ' <draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt> as a Proposed Standard
This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt Technical Summary This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework [RFC5828] and describes the technology specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE) [IEEE 802.1Qay]. 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. Working Group Summary Nothing of note. Document Quality There are no known implementations, but it is expected that several vendors plan to implement. Personnel Deborah Brungard (db3...@att.com) is the Document Shepherd. Adrian Farrel (adrian.far...@huawei.com) is the Responsible AD. RFC Editor Note Section 4.1 OLD Note, PBB-TE is designed to be bidirectional and symmetrically routed just like Ethernet. That is, complete and proper functionality of Ethernet protocols is only guaranteed for bidirectional Eth-LSPs. In the following we discuss the establishment of bidirectional Eth-LSPs. Note however that it is also possible to use RSVP-TE to configure unidirectional ESPs, if the UPSTREAM_LABEL is not included in the PATH message. To initiate a bidirectional Eth-LSP, the initiator of the PATH message MUST use the procedures outlined in [RFC3473] with the following specifics: NEW PBB-TE is designed to be bidirectional and symmetrically routed just like Ethernet. That is, complete and proper functionality of Ethernet protocols is only guaranteed for bidirectional Eth-LSPs. In this section we discuss the establishment of bidirectional Eth-LSPs. Note, however, that it is also possible to use RSVP-TE to configure unidirectional ESPs, if the UPSTREAM_LABEL is not included in the PATH message. To initiate a bidirectional Eth-LSP, the initiator of the PATH message MUST use the procedures outlined in [RFC3473] with the following specifics: END --- Section 4.1.1 s/Eth LSP/Eth-LSP/ --- Section 5.1.2 OLD The destination bridge after receiving the PATH message has to allocate a VID, which together with its MAC address will constitute the PBB-TE Ethernet Label. Depending on the size of the allocated VLAN range and the number of Eth-LSPs terminated on a particular bridge, it is possible that the available VIDs are exhausted and hence no PBB-TE Ethernet Label can be allocated. In this case the destination bridge SHOULD generate a PathErr message with error code: Routing problem (24) and error value: MPLS Label allocation failure (9). NEW The destination bridge after receiving the PATH message has to assign a VID, which together with its MAC address will constitute the PBB-TE Ethernet Label. An existing VID may be reused when Shared forwarding is used or when there are no path conflicts otherwise the bridge has to allocate a VID. Depending on the size of the allocated VLAN range and the number of Eth-LSPs terminated on a particular bridge, it is possible that the available VIDs are exhausted and hence no PBB-TE Ethernet Label can be allocated. In this case the destination bridge SHOULD generate a PathErr message with error code: Routing problem (24) and error value: MPLS Label allocation failure (9). END --- Section 5.2 OLD IEEE defines a set of reserved MAC addresses Table 8-1 [IEEE 802.1Q] that have special meaning, processing and follow specific forwarding rules. NEW IEEE defines a set of reserved MAC addresses from 01-80-C2-00-00-00 to 01-80-C2-00-00-0F as explained in [IEEE 802.1Q] that have special meaning, processing, and follow specific forwarding rules. END --- Section 6 Acronym expansions UNI - User-to-Network Interface NNI - Network-to-Network Interface DOS - Denial of Service --- Section 6 OLD For a more comprehensive discussion on GMPLS security please see the Security Framework for MPLS and GMPLS Networks[RFC5920]. Cryptography can be used to protect against many attacks described in [RFC5920]. One option for protecting "transport" Ethernet is the use of 802.1AE Media Access Control Security, [MACSEC] which provides encryption and authentication." NEW Where control plane communications are point-to-point over links that employ 802.1AE Media Access Control Security [MACSEC], it may reasonably 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 inherit security techniques applicable to RSVP-TE as described in [RFC3209] and [RFC2205]. For a fuller overview of GMPLS security techniques see [RFC5920]. END --- Section 7 DELETE - Assign a new globally defined error value: "PBB-TE Ethernet Label VID allocation failure" (suggested value: 35?) under the "Routing problem" (24) error code in the RSVP Parameters / Error Codes and Globally-Defined Error Value Sub-Codes registry. END --- Section 7 OLD - Assign a new type from the Attributes TLV Space in the RSVP-TE Parameters registry (suggested value 2) for the Service ID TLV that is carried in the LSP_ATTRIBUTES Object (class = 197, C-Type = 1) [RFC5420]. NEW - Assign a new type from the Attributes TLV Space in the RSVP-TE Parameters registry (suggested value 2) for the Service ID TLV that is carried in the LSP_ATTRIBUTES Object (class = 197, C-Type = 1) [RFC5420]. Please reocrd this new type as follows: Name: I-SID Association TLV Allowed on LSP_ATTRIBUTES Yes Allowed on LSP_REQUIRED_ATTRIBUTES No END --- Section 8.1 ADD [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997. --- Section 8.1 [RFC4872] Lang, J. et.al., "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery", RFC 4871, May 2007. s/4871/4872/ --- IANA Note IANA: Please note the two RFC Editor note changes to Section 7. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
