doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc5317.txt b/doc/rfc/rfc5317.txt
new file mode 100644
index 0000000..33c00aa
--- /dev/null
+++ b/doc/rfc/rfc5317.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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).
+
+
+
+
+
+
+
+
+
+
+
+
+Bryant & Andersson           Informational                      [Page 1]
+
+RFC 5317                   JWT MPLS-TP Report              February 2009
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryant & Andersson           Informational                      [Page 2]
+
+RFC 5317                   JWT MPLS-TP Report              February 2009
+
+
+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.
+
+
+
+
+
+
+Bryant & Andersson           Informational                      [Page 3]
+
+RFC 5317                   JWT MPLS-TP Report              February 2009
+
+
+   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.
+
+
+
+
+
+Bryant & Andersson           Informational                      [Page 4]
+
+RFC 5317                   JWT MPLS-TP Report              February 2009
+
+
+   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].
+
+
+
+
+
+
+Bryant & Andersson           Informational                      [Page 5]
+
+RFC 5317                   JWT MPLS-TP Report              February 2009
+
+
+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).
+
+
+
+
+
+
+
+
+Bryant & Andersson           Informational                      [Page 6]
+
+RFC 5317                   JWT MPLS-TP Report              February 2009
+
+
+   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.
+
+
+
+
+
+
+Bryant & Andersson           Informational                      [Page 7]
+
+RFC 5317                   JWT MPLS-TP Report              February 2009
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryant & Andersson           Informational                      [Page 8]
+
+RFC 5317                   JWT MPLS-TP Report              February 2009
+
+
+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>.
+
+
+
+
+
+
+
+
+
+
+
+Bryant & Andersson           Informational                      [Page 9]
+
+RFC 5317                   JWT MPLS-TP Report              February 2009
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryant & Andersson           Informational                     [Page 10]
+