Movatterモバイル変換

Network Working Group                                     S. Bryant, Ed.Request for Comments: 5317                                 Cisco SystemsCategory: Informational                                L. Andersson, Ed.                                                                Acreo AB                                                           February 2009Joint Working Team (JWT) Reporton MPLS Architectural Considerations for a Transport ProfileStatus 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 toBCP 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 2009Table of Contents1. Introduction ....................................................32. Executive Summary ...............................................43. Introduction and Background Material ............................64. High-Level Architecture .........................................65. OAM and Forwarding ..............................................66. Control Plane ...................................................77. Survivability ...................................................78. Network Management ..............................................79. Summary .........................................................710. IANA Considerations ............................................811. Security Considerations ........................................812. The JWT Report .................................................813. Informative References .........................................9Bryant & Andersson           Informational                      [Page 2]

RFC 5317                   JWT MPLS-TP Report              February 20091.  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 20093.  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 200913.  Informative References   [Ethertypes]   IESG and IAB, "T-MPLS use of the MPLS Ethertypes",                  2006, <https://datatracker.ietf.org/documents/LIAISON/file470.txt>.   [JWTcreation]  Chairman, ITU-T SG 15, "Proposal to establish an Ad                  Hoc group on T-MPLS", 2008, <http://www.itu.int/md/T05-SG15-080211-TD-PLEN-0515/en>.   [LIAISON]      Liaison statements to and from the IETF can be found                  at: <https://datatracker.ietf.org/liaison/>.   [MPLS-TP]      "IETF and ITU-T cooperation on extensions to MPLS for                  transport network functionality", May 2008,                  <https://datatracker.ietf.org/liaison/446/>.   [MPLS-TP-22]   IETF - ITU-T Joint Working Team, "MPLS Architectural                  Considerations for a Transport Profile", April 2008,                  <http://www.ietf.org/MPLS-TP_overview-22.pdf>.   [MPLS-TP1]     "IETF and ITU-T cooperation on extensions to MPLS for                  transport network functionality", ITU-T SG15,                  May 2008, <https://datatracker.ietf.org/documents/LIAISON/file553.pdf>.   [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, <http://ties.itu.int/u//tsg15/sg15/xchange/wp3/200709_joint_q12_q14_stuttgart/T-MPLS/wdt03_rapporteur_report-final.doc>.  This                  document is available on request from the ITU-T.   [ahtmpls]      "Ad Hoc group on T-MPLS", 2008, <http://www.itu.int/ITU-T/studygroups/com15/ahtmpls.html>.Bryant & Andersson           Informational                      [Page 9]

RFC 5317                   JWT MPLS-TP Report              February 2009Editors' 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.nuBryant & Andersson           Informational                     [Page 10]