Network Working Group S. Bryant, Ed.
Request for Comments: 5317 Cisco Systems
Category: Informational L. Andersson, Ed.
Acreo AB
February 2009
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
联合工作组（JWT）关于传输配置文件的MPLS体系结构考虑的报告
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.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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).
本RFC存档了IETF-ITU-T联合工作组（JWT）关于MPLS在传输网络中的应用的报告。JWT建议的选项1：IETF和ITU-T共同同意合作，将传输需求纳入IETF，并通过IETF标准流程扩展IETF MPLS转发、OAM（操作、管理和管理）、生存性、网络管理和控制平面协议，以满足这些需求。此RFC有ASCII格式（包含幻灯片摘要）和PDF格式（包含幻灯片摘要和副本）。
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 ....................................................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
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.
多年来，ITU-T一直在设计一种用于传输网络的面向连接的分组交换技术。传输网络可以被认为是提供广域连接的网络，其他服务（如IP或电话网络）在该网络上运行。ITU-T选择使IETF的MPLS适应这项任务，并引入了称为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].
在ITU-T设计和规范周期的后期，ITU-T和IETF之间就这项技术进行了多次联络交流。这些联络可在IETF联络声明网页[联络]上找到。此外，MPLS、PWE3、BFD和CCAMP工作组的主席以及路由和互联网区域主任出席了一些ITU-T会议。在这一过程中，IETF越来越担心IETF MPLS和ITU-T T-MPLS的不兼容性将“对互联网和传输网络构成相互威胁”。这些担忧促使IESG和IAB主席采取步骤，向ITU-T发送联络，声明T-MPLS要么应成为完全兼容的MPLS协议，在IETF过程中标准化（所谓的“选项1”），要么应成为具有新名称和全新代码点集的完全分离的协议（所谓的“选项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.
备选方案1和备选方案2在斯图加特（斯图加特）举行的问题12研究组15的ITU-T会议上进行了讨论，会上建议成立一个联合（ITU-T-IETF）小组来评估这些问题，并就最佳的前进方向向ITU-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 [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.
在IETF管理层和ITU-T讨论之后，成立了一个联合工作组（JWT）；这得到了IETF设计团队和ITU-T[ahtmpls]中T-MPLS特设小组的支持。特设小组的第一次会议是在2008年2月的国际电联日内瓦全体会议期间举行的。由于JWT的工作以及由此产生的关于前进道路的协议，人们对ITU-T开发的一套下一代网络传输规范可能导致互操作性问题的担忧得到了缓解。
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.
JWT以一套电源点幻灯片[MPLS-TP-22]的形式向ITU-T和IETF管理层提交了报告。（参见本RFC的PDF。）ITU-T已接受JWT的建议，如[MPLS-TP]中所述。本RFC以IETF可访问的格式归档JWT报告。
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.
此RFC有ASCII格式（包含幻灯片摘要）和PDF格式（包含幻灯片摘要和副本）。如果摘要和幻灯片之间存在冲突，则以幻灯片为准。由于这些幻灯片是IETF和ITU-T之间重要协议的基础，因此应进一步注意，如果幻灯片的PDF版本与JWT联合主席于2008年4月18日通过电子邮件发送给ITU-T和IETF管理层的幻灯片不同，则以电子邮件发送的幻灯片为准。
Slides 4 to 10 provide an executive summary of the JWT Report. The following is a summary of those slides:
幻灯片4至10提供了JWT报告的执行摘要。以下是这些幻灯片的摘要：
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).
JWT就选项1的建议达成共识：共同同意共同工作，将传输需求纳入IETF，并通过IETF标准流程扩展IETF MPLS转发、OAM、生存性、网络管理和控制平面协议，以满足这些需求。联合工作组相信，这将实现改善交通网络和互联网功能、保证完全互操作性和架构健全性的共同目标。该技术将被称为MPLS传输配置文件（MPLS-TP）。
The JWT recommended that future work should focus on:
联合工作组建议，今后的工作应侧重于：
In the IETF:
在IETF中：
Definition of the MPLS "Transport Profile" (MPLS-TP).
MPLS“传输配置文件”（MPLS-TP）的定义。
In the ITU-T:
在ITU-T中：
Integration of MPLS-TP into the transport network,
将MPLS-TP集成到传输网络中，
Alignment of the current T-MPLS ITU-T Recommendations with MPLS-TP and,
将当前的T-MPLS ITU-T建议与MPLS-TP和，
Termination of the work on current T-MPLS.
终止当前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.
技术可行性分析的结论是，方案1的建议中不存在“显示障碍”问题，IETF MPLS和伪线架构可以扩展以支持传输功能需求。因此，监测组认为没有必要对任何其他备选方案进行分析。
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:
JWT建议MPLS互操作性设计团队（MEAD团队）、JWT和特设T-MPLS小组继续履行SG15 TD515/PLEN[JWTcreation]中所述的职责：
Facilitate the rapid exchange of information between the IETF and ITU-T,
促进IETF和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.
这些团体都无权创建或修改IETF RFC或ITU-T建议。任何此类工作都将通过各自标准机构的正常流程进行。IETF和ITU-T的专家需要直接参与这项工作。
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:
联合工作组建议将支持ITU-T传输网络要求的MPLS-TP的标准定义纳入IETF RFCs。它建议ITU-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 [RFC4929],
制定ITU-T建议，以允许MPLS-TP与当前的传输设备和网络集成，包括与IETF达成协议，通过MPLS变更过程定义MPLS-TP体系结构中的任何ITU-T特定功能[RFC4929]，
Revise existing ITU-T Recommendations to align with MPLS-TP,
修订现有的ITU-T建议，以与MPLS-TP保持一致，
ITU-T Recommendations will make normative references to the appropriate RFCs.
ITU-T建议将对适当的RFC进行规范性参考。
The executive summary contains a number of detailed JWT recommendations to both IETF and ITU-T management together with proposed document structure and timetable.
执行摘要包含JWT向IETF和ITU-T管理层提出的许多详细建议，以及拟议的文件结构和时间表。
These JWT recommendations were accepted by ITU-T management [MPLS-TP1].
这些JWT建议被ITU-T管理层[MPLS-TP1]接受。
Slides 11 to 22 provide introductory and background material.
幻灯片11至22提供了介绍性和背景材料。
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.
分析的出发点是试图通过展示高层架构、任何演出停止点以及在做出合作决策后需要解决的设计点来满足选项1。IETF认为方案1是首选方案，由于方案1被证明是可行的，因此未对方案2进行探讨。
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.
这项工作分为五组：转发、OAM、保护、控制平面和网络管理。以下各节报告了每次审查的结果，总结如下。
There follows a detailed description of the overall requirements and architectural assumptions that would be used in the remainder of the work.
下文详细描述了将在剩余工程中使用的总体要求和架构假设。
Slides 23 to 28 provide a high-level architectural view of the proposed design.
幻灯片23至28提供了拟议设计的高层建筑视图。
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.
描述了MPLS-TP需要解决的服务范围和更广泛的MPLS上下文，以及供应问题。定义了理解MPLS-TP所需的一些基本术语，并提供了一些上下文示例。
Slides 29 to 32 describe the OAM requirements and talk about segment recovery and node identification.
幻灯片29至32描述了OAM需求，并讨论了段恢复和节点标识。
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.
幻灯片33至38介绍了OAM层次结构，并描述了标签交换路径（LSP）监控、维护端点（MEP）和维护中间点（MIP）关系以及LSP和伪线（PW）监控关系。
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).
第39侧到第46侧引入了相关联的信道报头（ACH）及其泛化，以便通过使用“标签为您”（LFU）在lsp上承载OAM。
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.
幻灯片47至48详细描述了转发和ACH OAM机制的工作方式。描述了大量场景，以逐个案例的方式完成操作。这些幻灯片引入了一种新的文本表示法，以简化复杂MPLS堆栈的描述。
Note that the MPLS forwarding, as specified by IETF RFCs, requires no changes to support MPLS-TP.
请注意，IETF RFCs规定的MPLS转发不需要更改以支持MPLS-TP。
Sides 79 to 83 discuss various aspects of the control plane design.
第79至83面讨论了控制平面设计的各个方面。
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.
控制平面小组表示，现有IETF协议可用于提供传输网络运行和数据通信网络/交换电路网络运行所需的功能。IETF GMPLS协议已经应用于自动交换光网络（ASON）架构，JWT认为任何需要的协议扩展都很容易实现。幻灯片提供了许多场景来演示这一结论。
The survivability considerations are provided in slides 95 to 104.
幻灯片95至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.
生存能力小组未发现任何妨碍创建MPLS-TP的问题，因此建议选择选项1。确定了三种可能的解决办法。每种解决方案都有不同的属性和优点，人们认为，在设计阶段的进一步工作应该消除一个或多个这些选项和/或提供适用性声明。
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.
在进行了一些澄清和讨论之后，幻灯片中接下来将介绍一些线性和环形保护场景，并举例说明如何解决这些场景。
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.
幻灯片106陈述了网络管理子团队的结论：没有发现阻止创建MPLS-TP的问题，因此可以选择选项1。
Slide 113 provides a summary of the JWT report.
幻灯片113提供了JWT报告的摘要。
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.
JWT没有发现任何阻碍演出的因素，一致认为他们已经找到了一个可行的解决方案。因此，他们建议选择1。他们表示，在他们看来，现有MPLS体系结构可以扩展以满足传输配置文件的要求，并且该体系结构允许LSP、PWs和深度嵌套网络采用单一OAM技术，这在技术上是可行的。通过对各种ITU-T研究小组和IETF工作小组的调查，似乎MPLS保留标签14的实施和部署已经足够广泛，因此解决方案可能必须使用不同的保留标签（例如，标签13）。JWT建议停止对标签14的扩展。
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.
JWT进一步建议，该架构似乎包含Y.1711，因为其报告中提出的机制可以满足要求。
There are no IANA considerations that arise from this document.
本文件不涉及IANA考虑事项。
Any IANA allocations needed to implement the JWT recommendation will be requested in the Standards-Track RFCs that define the MPLS-TP protocol.
实施JWT建议所需的任何IANA分配都将在定义MPLS-TP协议的标准跟踪RFC中请求。
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.
本文件引起的唯一安全考虑是需要确保这是JWT报告的忠实陈述。
The protocol work that arises from this agreement will have technical security requirements that will be identified in the RFCs that define MPLS-TP.
本协议产生的协议工作将具有技术安全要求，这些要求将在定义MPLS-TP的RFC中确定。
In the PDF of this RFC, there follows the JWT report as a set of slides.
在本RFC的PDF中，JWT报告后面有一组幻灯片。
[Ethertypes] IESG and IAB, "T-MPLS use of the MPLS Ethertypes", 2006, <https://datatracker.ietf.org/documents/LIAISON/ file470.txt>.
[Ethertypes]IESG和IAB，“MPLS Ethertypes的T-MPLS使用”，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>.
[JWT]主席，ITU-T SG 15，“关于设立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/>.
[联络]IETF与IETF之间的联络声明可在以下网址找到：<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]“IETF和ITU-T在扩展MPLS以实现传输网络功能方面的合作”，2008年5月<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-TP-22]IETF-ITU-T联合工作组，“传输配置文件的MPLS体系结构考虑”，2008年4月<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>.
[MPLS-TP1]“IETF和ITU-T在扩展MPLS以实现传输网络功能方面的合作”，ITU-T SG15，2008年5月<https://datatracker.ietf.org/documents/ 联络处/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.
[RFC4929]Andersson，L.和A.Farrel，“多协议标签交换（MPLS）和通用MPLS（GMPLS）协议和程序的变更过程”，BCP 129，RFC 49292007年6月。
[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.
[斯图加特]IETF-IESG和IAB主席，“关于T-MPLS的第12问题临时会议报告”，德国斯图加特，附件4，2007年9月12日至14日，2008年<http://ties.itu.int/u//tsg15/ sg15/xchange/wp3/200709_joint_q12_q14_stuttgart/T-MPLS/wdt03_report-final.doc>。本文件可根据ITU-T的要求提供。
[ahtmpls] "Ad Hoc group on T-MPLS", 2008, <http://www.itu.int/ ITU-T/studygroups/com15/ahtmpls.html>.
[ahtmpls]“T-MPLS特设小组”，2008年<http://www.itu.int/ ITU-T/studygroup/com15/ahtmpls.html>。
Editors' Addresses
编辑地址
Stewart Bryant (editor) Cisco Systems 250, Longwater, Green Park, Reading RG2 6GB UK
Stewart Bryant（编辑）思科系统250，朗沃特，格林公园，阅读RG2 6GB英国
EMail: stbryant@cisco.com
EMail: stbryant@cisco.com
Loa Andersson (editor) Acreo AB Isafjordsgatan 22 Kista, Sweden
Loa Andersson（编辑）Acreo AB Isafjordsgatan 22基斯塔，瑞典
EMail: loa@pi.nu
EMail: loa@pi.nu