One document matched: draft-bryant-mpls-tp-jwt-report-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-bryant-mpls-tp-jwt-report-00"
ipr="full3978">
<front>
<title abbrev="JWT MPLS-TP Report">JWT Report on MPLS Architectural
Considerations for a Transport Profile</title>
<author fullname="Stewart Bryant" initials="S" role="editor"
surname="Bryant">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>250, Longwater, Green Park,</street>
<city>Reading</city>
<code>RG2 6GB, UK</code>
<country>UK</country>
</postal>
<email>stbryant@cisco.com</email>
</address>
</author>
<author fullname="Loa Andersson" initials="L" role="editor"
surname="Andersson">
<organization>Acreo AB</organization>
<address>
<postal>
<street>Isafjordsgatan 22</street>
<city>Kista</city>
<region></region>
<code></code>
<country>Sweden</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>loa@pi.nu</email>
<uri></uri>
</address>
</author>
<date year="2008" />
<area>Routing Area</area>
<workgroup>Network Working Group</workgroup>
<keyword>Sample</keyword>
<keyword>Draft</keyword>
<abstract>
<t>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, survivability, network management and control
plane protocols to meet those requirements through the IETF Standards
Process. There are two versions of this RFC. An ASCII version that
contains a summary of the slides and a PDF version that contains the
summary and a copy of the slides.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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 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.</t>
<t>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 <xref target="T-MPLS1"></xref>, and 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 and fully compliant MPLS
protocol, standardised 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”)<xref target="Ethertypes"></xref>.</t>
<t>Option 1 and Option 2 were discussed at an ITU-T meeting of Question
12 Study Group 15 in Stuttgart <xref target="Stuttgart"></xref>, 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.</t>
<t>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 <xref
target="ahtmpls"></xref>. The first meeting of the Ad Hoc group occurred
during the ITU-T Geneva Plenary in February this year. 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.</t>
<t>The JWT submitted their report to ITU-T and IETF management in the
form of a set of power point slides <xref target="MPLS-TP-22"></xref>
[ALSO INCLUDE SELF REF TO PDF WHEN AVAILABLE]. The ITU-T have accepted
the JWT recommendations, as documented in <xref
target="MPLS-TP"></xref>. This RFC archives the JWT report in a format
that is accessible to the IETF.</t>
<t>There are two versions of this RFC. An ASCII version that contains a
summary of the slides and a PDF version that 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 18th
April 2008 by the co-chairs of the JWT, the emailed slides take
precedence.</t>
</section>
<section title="Executive Summary">
<t>Slides 4 to 10 provide an executive summary of the JWT Report. The
following is a summary of those slides:</t>
<t>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 fulfil 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)</t>
<t>The JWT recommended that future work should focus on:</t>
<t>In the IETF: <list>
<t>Definition of the MPLS “Transport Profile”
(MPLS-TP).</t>
</list> In the ITU-T: <list>
<t>Integration of MPLS-TP into the transport network,</t>
<t>Alignment of the current T-MPLS ITU-T Recommendations with
MPLS-TP and,</t>
<t>Termination of the work on current T-MPLS.</t>
</list>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.</t>
<t>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 <xref target="JWTcreation"></xref> with the following
roles:<list>
<t>Facilitate the rapid exchange of information between the IETF and
ITU-T,</t>
<t>Ensure that the work is progressing with a consistent set of
priorities,</t>
<t>Identify gaps/inconsistencies in the solutions under
development,</t>
<t>Propose solutions for consideration by the appropriate
WG/Question,</t>
<t>Provide guidance when work on a topic is stalled or a technical
decision must be mediated.</t>
</list>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.</t>
<t>The JWT recommended that the normative definition of the MPLS-TP that
supports the ITU-T transport network requirements will be captured in
IETF RFCs. It proposed that the ITU-T should:<list>
<t>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 (RFC
4929),</t>
<t>Revise existing ITU-T Recommendations to align with MPLS-TP,</t>
<t>ITU-T Recommendations will make normative references to the
appropriate RFCs.</t>
</list></t>
<t>The executive summary contains a number of detailed JWT
recommendations to both IETF and ITU-T management together with proposed
document structure and timetable.</t>
<t>These JWT recommendations were accepted by ITU-T management [REF]</t>
</section>
<section title="Introduction and Background Material">
<t>Slides 11 to 22 provide introductory and background material.</t>
<t>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 has 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.</t>
<t>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 following sections and is summarised below.</t>
<t>There follows a detailed description of the overall requirements and
architectural assumptions that would be used in the remainder of the
work.</t>
</section>
<section title="High-Level Architecture ">
<t>Slides 23 to 28 provide a high-level architectural view of the
proposed design.</t>
<t>The spectrum of services that MPLS-TP needs to address and the wider
MPLS context is described, together with the provisioning issues. Some
basic terminology needed to understand the MPLS-TP is defined and some
context examples provided.</t>
</section>
<section title="OAM and Forwarding">
<t>Slides 29 to 32 describe the OAM requirements and talk about segment
recovery and node identification.</t>
<t>Slides 33 to 38 introduce OAM hierarchy and describe LSP monitoring,
the MEP and MIP relationship and the LSP and PW monitoring
relationship.</t>
<t>Sides 39 to 46 introduce the Associated Channel Header and its
generalisation to carry the OAM over LSPs through the use of the "Label
for You" (LFU).</t>
<t>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.</t>
<t>Note that the MPLS forwarding, as specified by IETF RFCs, requires no
changes to support MPLS-TP.</t>
</section>
<section title="Control Plane">
<t>Sides 79 to 83 discuss various aspects of the control plane
design.</t>
<t>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 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.</t>
</section>
<section title="Survivability">
<t>The survivability considerations are provided in slides 95 to 104</t>
<t>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 solutions has
different attributes and advantages, and thought that further work in
the design phase should eliminate one or more of these options and/or
provide an applicability statement.</t>
<t>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.</t>
</section>
<section title="Network Management">
<t>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.</t>
</section>
<section title="Summary">
<t>Slide 113 provides a summary of the JWT report.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="IANA considerations ">
<t>There are no IANA considerations that arise from this draft.</t>
<t>Any IANA allocations needed to implement the JWT recommendation will
be requested in the standards-track RFCs that define the MPLS-TP
protocol.</t>
</section>
<section title="Security Considerations">
<t>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.</t>
<t>The protocol work that arises from this agreement will have technical
security requirements which will be identified in the RFCs that define
MPLS-TP.</t>
</section>
<section title="The JWT Report">
<t>In the PDF version of this RFC [REF to PDF VERSION] there follows the
JWT report as a set of slides.</t>
<t><vspace blankLines="21" /></t>
</section>
</middle>
<back>
<references title="Informative References"></references>
<references title="URL References">
<reference anchor="MPLS-TP-22">
<front>
<title>http://www.ietf.org/MPLS-TP_overview-22.pdf</title>
<author>
<organization>IETF - ITU-T Joint Working Team</organization>
</author>
<date year="2008" />
</front>
</reference>
<reference anchor="T-MPLS1">
<front>
<title>Various ITU-T and IETF Liaison Statements Concerning T-MPLS,
https://datatracker.ietf.org/liaison/</title>
<author>
<organization>IETF and ITU-T</organization>
</author>
<date year="" />
</front>
</reference>
<reference anchor="Ethertypes">
<front>
<title>T-MPLS use of the MPLS Ethertypes,
https://datatracker.ietf.org/documents/LIAISON/file470.txt</title>
<author>
<organization>ITU-T, SG 15 Question 12</organization>
</author>
<date year="2006" />
</front>
</reference>
<reference anchor="Stuttgart">
<front>
<title>Report of interim meeting of Q.12 on T-MPLS - Stuttgart,
Germany, 12-14 September , 2007, Annex
4,http://ties.itu.int/u//tsg15/sg15/xchange/wp3/200709_joint_q12_q14_stuttgart/T-MPLS/wdt03_rapporteur_report-final.doc</title>
<author>
<organization>IETF - IESG and IAB Chairs</organization>
</author>
<date year="2006" />
</front>
</reference>
<reference anchor="JWTcreation">
<front>
<title>Proposal to establish an Ad Hoc group on T-MPLS,
http://www.itu.int/md/T05-SG15-080211-TD-PLEN-0515/en</title>
<author>
<organization>Chairman, ITU-T SG 15</organization>
</author>
<date year="2008" />
</front>
</reference>
<reference anchor="ahtmpls">
<front>
<title>Ad Hoc group on T-MPLS,
http://www.itu.int/ITU-T/studygroups/com15/ahtmpls.html</title>
<author>
<organization></organization>
</author>
<date year="2008" />
</front>
</reference>
<reference anchor="MPLS-TP">
<front>
<title>IETF and ITU-T cooperation on extensions to MPLS for
transport network functionality,
https://datatracker.ietf.org/liaison/446/</title>
<author>
<organization></organization>
</author>
<date year="2008" />
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-22 02:17:57 |