Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile
draft-bryant-mpls-tp-jwt-report-00

Network Working Group                                     S. Bryant, Ed.
Internet-Draft                                             Cisco Systems
Intended status: Informational                         L. Andersson, Ed.
Expires: January 8, 2009                                        Acreo AB
                                                            July 7, 2008

JWT Report on MPLS Architectural Considerations for a Transport Profile
                   draft-bryant-mpls-tp-jwt-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 January 8, 2009.

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, 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 January 8, 2009                [Page 1]
Internet-Draft             JWT MPLS-TP Report                  July 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 January 8, 2009                [Page 2]
Internet-Draft             JWT MPLS-TP Report                  July 2008

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 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 "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")[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 power point slides [MPLS-TP-22] [ALSO INCLUDE SELF
   REF TO PDF WHEN AVAILABLE].  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.

   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

Bryant & Andersson       Expires January 8, 2009                [Page 3]
Internet-Draft             JWT MPLS-TP Report                  July 2008

   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.

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

   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

Bryant & Andersson       Expires January 8, 2009                [Page 4]
Internet-Draft             JWT MPLS-TP Report                  July 2008

   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 will 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 (RFC 4929),

      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 [REF]

3.  Introduction and Background Material

   Slides 11 to 22 provide introductory and background material.

Bryant & Andersson       Expires January 8, 2009                [Page 5]
Internet-Draft             JWT MPLS-TP Report                  July 2008

   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.

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

Bryant & Andersson       Expires January 8, 2009                [Page 6]
Internet-Draft             JWT MPLS-TP Report                  July 2008

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

   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

Bryant & Andersson       Expires January 8, 2009                [Page 7]
Internet-Draft             JWT MPLS-TP Report                  July 2008

   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 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
   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 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 January 8, 2009                [Page 8]
Internet-Draft             JWT MPLS-TP Report                  July 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/file470.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 January 8, 2009                [Page 9]
Internet-Draft             JWT MPLS-TP Report                  July 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 January 8, 2009               [Page 10]
Internet-Draft             JWT MPLS-TP Report                  July 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 January 8, 2009               [Page 11]