1、 COVERING NOTE GENERAL SECRETARIAT OF THE INTERNATIONAL TELECOMMUNICATION UNION Geneva, 6 September 2012 ITU TELECOMMUNICATION STANDARDIZATION SECTOR Subject: Erratum (09/2012) to Recommendation ITU-T G.8110.1/Y.1370.1 (2011), Architecture of the Multi-Protocol Label Switching transport profile laye
2、r network Replace the first page of the Recommendation with the contents of the following two pages: Rec. ITU-T G.8110.1/Y.1370.1 (12/2011) 1 Recommendation ITU-T G.8110.1/Y.1370.1 Architecture of the Multi-Protocol Label Switching transport profile layer network1 1 Scope This Recommendation provide
3、s the functional components, based on ITU-T G.805, that are necessary to describe the deployment of Multi-Protocol Label Switching Transport Profile (MPLS-TP) in a transport network. This model allows MPLS-TP to be modelled in a way that is consistent with the description of other transport technolo
4、gies defined by ITU-T, (e.g., the synchronous digital hierarchy (SDH), the optical transport network (OTN), etc.). This Recommendation provides a representation of the MPLS-TP technology using the methodologies that have been used for other transport technologies, (e.g., SDH, OTN and Ethernet).2 1 C
5、isco Systems has expressed concerns that the following text has been removed from the consented text: “This Recommendation complies with the transport profile of MPLS Architecture as defined by the IETF. In the event of a difference between this ITU-T Recommendation and any of the normatively refere
6、nced IETF RFCs, the RFCs will take precedence.“ as without this statement, interoperability issues may arise. 1 France Telecom Orange has expressed its concerns that the following text has been removed from the consented text: “This Recommendation complies with the transport profile of MPLS Architec
7、ture as defined by the IETF. In the event of a difference between this ITU-T Recommendation and any of the normatively referenced IETF RFCs, the RFCs will take precedence.“ as without this statement, interoperability issues may arise. 1 Juniper Networks has stated its concerns about the changes to t
8、he consented text of this Recommendation that it believes have introduced potential issues in implementation, deployment, and interoperability. Juniper Networks believes that it is important to provide a clarification that in the event of any misalignment, the definition of MPLS provided in the refe
9、renced RFCs takes precedence over any description or modeling of MPLS-TP provided in this Recommendation. 1 Nokia Siemens Networks has expressed concerns that the following text has been removed from the consented text: “This Recommendation complies with the transport profile of MPLS Architecture as
10、 defined by the IETF. In the event of a difference between this ITU-T Recommendation and any of the normatively referenced IETF RFCs, the RFCs will take precedence.“ as without this statement, interoperability issues may arise. 1 Telefon AB - LM Ericsson has expressed concerns that the following tex
11、t has been removed from the consented text: “This Recommendation complies with the transport profile of MPLS Architecture as defined by the IETF. In the event of a difference between this ITU-T Recommendation and any of the normatively referenced IETF RFCs, the RFCs will take precedence.“ as without
12、 this statement, interoperability issues may arise. 1 Verizon Communications has expressed concerns that the following text has been removed from the consented ITU-T G.8110.1 text: “This Recommendation complies with the transport profile of MPLS Architecture as defined by the IETF. In the event of a
13、 difference between this ITU-T Recommendation and any of the normatively referenced IETF RFCs, the RFCs will take precedence.“ Without this statement, interoperability issues may arise. 1bis REC. ITU-T G.8110.1/Y.1370.1 (12/2011) MPLS-TP is a connection-oriented packet-switched transport layer netwo
14、rk technology that uses pseudowires (PWs) and MPLS-TP label switched paths (LSPs). The MPLS-TP is a profile of the MPLS that supports deployment in transport networks and allows operations in a manner consistent with other transport technologies. Its operation is independent of the mechanisms used f
15、or configuration and management. In some applications, the data plane only supports forwarding based on the MPLS label; it does not support IP forwarding. The architecture of the MPLS-TP forwarding, operation, administration and maintenance (OAM), and network survivability, is modelled from a networ
16、k-level viewpoint. The description of the control plane and management plane aspects of the MPLS-TP is outside the scope of this Recommendation. The functional components described in this Recommendation also support the architecture for point-to-multipoint (p2mp) MPLS-TP LSPs in compliance with IET
17、F RFC 5331 and IETF RFC 5332. As the MPLS-TP is a profile of the MPLS, this Recommendation uses the applicable functional components provided in the MPLS layer network architecture of ITU-T G.8110 and extends them with additional capabilities (e.g., OAM and protection) that are not modelled in ITU-T
18、 G.8110. This version of this Recommendation only provides those functional components (based on ITU-T G.805) and architectural models required to model an Ethernet service carried by a single-segment pseudowire (SS-PW) over co-routed bidirectional LSPs, which may be hierarchical, and do not use pen
19、ultimate hop popping (PHP). Other clients for LSPs (e.g., Internet Protocol (IP), and PWs and modes of operation (e.g., multi-segment pseudowire (MS-PW) or associated bidirectional LSPs), as described in IETF RFC 5921, are supported as defined in IETF RFC 5921 and IETF RFC 6215 but are not modelled in this version of the Recommendation. They will be added in future versions of this Recommendation. 2 This ITU-T Recommendation is intended to be aligned with the IETF MPLS RFCs normatively referenced by this Recommendation.
