MPLS-TP JWT Report: Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile
The agreement that stopped two standards bodies from building incompatible versions of the same thing.
Bryant, S., Ed. and L. Andersson, Ed., "Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile", RFC 5317, DOI 10.17487/RFC5317, February 2009, <https://www.rfc-editor.org/info/rfc5317>.
@misc{rfc5317,
series = {Request for Comments},
number = 5317,
howpublished = {RFC 5317},
publisher = {RFC Editor},
doi = {10.17487/RFC5317},
url = {https://www.rfc-editor.org/info/rfc5317},
author = {S. Bryant and L. Andersson},
title = {{Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile}},
pagetotal = 10,
year = 2009,
month = feb,
} RFC text
Contents
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).
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 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.
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.
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].
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).
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.
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.
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
ISO Plain Language
On this page
§1Introduction and Background
For a number of years the ITU-T had been designing a connection-oriented packet switched technology for use in transport networks. A transport network is the network that provides wide area connectivity on which other services, such as IP or the phone network, run. The ITU-T chose to adapt the IETF's MPLS to the 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 two organizations, and the chairs of the MPLS, PWE3, BFD and CCAMP working groups, along with the Routing and Internet Area Directors, attended several ITU-T meetings. Through 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. Those concerns led the chairs of the IESG and IAB to send a liaison to the ITU-T stating that either T-MPLS should become fully compliant MPLS, 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.
Both options were discussed at an ITU-T meeting of Question 12 of Study Group 15 in Stuttgart, where it was proposed that a joint 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 two organizations, a Joint Working Team was established, supported by an IETF Design Team and an Ad Hoc Group on T-MPLS in the ITU-T. 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 agreement on a way forward, the fears that a set of next-generation network transport specifications developed by the ITU-T could cause interoperability problems were allayed.
The JWT submitted its report to the ITU-T and IETF management in the form of a set of PowerPoint slides. The ITU-T accepted the JWT recommendations, as documented in the liaison statement of May 2008. This RFC archives the report in a format accessible to the IETF: an ASCII version holding a summary of the slides, and a PDF version holding the summary and a copy of the slides. In the case of a conflict between the summary and the slides, the slides take precedence.
The starting point of the analysis was to try to satisfy Option 1 by showing the high-level architecture, any show stoppers, and the design points that would need addressing after the decision to work together. Option 1 was stated as preferred by the IETF, and because it was shown to be feasible, Option 2 was not explored. The work was segmented into five groups looking at forwarding, OAM, protection, the control plane, and network management.
Transport networks carry things like telephone calls and IP traffic over wide areas. The ITU-T wanted to build its transport version of MPLS, but it was drifting away from the version the IETF had standardized, so the two organizations were heading towards a future with two incompatible label-switching systems on the same network. A joint team was set up to decide what to do.
| Option | What it means | Outcome |
|---|---|---|
| Option 1 | T-MPLS becomes fully compliant MPLS, standardized under the IETF process | Chosen. The two organizations work together and the result is the MPLS Transport Profile |
| Option 2 | T-MPLS becomes a completely disjoint protocol with a new name and completely new set of code points | Not explored, because Option 1 was shown to be feasible |
§2Executive Summary: The Recommendation
The JWT achieved consensus on recommending Option 1: to 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 team believed this would fulfil the mutual goals of improving the functionality of the transport networks and the Internet, and of guaranteeing complete interoperability and architectural soundness. This technology would be referred to as the Transport Profile for MPLS, MPLS-TP.
Future work should focus on defining the MPLS Transport Profile in the IETF, and in the ITU-T on integrating MPLS-TP into the transport network, aligning the current T-MPLS Recommendations with MPLS-TP, and terminating the work on current T-MPLS. The technical feasibility analysis concluded there were no show stopper issues in the Option 1 recommendation, and that the IETF MPLS and Pseudowire architecture could be extended to support transport functional requirements, so there was no need to analyse any other option.
The JWT recommended that the normative definition of MPLS-TP supporting the ITU-T transport network requirements be captured in IETF RFCs, and proposed that the ITU-T should develop Recommendations allowing 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, revise existing Recommendations to align with MPLS-TP, and make normative references to the appropriate RFCs.
The JWT also proposed that the MPLS Interoperability Design Team, the JWT and the Ad Hoc T-MPLS groups continue, with the roles of facilitating the rapid exchange of information between the IETF and ITU-T, ensuring that the work progresses with a consistent set of priorities, identifying gaps and inconsistencies in the solutions under development, proposing solutions for consideration by the appropriate working group or question, and providing guidance when work 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 go through the normal process of the respective standards body, with direct participation by experts from both.
In its conclusion the JWT found no show stoppers and unanimously agreed that it had identified a viable solution. It stated that in its view 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 label switched paths, pseudowires and a deeply nested network. From probing the ITU-T Study Groups and IETF Working Groups it appeared that the MPLS reserved label 14 had had wide enough implementation and deployment that the solution might have to use a different reserved label, for example label 13. The JWT recommended that extensions to label 14 should cease, and further recommended that this architecture appeared to subsume Y.1711, since the requirements can be met by the mechanism proposed in the report.
The answer was to stop writing two protocols. The transport requirements would be brought into the IETF, and the existing MPLS protocols would be extended to cover them, with the result called the MPLS Transport Profile. The team found nothing that made this impossible, and it also asked that work on extending the old reserved label stop, since that label had been implemented widely enough to cause trouble.
- 2007Option 1 and Option 2 discussed at the ITU-T Question 12 meeting in Stuttgart
- 2008First meeting of the ITU-T Ad Hoc group on T-MPLS, at the Geneva Plenary
- 2008ITU-T management accepts the JWT recommendations
§4High-Level Architecture
Slides 23 to 28 of the report give a high-level architectural view of the proposed design. They describe the spectrum of services the MPLS-TP needs to address and the wider MPLS context, together with the provisioning issues. They also define some basic terminology needed to understand MPLS-TP and give context examples.
The detailed sections of the report then work through the technical areas. The OAM and forwarding slides describe the OAM requirements and discuss segment recovery and node identification, then introduce the OAM hierarchy and describe label switched path monitoring, the relationship between the Maintenance End Point and the Maintenance Intermediate Point, and the relationship between LSP and pseudowire monitoring. Later slides introduce the Associated Channel Header and its generalization to carry OAM over LSPs through the use of the Label for You. A further set of slides describes in detail how forwarding and the Associated Channel Header OAM mechanism work, walking through a significant number of scenarios case by case, and introduces a new textual notation to simplify the description of complex MPLS stacks. The report notes that MPLS forwarding, as specified by the IETF RFCs, requires no changes to support MPLS-TP.
The architecture slides set out the services the profile has to cover and the terms used to describe it. The technical detail follows in five areas, and the first of them is the one that matters most for carrying traffic: the forwarding plane itself needs no change at all, only the operations and maintenance around it.
§6Control Plane, Survivability and Network Management
The control plane sub-team stated that existing IETF protocols can provide the functions required for transport network operation and for data-communications-network and switched-circuit-network operation. IETF GMPLS protocols have already been applied to the Automatic Switched Optical Network architecture, and the JWT considered that any protocol extensions needed would be easy to make. The slides give a number of scenarios to demonstrate that conclusion.
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. It identified three potential solutions, each with different attributes and advantages, and thought that further work in the design phase should eliminate one or more of the options or provide an applicability statement. After some clarifications and discussion, the slide set follows with a number of linear and ring protection scenarios with examples of how they might be addressed.
The network management sub-team reached the same conclusion: it found no issues that prevent the creation of an MPLS-TP, and hence Option 1 could be selected.
The remaining three areas all came back clear. The existing control plane protocols were already good enough, the protection and restoration options could be narrowed down later, and network management raised no obstacle. Nothing in these areas stopped the two organizations from working together.
- ForwardingMPLS forwarding as specified by the IETF RFCs needs no changes to support MPLS-TP.
- OAMRequirements for operations, administration and management, with a hierarchy over LSPs and pseudowires and the Associated Channel Header.
- ProtectionNo issue preventing an MPLS-TP. Three candidate solutions, to be narrowed down later, with linear and ring scenarios.
- Control planeExisting IETF protocols already provide the needed functions; GMPLS has been applied to ASON, and any extensions would be easy.
- Network managementNo issue preventing an MPLS-TP, so Option 1 could be selected.
§11IANA and Security Considerations
No IANA considerations arise from this document. Any allocations needed to implement the JWT recommendation will be requested in the Standards-Track RFCs that define the MPLS-TP protocol.
The only security consideration that arises from this document is the need to ensure that it is a faithful representation of the JWT report. The protocol work that arises from the agreement will have technical security requirements that will be identified in the RFCs that define MPLS-TP.
Nothing to allocate and nothing to secure yet. The only requirement here is that the archived report stays faithful to what the team actually decided, and the real security work belongs to the specifications that follow.