From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5317.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc5317.txt (limited to 'doc/rfc/rfc5317.txt') diff --git a/doc/rfc/rfc5317.txt b/doc/rfc/rfc5317.txt new file mode 100644 index 0000000..33c00aa --- /dev/null +++ b/doc/rfc/rfc5317.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group S. Bryant, Ed. +Request for Comments: 5317 Cisco Systems +Category: Informational L. Andersson, Ed. + Acreo AB + February 2009 + + + Joint Working Team (JWT) Report + on MPLS Architectural Considerations for a Transport Profile + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 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. + +Abstract + + This RFC archives the report of the IETF - ITU-T Joint Working Team + (JWT) on the application of MPLS to transport networks. The JWT + recommended of Option 1: The IETF and the ITU-T jointly agree to work + together and bring transport requirements into the IETF and extend + IETF MPLS forwarding, OAM (Operations, Administration, and + Management), survivability, network management and control plane + protocols to meet those requirements through the IETF Standards + Process. This RFC is available in ASCII (which contains a summary of + the slides) and in PDF (which contains the summary and a copy of the + slides). + + + + + + + + + + + + +Bryant & Andersson Informational [Page 1] + +RFC 5317 JWT MPLS-TP Report February 2009 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Executive Summary ...............................................4 + 3. Introduction and Background Material ............................6 + 4. High-Level Architecture .........................................6 + 5. OAM and Forwarding ..............................................6 + 6. Control Plane ...................................................7 + 7. Survivability ...................................................7 + 8. Network Management ..............................................7 + 9. Summary .........................................................7 + 10. IANA Considerations ............................................8 + 11. Security Considerations ........................................8 + 12. The JWT Report .................................................8 + 13. Informative References .........................................9 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bryant & Andersson Informational [Page 2] + +RFC 5317 JWT MPLS-TP Report February 2009 + + +1. Introduction + + For a number of years, the ITU-T has been designing a connection- + oriented packet switched technology to be used in Transport Networks. + A Transport Network can be considered to be the network that provides + wide area connectivity upon which other services, such as IP or the + phone network, run. The ITU-T chose to adapt the IETF's MPLS to this + task, and introduced a protocol suite known as T-MPLS. + + Quite late in the ITU-T design and specification cycle, there were a + number of liaison exchanges between the ITU-T and the IETF concerning + this technology. These liaisons can be found on the IETF Liaison + Statement web page [LIAISON]. In addition, the chairs of the MPLS, + PWE3, BFD, and CCAMP working groups as well as the Routing and + Internet Area Directors attended a number of ITU-T meetings. During + this process, the IETF became increasingly concerned that the + incompatibility of IETF MPLS and ITU-T T-MPLS would "represent a + mutual danger to both the Internet and the Transport network". These + concerns led the chairs of the IESG and IAB to take the step of + sending a liaison to the ITU-T, stating that either T-MPLS should + become fully compliant MPLS protocol, standardized under the IETF + process (the so-called "Option 1"), or it should become a completely + disjoint protocol with a new name and completely new set of code + points (the so-called "Option 2") [Ethertypes]. + + Option 1 and Option 2 were discussed at an ITU-T meeting of Question + 12 Study Group 15 in Stuttgart [Stuttgart], where it was proposed + that a Joint (ITU-T - IETF) Team should be formed to evaluate the + issues, and make a recommendation to ITU-T management on the best way + forward. + + Following discussion between the management of the IETF and the + ITU-T, a Joint Working Team (JWT) was established; this was supported + by an IETF Design Team and an Ad Hoc Group on T-MPLS in the ITU-T + [ahtmpls]. The first meeting of the Ad Hoc group occurred during the + ITU-T Geneva Plenary in February 2008. As a result of the work of + the JWT and the resulting agreement on a way forward, the fears that + a set of next-generation network transport specifications developed + by ITU-T could cause interoperability problems were allayed. + + The JWT submitted their report to the ITU-T and IETF management in + the form of a set of Power Point slides [MPLS-TP-22]. (See the PDF + of this RFC.) The ITU-T have accepted the JWT recommendations, as + documented in [MPLS-TP]. This RFC archives the JWT report in a + format that is accessible to the IETF. + + + + + + +Bryant & Andersson Informational [Page 3] + +RFC 5317 JWT MPLS-TP Report February 2009 + + + This RFC is available in ASCII (which contains a summary of the + slides) and in PDF (which contains the summary and a copy of the + slides). In the case of a conflict between the summary and the + slides, the slides take precedence. Since those slides were the + basis of an important agreement between the IETF and the ITU-T, it + should further be noted that in the event that the PDF version of the + slides differs from those emailed to ITU-T and IETF management on 18 + April 2008 by the co-chairs of the JWT, the emailed slides take + precedence. + +2. Executive Summary + + Slides 4 to 10 provide an executive summary of the JWT Report. The + following is a summary of those slides: + + The JWT achieved consensus on the recommendation of Option 1: to + jointly agree to work together and bring transport requirements into + the IETF and extend IETF MPLS forwarding, OAM, survivability, network + management, and control plane protocols to meet those requirements + through the IETF Standards Process. The Joint Working Team believed + that this would fulfill the mutual goals of improving the + functionality of the transport networks and the Internet and + guaranteeing complete interoperability and architectural soundness. + This technology would be referred to as the Transport Profile for + MPLS (MPLS-TP). + + The JWT recommended that future work should focus on: + + In the IETF: + + Definition of the MPLS "Transport Profile" (MPLS-TP). + + In the ITU-T: + + Integration of MPLS-TP into the transport network, + + Alignment of the current T-MPLS ITU-T Recommendations with MPLS-TP + and, + + Termination of the work on current T-MPLS. + + The technical feasibility analysis concluded there were no "show + stopper" issues in the recommendation of Option 1 and that the IETF + MPLS and Pseudowire architecture could be extended to support + transport functional requirements. Therefore, the team believed that + there was no need for the analysis of any other option. + + + + + +Bryant & Andersson Informational [Page 4] + +RFC 5317 JWT MPLS-TP Report February 2009 + + + The JWT proposed that the MPLS Interoperability Design Team (MEAD + Team), JWT, and Ad Hoc T-MPLS groups continue as described in SG15 + TD515/PLEN [JWTcreation] with the following roles: + + Facilitate the rapid exchange of information between the IETF and + ITU-T, + + Ensure that the work is progressing with a consistent set of + priorities, + + Identify gaps/inconsistencies in the solutions under development, + + Propose solutions for consideration by the appropriate WG/ + Question, + + Provide guidance when work on a topic is stalled or a technical + decision must be mediated. + + None of these groups would have the authority to create or modify + IETF RFCs or ITU-T Recommendations. Any such work would be + progressed via the normal process of the respective standards body. + Direct participation in the work by experts from the IETF and ITU-T + would be required. + + The JWT recommended that the normative definition of the MPLS-TP that + supports the ITU-T transport network requirements be captured in IETF + RFCs. It proposed that the ITU-T should: + + Develop ITU-T Recommendations to allow MPLS-TP to be integrated + with current transport equipment and networks, including in + agreement with the IETF, the definition of any ITU-T-specific + functionality within the MPLS-TP architecture via the MPLS change + process [RFC4929], + + Revise existing ITU-T Recommendations to align with MPLS-TP, + + ITU-T Recommendations will make normative references to the + appropriate RFCs. + + The executive summary contains a number of detailed JWT + recommendations to both IETF and ITU-T management together with + proposed document structure and timetable. + + These JWT recommendations were accepted by ITU-T management + [MPLS-TP1]. + + + + + + +Bryant & Andersson Informational [Page 5] + +RFC 5317 JWT MPLS-TP Report February 2009 + + +3. Introduction and Background Material + + Slides 11 to 22 provide introductory and background material. + + The starting point of the analysis was to attempt to satisfy Option 1 + by showing the high-level architecture, any show stoppers, and the + design points that would need to be addressed after the decision had + been made to work together. Option 1 was stated as preferred by the + IETF and because Option 1 was shown to be feasible, Option 2 was not + explored. + + The work was segmented into five groups looking at: Forwarding, OAM, + Protection, Control Plane, and Network Management. The outcome of + each review was reported in the following sections and is summarized + below. + + There follows a detailed description of the overall requirements and + architectural assumptions that would be used in the remainder of the + work. + +4. High-Level Architecture + + Slides 23 to 28 provide a high-level architectural view of the + proposed design. + + The spectrum of services that the MPLS-TP needs to address and the + wider MPLS context is described, together with the provisioning + issues. Some basic terminology needed in order to understand the + MPLS-TP is defined and some context examples are provided. + +5. OAM and Forwarding + + Slides 29 to 32 describe the OAM requirements and talk about segment + recovery and node identification. + + Slides 33 to 38 introduce OAM hierarchy and describe Label Switched + Path (LSP) monitoring, the Maintenance End Point (MEP) and + Maintenance Intermediate Point (MIP) relationship and the LSP and + pseudowire (PW) monitoring relationship. + + Sides 39 to 46 introduce the Associated Channel Header (ACH) and its + generalization to carry the OAM over LSPs through the use of the + "Label for You" (LFU). + + + + + + + + +Bryant & Andersson Informational [Page 6] + +RFC 5317 JWT MPLS-TP Report February 2009 + + + Slides 47 to 48 provide a description of how the forwarding and the + ACH OAM mechanism work in detail. A significant number of scenarios + are described to work through the operation on a case-by-case basis. + These slides introduce a new textual notation to simplify the + description of complex MPLS stacks. + + Note that the MPLS forwarding, as specified by IETF RFCs, requires no + changes to support MPLS-TP. + +6. Control Plane + + Sides 79 to 83 discuss various aspects of the control plane design. + + Control plane sub-team stated that existing IETF protocols can be + used to provide required functions for transport network operation + and for data-communications-network/switched-circuit-network + operation. IETF GMPLS protocols have already applied to Automatic + Switched Optical Network (ASON) architecture, and the JWT considered + that any protocol extensions needed will be easy to make. The slides + provide a number of scenarios to demonstrate this conclusion. + +7. Survivability + + The survivability considerations are provided in slides 95 to 104. + + The survivability sub-team did not find any issues that prevented the + creation of an MPLS-TP, and therefore recommended that Option 1 be + selected. Three potential solutions were identified. Each solution + has different attributes and advantages, and it was thought that + further work in the design phase should eliminate one or more of + these options and/or provide an applicability statement. + + After some clarifications and discussion, there follow in the slide + set a number of linear and ring protection scenarios with examples of + how they might be addressed. + +8. Network Management + + Slide 106 states the conclusion of the Network Management sub-team : + that it found no issues that prevent the creation of an MPLS-TP and + hence Option 1 can be selected. + +9. Summary + + Slide 113 provides a summary of the JWT report. + + + + + + +Bryant & Andersson Informational [Page 7] + +RFC 5317 JWT MPLS-TP Report February 2009 + + + The JWT found no show stoppers and unanimously agreed that they had + identified a viable solution. They therefore recommend Option 1. + They stated that in their view, it is technically feasible that the + existing MPLS architecture can be extended to meet the requirements + of a Transport profile, and that the architecture allows for a single + OAM technology for LSPs, PWs, and a deeply nested network. From + probing various ITU-T Study Groups and IETF Working Groups it appears + that MPLS reserved label 14 has had wide enough implementation and + deployment that the solution may have to use a different reserved + label (e.g., Label 13). The JWT recommended that extensions to Label + 14 should cease. + + The JWT further recommended that this architecture appeared to + subsume Y.1711, since the requirements can be met by the mechanism + proposed in their report. + +10. IANA Considerations + + There are no IANA considerations that arise from this document. + + Any IANA allocations needed to implement the JWT recommendation will + be requested in the Standards-Track RFCs that define the MPLS-TP + protocol. + +11. Security Considerations + + The only security consideration that arises as a result of this + document is the need to ensure that this is a faithful representation + of the JWT report. + + The protocol work that arises from this agreement will have technical + security requirements that will be identified in the RFCs that define + MPLS-TP. + +12. The JWT Report + + In the PDF of this RFC, there follows the JWT report as a set of + slides. + + + + + + + + + + + + + +Bryant & Andersson Informational [Page 8] + +RFC 5317 JWT MPLS-TP Report February 2009 + + +13. Informative References + + [Ethertypes] IESG and IAB, "T-MPLS use of the MPLS Ethertypes", + 2006, . + + [JWTcreation] Chairman, ITU-T SG 15, "Proposal to establish an Ad + Hoc group on T-MPLS", 2008, . + + [LIAISON] Liaison statements to and from the IETF can be found + at: . + + [MPLS-TP] "IETF and ITU-T cooperation on extensions to MPLS for + transport network functionality", May 2008, + . + + [MPLS-TP-22] IETF - ITU-T Joint Working Team, "MPLS Architectural + Considerations for a Transport Profile", April 2008, + . + + [MPLS-TP1] "IETF and ITU-T cooperation on extensions to MPLS for + transport network functionality", ITU-T SG15, + May 2008, . + + [RFC4929] Andersson, L. and A. Farrel, "Change Process for + Multiprotocol Label Switching (MPLS) and Generalized + MPLS (GMPLS) Protocols and Procedures", BCP 129, + RFC 4929, June 2007. + + [Stuttgart] IETF - IESG and IAB Chairs, "Report of interim meeting + of Q.12 on T-MPLS", Stuttgart, Germany, Annex 4, 12-14 + September 2007, 2008, . This + document is available on request from the ITU-T. + + [ahtmpls] "Ad Hoc group on T-MPLS", 2008, . + + + + + + + + + + + +Bryant & Andersson Informational [Page 9] + +RFC 5317 JWT MPLS-TP Report February 2009 + + +Editors' Addresses + + Stewart Bryant (editor) + Cisco Systems + 250, Longwater, Green Park, + Reading RG2 6GB + UK + + EMail: stbryant@cisco.com + + + Loa Andersson (editor) + Acreo AB + Isafjordsgatan 22 + Kista, + Sweden + + EMail: loa@pi.nu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bryant & Andersson Informational [Page 10] + -- cgit v1.2.3