RFC 5317

Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile

📅 published February 2009, from ietf

RFC 5317: Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile 🦋

okay bestie, this one is a Informational RFC from February 2009 📅 (so it's not a rule, it's a report!). The authors are S. Bryant, Ed. from Cisco Systems and L. Andersson, Ed. from Acreo AB 🫶. The header doesn't list any RFC that it obsoletes or updates, so it's a standalone archive 💜. Its job is to file away the JWT report, which is the IETF and ITU-T's big joint team report on using MPLS for transport networks ✨.

Status of This Memo 📝

This memo gives info to the Internet community, and it does not set any Internet standard of any kind 🙅‍♀️. It can be distributed freely, with no limits 🌸.

Copyright (c) 2009 IETF Trust and the people listed as the document authors. All rights reserved 💅.

This document is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info), as they were on the day it was published. Read these carefully, because they explain your rights and restrictions for this document 🎀.

Abstract 🌈

okay so this RFC archives the report from the IETF - ITU-T Joint Working Team (JWT) about running MPLS on transport networks 🚇. The JWT recommended Option 1 ✨: the IETF and the ITU-T agree to team up, 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 has a summary of the slides) and in PDF (which has the summary and a copy of the slides) 💖.

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

1. Introduction 🌸

For a while now, the ITU-T has been designing a connection-oriented packet switched tech for Transport Networks 🚆. A Transport Network is basically the network that gives wide area connectivity, and other services like IP or the phone network run on top of it 🌐. The ITU-T picked the IETF's MPLS to adapt for this job and made a protocol suite called T-MPLS 🧚.

Quite late in the ITU-T's design and spec cycle, there were a bunch of liaison exchanges between the ITU-T and the IETF about this tech 📨. You can find these on the IETF Liaison Statement web page [LIAISON]. The chairs of the MPLS, PWE3, BFD, and CCAMP working groups, plus the Routing and Internet Area Directors, also went to a bunch of ITU-T meetings 🙈. During all of this, the IETF got really worried that the IETF MPLS and ITU-T T-MPLS being incompatible would "represent a mutual danger to both the Internet and the Transport network" 😭. So the IESG and IAB chairs sent a liaison to the ITU-T saying that either T-MPLS should become a fully compliant MPLS protocol, standardized under the IETF process (the so-called "Option 1"), or it should become a completely separate protocol with a new name and a completely new set of code points (the so-called "Option 2") [Ethertypes] 💅.

Option 1 and Option 2 were talked about at an ITU-T meeting of Question 12 Study Group 15 in Stuttgart [Stuttgart], where someone proposed forming a Joint (ITU-T - IETF) Team to check out the issues and recommend the best way forward to ITU-T management 🔥.

After talks between the IETF and ITU-T management, a Joint Working Team (JWT) got set up 🫶. It was backed up 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 happened during the ITU-T Geneva Plenary in February 2008 ✨. Because of the JWT's work and the agreement on a way forward, the fears that the ITU-T's next-gen network transport specs could cause interoperability problems got calmed down 🦋.

The JWT sent their report to ITU-T and IETF management as a set of Power Point slides [MPLS-TP-22] 💜. (See the PDF of this RFC 📄.) The ITU-T has accepted the JWT recommendations, as written up in [MPLS-TP] 👑. This RFC archives the JWT report in a format that's accessible to the IETF 🌈.

This RFC is available in ASCII (which has a summary of the slides) and in PDF (which has the summary and a copy of the slides) 💅. If the summary and the slides conflict, the slides win 🏆. Since those slides were the basis of an important agreement between the IETF and the ITU-T, it's also worth noting that if the PDF version of the slides is different from the ones emailed to ITU-T and IETF management on 18 April 2008 by the co-chairs of the JWT, the emailed slides win 💖.

2. Executive Summary ✨

Slides 4 to 10 give an executive summary of the JWT Report 💅. Here's the summary of those slides, bestie 🎀:

