Network Working Group S. Bryant, Ed.
Internet-Draft Cisco Systems
Intended status: Informational L. Andersson, Ed.
Expires: December 22, 2008 Acreo AB
June 20, 2008
JWT Report on MPLS Architectural Considerations for a Transport Profile
draft-bryant-jwt-mplstp-report-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 22, 2008.
Abstract
This RFC archives the report of the IETF - ITU-T Jooint 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.
Bryant & Andersson Expires December 22, 2008 [Page 1]
Internet-Draft JWT MPLS-TP Report June 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Executive Summary . . . . . . . . . . . . . . . . . . . . . . 4
3. Introduction and Background Material . . . . . . . . . . . . . 5
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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
13.1. Informative References . . . . . . . . . . . . . . . . . 9
13.2. URL References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Bryant & Andersson Expires December 22, 2008 [Page 2]
Internet-Draft JWT MPLS-TP Report June 2008
1. Introduction
For a number of years the ITU-T has been designing a label switched
protocol 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.
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 [T-MPLS1], 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 lead to a "train wreck on the
Internet". 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, 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 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.
The JWT submitted their report to ITU-T and IETF management in the
form of a set of powerpoint slides [MPLS-TP-22] [ALSO INCLUDE SELF
REF TO PDF WHEN AVALIABLE]. The ITU-T have accepted this
recommendation, as documented in [MPLS-TP]. This RFC archives the
JWT report in a format that is accessable to the IETF.
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
Bryant & Andersson Expires December 22, 2008 [Page 3]
Internet-Draft JWT MPLS-TP Report June 2008
and the slides, the slides have normacy. Since those slides were the
basis of an important agreement between the the IETF and the ITU-T,
it should further be noted that In the event that the pdf verson of
the slides differ from those emailed to ITU-T and IETF management on
18th April 2008 by the co-chairs of the JWT, the emailed slides have
normacy.
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 acheived 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 goal of improving the
functionality of the transport networks and the internet and
guaranteeing complete interoperability and architectural soundness.
This technolgy would be refered to as the Transport Profile for MPLS
(MPLS-TP)
The JWT recommend 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 Recommendations with MPLS-TP and,
Terminate the work on current T-MPLS
The technical feasibility analysis demonstrated 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:
Bryant & Andersson Expires December 22, 2008 [Page 4]
Internet-Draft JWT MPLS-TP Report June 2008
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 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 will be captured in
IETF RFCs. It proposed that the ITU-T should:
Develop 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)
Revise existing 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 recommendations
to both IETF and ITU-T management together with proposed document
structure and timetable.
These recommendations were accepted by ITU-T management [REF]
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 has
Bryant & Andersson Expires December 22, 2008 [Page 5]
Internet-Draft JWT MPLS-TP Report June 2008
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 following sections and is summarised
below.
There followed 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 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.
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 LSP monitoring,
the MEP and MIP relationship and the LSP and PW monitoring
relationship.
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).
Slides 47 to 48 provide a didactic 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 the IETF RFCs,
requires no changes to support MPLS-TP
Bryant & Andersson Expires December 22, 2008 [Page 6]
Internet-Draft JWT MPLS-TP Report June 2008
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 DCN/SCN 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.
7. Survivability
The survivability considerations are provided in slides 95 to 104
Survivability sub-team did nit 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.
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 they 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 everyone was in agreement 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
Bryant & Andersson Expires December 22, 2008 [Page 7]
Internet-Draft JWT MPLS-TP Report June 2008
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 draft.
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 RFC
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 which will be identified in the RFCs that
define MPLS-TP.
12. The JWT Report
In the PDF version of this RFC [REF to PDF VERSION] there follows the
JWT report as a set of slides.
Bryant & Andersson Expires December 22, 2008 [Page 8]
Internet-Draft JWT MPLS-TP Report June 2008
13. References
13.1. Informative References
13.2. URL References
[Ethertypes]
ITU-T, SG 15 Question 12, "T-MPLS use of the MPLS
Ethertypes, https://datatracker.ietf.org/documents/
LIAISON/file366.txt", 2006.
[JWTcreation]
Chairman, ITU-T SG 15, "Proposal to establish an Ad Hoc
group on T-MPLS,
http://www.itu.int/md/T05-SG15-080211-TD-PLEN-0515/en",
2008.
[MPLS-TP] "IETF and ITU-T cooperation on extensions to MPLS for
transport network functionality,
https://datatracker.ietf.org/liaison/446/", 2008.
[MPLS-TP-22]
IETF - ITU-T Joint Working Team,
"http://www.ietf.org/MPLS-TP_overview-22.pdf", 2008.
[Stuttgart]
IETF - IESG and IAB Chairs, "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", 2006.
[T-MPLS1] IETF and ITU-T, "Various ITU-T and IETF Liaison Statements
Concerning T-MPLS, https://datatracker.ietf.org/liaison/".
[ahtmpls] "Ad Hoc group on T-MPLS,
http://www.itu.int/ITU-T/studygroups/com15/ahtmpls.html",
2008.
Bryant & Andersson Expires December 22, 2008 [Page 9]
Internet-Draft JWT MPLS-TP Report June 2008
Authors' Addresses
Stewart Bryant (editor)
Cisco Systems
250, Longwater, Green Park,
Reading RG2 6GB, UK
UK
Email: stbryant@cisco.com
Loa Andersson (editor)
Acreo AB
Isafjordsgatan 22
Kista,
Sweden
Phone:
Fax:
Email: loa@pi.nu
URI:
Bryant & Andersson Expires December 22, 2008 [Page 10]
Internet-Draft JWT MPLS-TP Report June 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Bryant & Andersson Expires December 22, 2008 [Page 11]