summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5317.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5317.txt')
-rw-r--r--doc/rfc/rfc5317.txt563
1 files changed, 563 insertions, 0 deletions
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, <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 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]
+