The JWT reached consensus on recommending Option 1: jointly agree to work together, 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 this would hit the mutual goals of making transport networks and the Internet better, while also guaranteeing complete interoperability and architectural soundness 🌸. This tech would be called the Transport Profile for MPLS (MPLS-TP) 🦋.

The JWT recommended that future work 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 found there were no "show stopper" issues with recommending Option 1, and that the IETF MPLS and Pseudowire architecture could be extended to support transport functional requirements 🔥. So the team believed there was no need to analyze any other option 🙅‍♀️.

The JWT proposed that the MPLS Interoperability Design Team (MEAD Team), JWT, and Ad Hoc T-MPLS groups keep going as described in SG15 TD515/PLEN [JWTcreation], with these 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 power to create or change IETF RFCs or ITU-T Recommendations 🙅‍♀️. Any such work would go through 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 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 also has a bunch of detailed JWT recommendations for both IETF and ITU-T management, plus a proposed document structure and timetable 📅.

These JWT recommendations were accepted by ITU-T management [MPLS-TP1] 🏆.

3. Introduction and Background Material 🌷

Slides 11 to 22 give the intro and background material 📚.

The analysis started by trying to satisfy Option 1 🎯. That meant showing the high-level architecture, any show stoppers, and the design points that would need addressing once the decision to work together was made 🔥. Option 1 was the one the IETF preferred, and since Option 1 was shown to be feasible, Option 2 wasn't explored 💅.

The work was split into five groups looking at Forwarding, OAM, Protection, Control Plane, and Network Management 🧩. The result of each review is reported in the following sections and summarized below 🦋.

There's a detailed description of the overall requirements and architectural assumptions that the rest of the work uses 📝.

4. High-Level Architecture 🏗️

Slides 23 to 28 give a high-level architectural view of the proposed design 🌈.

The spectrum of services that MPLS-TP needs to address, plus the wider MPLS context, is described, along with the provisioning issues 🍓. Some basic terminology needed to understand 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 💖.

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) 🎀.

Slides 47 to 48 describe in detail how the forwarding and the ACH OAM mechanism work 🫶. A significant number of scenarios are worked through case by case 🌸. These slides also introduce a new textual notation to simplify the description of complex MPLS stacks ✨.

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 👑.

Note that MPLS forwarding, as specified by IETF RFCs, requires no changes to support MPLS-TP 🏆.

6. Control Plane 🎀

okay so sides 79 to 83 are where the control plane design gets the spotlight 💅✨

The control plane sub-team said that existing IETF protocols can already do the jobs needed for transport network operation, and for data-communications-network/switched-circuit-network operation too 🦋 The IETF GMPLS protocols have already been applied to the Automatic Switched Optical Network (ASON) architecture, and the JWT thought any protocol extensions that turn out to be needed will be easy to make 🫶 The slides give a bunch of scenarios to show that this conclusion holds up 🔥

7. Survivability 🛟

the survivability considerations are in slides 95 to 104 💖

The survivability sub-team didn't find any issues that stopped the creation of an MPLS-TP 🌸 So they recommended that Option 1 be selected 👑 They identified three potential solutions, and each one has different attributes and advantages 🧚 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, the slide set walks through 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 💅 They found no issues that prevent the creation of an MPLS-TP, so Option 1 can be selected 🎀

9. Summary 🍓

slide 113 gives a summary of the JWT report ✨

The JWT found no show stoppers, and they unanimously agreed that they had identified a viable solution 😭 So they recommend Option 1 👑 In their view, it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile 🔥 They also said 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 been implemented and deployed widely enough 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 also 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 🔐

⚠️ This is the serious part, bestie. Read it carefully 💀

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, and those will be identified in the RFCs that define MPLS-TP 🔥

12. The JWT Report 📑

In the PDF of this RFC, the JWT report follows as a set of slides 🎀

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>.

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

📦 where this page comes from