Internet Engineering Task Force (IETF) N. Sprecher
Request for Comments: 6670 Nokia Siemens Networks
Category: Informational KY. Hong
ISSN: 2070-1721 Cisco Systems
July 2012
Internet Engineering Task Force (IETF) N. Sprecher
Request for Comments: 6670 Nokia Siemens Networks
Category: Informational KY. Hong
ISSN: 2070-1721 Cisco Systems
July 2012
The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM)
为MPLS传输配置文件（MPLS-TP）操作、管理和维护（OAM）选择单一解决方案的原因
Abstract
摘要
The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS technology for use in transport network deployments. The work on MPLS-TP has extended the MPLS technology with additional architectural elements and functions that can be used in any MPLS deployment. MPLS-TP is a set of functions and features selected from the extended MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks.
MPLS传输配置文件（MPLS-TP）是用于传输网络部署的MPLS技术的配置文件。关于MPLS-TP的工作扩展了MPLS技术，增加了可用于任何MPLS部署的体系结构元素和功能。MPLS-TP是从扩展的MPLS工具集中选择并以一致的方式应用的一组功能和特性，以满足分组传输网络运营商的需求和要求。
During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment.
在概要文件的开发过程中，添加了MPLS工具集，以确保可用的工具满足要求。这些添加是由MPLS-TP推动的，但它们构成了更广泛的MPLS工具集的一部分，因此它们中的任何一个都可以用于任何MPLS部署。
One major set of additions provides enhanced support for Operations, Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address the requirements for MPLS-TP OAM, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization.
一组主要的新增功能为操作、管理和维护（OAM）提供了增强的支持。这使得故障管理和性能监控达到传输网络所需的水平。为了满足MPLS-TP OAM的要求，已经提出了许多解决方案和协议扩展，本文档阐述了选择一组统一的解决方案进行标准化的原因。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6670.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6670.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Background .................................................5
1.2. The Development of a Parallel MPLS-TP OAM Solution .........7
2. Terminology .....................................................8
2.1. Acronyms ...................................................8
3. Motivations for a Single OAM Solution in MPLS-TP ................9
3.1. MPLS-TP Is an MPLS Technology ..............................9
3.2. MPLS-TP Is a Convergence Technology ........................9
3.3. There Is an End-to-End Requirement for OAM ................10
3.4. The Complexity Sausage ....................................10
3.5. Interworking Is Expensive and Has Deployment Issues .......11
3.6. Selection of a Single OAM Solution When There Is a
Choice ....................................................13
3.7. Migration Issues ..........................................14
4. Potential Models for Coexistence ...............................15
4.1. Protocol Incompatibility ..................................15
4.2. Inevitable Coexistence ....................................16
4.3. Models for Coexistence ....................................16
4.3.1. The Integrated Model ...............................17
4.3.2. The Island Model ...................................18
5. The Argument for Two Solutions .................................20
5.1. Progress of the IETF Solution .............................20
5.2. Commonality with Ethernet OAM .............................21
5.3. Different Application Scenarios ...........................21
5.4. Interaction between Solutions .............................22
5.5. Letting the Market Decide .................................23
6. Security Considerations ........................................24
7. Acknowledgments ................................................24
8. References .....................................................24
8.1. Normative References ......................................24
8.2. Informative References ....................................25
Appendix A. Examples of Interworking Issues in the Internet .......27
A.1. IS-IS/OSPF .................................................27
A.2. Time Division Multiplexing Pseudowires .....................28
A.3. Codecs .....................................................28
A.4. MPLS Signaling Protocols ...................................29
A.5. IPv4 and IPv6 ..............................................29
Appendix B. Other Examples of Interworking Issues .................30
B.1. SONET and SDH ..............................................30
B.2. IEEE 802.16d and IEEE 802.16e ..............................32
B.3. CDMA and GSM ...............................................32
1. Introduction ....................................................4
1.1. Background .................................................5
1.2. The Development of a Parallel MPLS-TP OAM Solution .........7
2. Terminology .....................................................8
2.1. Acronyms ...................................................8
3. Motivations for a Single OAM Solution in MPLS-TP ................9
3.1. MPLS-TP Is an MPLS Technology ..............................9
3.2. MPLS-TP Is a Convergence Technology ........................9
3.3. There Is an End-to-End Requirement for OAM ................10
3.4. The Complexity Sausage ....................................10
3.5. Interworking Is Expensive and Has Deployment Issues .......11
3.6. Selection of a Single OAM Solution When There Is a
Choice ....................................................13
3.7. Migration Issues ..........................................14
4. Potential Models for Coexistence ...............................15
4.1. Protocol Incompatibility ..................................15
4.2. Inevitable Coexistence ....................................16
4.3. Models for Coexistence ....................................16
4.3.1. The Integrated Model ...............................17
4.3.2. The Island Model ...................................18
5. The Argument for Two Solutions .................................20
5.1. Progress of the IETF Solution .............................20
5.2. Commonality with Ethernet OAM .............................21
5.3. Different Application Scenarios ...........................21
5.4. Interaction between Solutions .............................22
5.5. Letting the Market Decide .................................23
6. Security Considerations ........................................24
7. Acknowledgments ................................................24
8. References .....................................................24
8.1. Normative References ......................................24
8.2. Informative References ....................................25
Appendix A. Examples of Interworking Issues in the Internet .......27
A.1. IS-IS/OSPF .................................................27
A.2. Time Division Multiplexing Pseudowires .....................28
A.3. Codecs .....................................................28
A.4. MPLS Signaling Protocols ...................................29
A.5. IPv4 and IPv6 ..............................................29
Appendix B. Other Examples of Interworking Issues .................30
B.1. SONET and SDH ..............................................30
B.2. IEEE 802.16d and IEEE 802.16e ..............................32
B.3. CDMA and GSM ...............................................32
The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology for use in transport network deployments. Note that "transport" in this document is used in the context of transport networks as discussed in Section 1.3 of [RFC5654] and in [RFC5921]. The work on MPLS-TP has extended the MPLS toolset with additional architectural elements and functions that can be used in any MPLS deployment. MPLS-TP is a set of functions and features selected from the extended MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks.
MPLS传输配置文件（MPLS-TP）是用于传输网络部署的MPLS技术配置文件。注意，本文件中的“传输”用于[RFC5654]第1.3节和[RFC5921]中讨论的传输网络。关于MPLS-TP的工作扩展了MPLS工具集，增加了可用于任何MPLS部署的体系结构元素和功能。MPLS-TP是从扩展的MPLS工具集中选择并以一致的方式应用的一组功能和特性，以满足分组传输网络运营商的需求和要求。
Operations, Administration, and Maintenance (OAM) plays a significant role in carrier networks, providing methods for fault management and performance monitoring in both the transport and service layers, and enabling these layers to support services with guaranteed and strict Service Level Agreements (SLAs) while reducing their operational costs.
运营、管理和维护（OAM）在运营商网络中发挥着重要作用，为传输层和服务层的故障管理和性能监控提供了方法，并使这些层能够通过有保证且严格的服务水平协议（SLA）支持服务，同时降低运营成本。
OAM provides a comprehensive set of capabilities that operate in the data plane. Network-oriented mechanisms are used to monitor the network's infrastructure in order to enhance the network's general behavior and level of performance. Service-oriented mechanisms are used to monitor the services offered to end customers. Such mechanisms enable rapid response to a failure event and facilitate the verification of some SLA parameters. Fault management mechanisms are used for fault detection and localization as well as for diagnostics and notification. Performance management mechanisms enable monitoring of the quality of service with regard to key SLA criteria (e.g., jitter, latency, and packet loss).
OAM提供了在数据平面上运行的一整套功能。面向网络的机制用于监控网络的基础设施，以增强网络的一般行为和性能水平。面向服务的机制用于监控向最终客户提供的服务。这种机制能够快速响应故障事件，并有助于验证某些SLA参数。故障管理机制用于故障检测和定位以及诊断和通知。性能管理机制能够根据关键SLA标准（例如抖动、延迟和数据包丢失）监控服务质量。
During the process of development of MPLS-TP, additions to the MPLS toolset have been made to ensure that the tools available meet the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset, such that any of them could be used in any MPLS deployment.
在开发MPLS-TP的过程中，对MPLS工具集进行了添加，以确保可用的工具满足要求。这些添加是由MPLS-TP推动的，但它们是更广泛的MPLS工具集的一部分，因此它们中的任何一个都可以用于任何MPLS部署。
One major set of additions provides enhanced support for OAM. Many solutions and protocol extensions have been proposed to address these OAM requirements. This document sets out the reasons for selecting a single, coherent set of OAM solutions for standardization.
一组主要的附加组件提供了对OAM的增强支持。已经提出了许多解决方案和协议扩展来满足这些OAM需求。本文件阐述了选择一套统一的OAM解决方案进行标准化的原因。
The content of this document should be read in the context of [RFC1958]. In particular, Section 3.2 of [RFC1958] says:
本文件的内容应在[RFC1958]的上下文中阅读。具体而言，[RFC1958]第3.2节规定：
If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements.
如果有几种方法做同一件事，选择一种。如果以前的设计在互联网环境或其他地方成功地解决了相同的问题，请选择相同的解决方案，除非有充分的技术理由不这样做。应尽可能避免相同协议功能的重复，当然不要使用此参数来拒绝改进。
The ITU-T and the IETF jointly commissioned a Joint Working Team (JWT) to examine the feasibility of a collaborative solution to support OAM requirements for MPLS transport networks known as the MPLS Transport Profile (MPLS-TP). The JWT reported that it is possible to extend the MPLS technology to fully satisfy the requirements [RFC5317]. The investigation by the JWT laid the foundations for the work to extend MPLS, but a thorough technical analysis was subsequently carried out within the IETF with strong input from the ITU-T to ensure that the MPLS-TP OAM requirements provided by the ITU-T and the IETF would be met.
ITU-T和IETF联合委托了一个联合工作组（JWT）来研究一个协作解决方案的可行性，以支持MPLS传输网络的OAM要求，称为MPLS传输配置文件（MPLS-TP）。JWT报告说，可以扩展MPLS技术以完全满足要求[RFC5317]。JWT的调查为扩展MPLS的工作奠定了基础，但随后在ITU-T的大力投入下，在IETF内进行了彻底的技术分析，以确保满足ITU-T和IETF提供的MPLS-TP OAM要求。
The report of the JWT [RFC5317] as accepted by the ITU-T was documented in [TD7] and was communicated to the IETF in a liaison statement [LS26]. In particular, the ITU-T stated that any extensions to MPLS technology will be progressed via the IETF standards process using the procedures defined in [RFC4929].
ITU-T接受的JWT[RFC5317]报告记录在[TD7]中，并在联络声明[LS26]中传达给IETF。特别是，ITU-T声明，MPLS技术的任何扩展都将使用[RFC4929]中定义的程序，通过IETF标准流程进行。
[RFC5317] includes the analysis that "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". This provided a starting point for the work on MPLS-TP.
[RFC5317]包括以下分析：“现有MPLS体系结构可以扩展以满足传输配置文件的要求，并且该体系结构允许LSP、PWs和深度嵌套网络采用单一OAM技术，这在技术上是可行的”。这为MPLS-TP的工作提供了一个起点。
[RFC5654] in general, and [RFC5860] in particular, define a set of requirements for OAM functionality in MPLS-TP that are applicable to MPLS-TP Label Switched Paths (LSPs), Pseudowires (PWs), and MPLS-TP links. These documents are the results of a joint effort by the ITU-T and the IETF to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to enable the deployment of a packet transport network that supports the capabilities and functionalities of a transport network as defined by the ITU-T. The OAM requirements are derived from those specified by the ITU-T in [Y.Sup4].
[RFC5654]通常，特别是[RFC5860]定义了适用于MPLS-TP标签交换路径（LSP）、伪线（PW）和MPLS-TP链路的MPLS-TP中OAM功能的一组要求。这些文件是ITU-T和IETF共同努力的结果，目的是在IETF MPLS和伪线仿真边到边（PWE3）中包含MPLS传输配置文件支持ITU-T定义的传输网络的能力和功能的分组传输网络的部署架构。OAM要求源自ITU-T在[Y.Sup4]中规定的要求。
An analysis of the technical options for OAM solutions was carried out by a design team (the MEAD team) consisting of experts from both the ITU-T and the IETF. The team reached an agreement on the principles of the design and the direction for the development of an MPLS-TP OAM toolset. A report was subsequently submitted to the IETF MPLS working group at the Stockholm IETF meeting in July 2009 [DesignReport]. The guidelines drawn up by the design team have played an important role in the creation of a coherent MPLS-TP OAM solution.
由ITU-T和IETF专家组成的设计团队（MEAD团队）对OAM解决方案的技术选项进行了分析。团队就MPLS-TP OAM工具集的设计原则和开发方向达成一致。随后，在2009年7月斯德哥尔摩IETF会议上，向IETF MPLS工作组提交了一份报告【设计报告】。设计团队制定的指导方针在创建一致的MPLS-TP OAM解决方案方面发挥了重要作用。
The MPLS working group has modularized the function of MPLS-TP OAM, allowing for separate and prioritized development of solutions. This has given rise to a number of documents each describing a different part of the solution toolset. At the time of this writing, the most important of these documents have completed development within the MPLS working group and are advancing through the IETF process toward publication as RFCs. These documents cover the following OAM features:
MPLS工作组对MPLS-TP OAM的功能进行了模块化，允许对解决方案进行单独和优先的开发。这就产生了许多文档，每个文档描述了解决方案工具集的不同部分。在撰写本文时，这些文件中最重要的部分已经在MPLS工作组内完成了开发，并正在通过IETF过程向RFC的发布迈进。这些文档包括以下OAM功能：
o Continuity Check
o 连续性检查
o Connection Verification
o 连接验证
o On-Demand Connection Verification
o 按需连接验证
o Route Tracing
o 路线追踪
o Remote Defect Indication
o 远程缺陷指示
o Packet Loss Measurement
o 丢包测量
o Packet Delay Measurement
o 包延迟测量
o Lock Instruction
o 锁定指令
o Loopback Testing
o 回测
o Fault Management
o 故障管理
The standardization process within the IETF allows for the continued analysis of whether the OAM solutions under development meet the documented requirements, and facilitates the addition of new requirements if any are discovered. It is not the purpose of this document to analyze the correctness of the selection of specific OAM solutions. This document is intended to explain why it would be unwise to standardize multiple solutions for MPLS-TP OAM, and to show
IETF中的标准化过程允许继续分析开发中的OAM解决方案是否满足记录的需求，并在发现任何新需求时，促进添加新需求。本文档的目的不是分析特定OAM解决方案选择的正确性。本文档旨在解释为什么将多个MPLS-TP OAM解决方案标准化是不明智的，并展示
how the existence of multiple solutions would complicate MPLS-TP development and deployment, making networks more expensive to build, less stable, and more costly to operate.
多个解决方案的存在将使MPLS-TP的开发和部署复杂化，使网络的构建成本更高，稳定性更低，运行成本更高。
It has been suggested that a second (i.e., different) OAM solution should also be developed and documented in an ITU-T Recommendation. Various arguments have been presented for this duplication of effort, including the following:
有人建议，还应开发第二个（即不同的）OAM解决方案，并将其记录在ITU-T建议中。对于这种重复工作，提出了各种论点，包括：
o Similarity to OAM encodings and mechanisms used in Ethernet.
o 与以太网中使用的OAM编码和机制相似。
o The existence of two distinct MPLS-TP deployment environments: Packet Switched Networks (PSNs) and Packet Transport Networks (PTNs).
o 存在两种不同的MPLS-TP部署环境：分组交换网络（PSN）和分组传输网络（PTN）。
o The need for similar operational experience in MPLS-TP networks and in pre-existing transport networks (especially Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) networks).
o 在MPLS-TP网络和现有传输网络（特别是同步光网络/同步数字体系（SONET/SDH）网络）中需要类似的操作经验。
The first of these was discussed within the IETF's MPLS working group where precedence was given to adherence to the JWT's recommendation to select a solution that reused as far as possible pre-existing MPLS tools. Additionally, it was decided that consistency with encodings and mechanisms used in MPLS was of greater importance.
IETF的MPLS工作组讨论了其中的第一个问题，优先考虑遵守JWT的建议，选择尽可能重用现有MPLS工具的解决方案。此外，决定与MPLS中使用的编码和机制的一致性更为重要。
The second argument has not been examined in great detail because substantive evidence of the existence of two deployment environments has not been documented or presented. Indeed, one of the key differences cited between the two allegedly distinct environments is the choice of MPLS-TP OAM solution, which makes a circular argument.
第二个论点没有得到非常详细的审查，因为没有记录或提出存在两个部署环境的实质性证据。事实上，这两个据称截然不同的环境之间引用的关键区别之一是MPLS-TP OAM解决方案的选择，这是一个循环论证。
The third argument contains a very important point: network operators want to achieve a smooth migration from legacy technologies such as SONET/SDH to their new packet transport networks. This transition can be eased if the new networks offer similar OAM features and can be managed using tools with similar look and feel. The requirements specifications [RFC5654] and [RFC5860] capture the essential issues that must be resolved to allow the same look and feel to be achieved. Since the OAM solutions developed within the IETF meet the documented requirements, Network Management Systems (NMSs) can easily be built to give the same type of control of MPLS-TP networks as is seen in other transport networks. Indeed, it should be understood that the construction of an NMS is not dependent on the protocols and packet formats within the OAM but on the high-level features and functions offered by the OAM.
第三个论点包含一个非常重要的观点：网络运营商希望实现从传统技术（如SONET/SDH）到新的分组传输网络的平滑迁移。如果新网络提供类似的OAM功能，并且可以使用具有类似外观的工具进行管理，那么这种转换可以得到缓解。需求规范[RFC5654]和[RFC5860]捕获了必须解决的基本问题，以实现相同的外观和感觉。由于IETF内开发的OAM解决方案满足文件要求，因此可以轻松构建网络管理系统（NMS），以提供与其他传输网络相同的MPLS-TP网络控制类型。事实上，应该理解的是，NMS的构建并不依赖于OAM内的协议和分组格式，而是依赖于OAM提供的高级特性和功能。
This document does not debate the technical merits of any specific solution. That discussion, and the documentation of MPLS-TP OAM specifications, was delegated by the IETF and ITU-T to the MPLS working group and can be conducted using the normal consensus-driven IETF process. [OAM-OVERVIEW] presents an overview of the OAM mechanisms that have already been defined and that are currently being defined by the IETF, as well as a comparison with other OAM mechanisms that were defined by the IEEE and ITU-T.
本文件不讨论任何具体解决方案的技术优点。该讨论和MPLS-TP OAM规范的文件由IETF和ITU-T委托给MPLS工作组，可以使用通常的一致性驱动的IETF过程进行。[OAM概述]概述了IETF已经定义和目前正在定义的OAM机制，以及与IEEE和ITU-T定义的其他OAM机制的比较。
This document focuses on an examination of the consequences of the existence of two MPLS-TP OAM solutions.
本文档重点研究两种MPLS-TP OAM解决方案存在的后果。
This document uses the following acronyms:
本文件使用以下首字母缩略词：
ANSI American National Standards Institute CESoPSN Circuit Emulation Service over Packet Switched Network ETSI European Telecommunications Standards Institute FPGA Field-Programmable Gate Array GFP Generic Framing Procedure IEEE Institute of Electrical and Electronics Engineers ITU-T International Telecommunication Union - Telecommunication Standardization Sector JWT Joint Working Team LSP Label Switched Path MPLS-TP MPLS Transport Profile NMS Network Management System OAM Operations, Administration, and Maintenance PDH Plesiochronous Digital Hierarchy PSN Packet Switched Network PTN Packet Transport Network PW Pseudowire PWE3 Pseudowire Emulation Edge-to-Edge SAToP Structure-Agnostic Time Division Multiplexing over Packet SDH Synchronous Digital Hierarchy SLA Service Level Agreement SONET Synchronous Optical Network TDM Time Division Multiplexing TDMoIP Time Division Multiplexing over IP
ANSI美国国家标准协会CESoPSN分组交换网络电路仿真服务ETSI欧洲电信标准协会FPGA现场可编程门阵列GFP通用成帧程序IEEE电气和电子工程师协会ITU-T国际电信联盟-电信标准化部门JWT联合工作组LSP标签交换路径MPLS-TP MPLS传输配置文件NMS网络管理系统OAM操作、管理、，和维护PDH准同步数字体系PSN分组交换网PTN分组传输网PW伪线PWE3伪线仿真边到边SAToP结构不可知分组SDH上的时分复用同步数字体系SLA服务级别协议SONET同步光网络TDM时分IP上的时分多路复用
This section presents a discussion of the implications of the development and deployment of more than one MPLS OAM protocol. The summary is that it can be seen that there are strong technical, operational, and economic reasons to avoid the development and deployment of anything other than a single MPLS OAM protocol.
本节讨论了开发和部署多个MPLS OAM协议的含义。综上所述，可以看出，避免开发和部署单一MPLS OAM协议以外的任何协议都有很强的技术、操作和经济原因。
MPLS-TP is an MPLS technology. It is designed to apply MPLS to a new application. The original proposers of the concept assumed that the transport variant of MPLS would always exist in a disjoint network, and indeed their first attempt at the technology (Transport MPLS (T-MPLS)) had a number of significant incompatibilities with MPLS that were irreconcilable. When it was established that coexistence in the same layer network could and would occur, T-MPLS development was stopped and the development of MPLS-TP was begun. In MPLS-TP, MPLS was extended to satisfy the transport network requirements in a way that was compatible both with MPLS as has already been deployed, and with MPLS as the IETF envisioned it would develop in the future.
MPLS-TP是一种MPLS技术。它旨在将MPLS应用于新的应用程序。最初提出这一概念的人假设MPLS的传输变体总是存在于不相交的网络中，事实上，他们第一次尝试这项技术（传输MPLS（T-MPLS））与MPLS有许多不可调和的重大不兼容性。当确定在同一层网络中可能会出现共存时，T-MPLS的开发就停止了，MPLS-TP的开发也就开始了。在MPLS-TP中，MPLS被扩展以满足传输网络需求，其方式既与已经部署的MPLS兼容，也与IETF设想的未来发展的MPLS兼容。
Given this intention for compatibility, it follows that the MPLS-TP OAM protocols should be designed according to the design philosophies that were applied for the existing deployed MPLS OAM and that have led to the current widespread adoption of MPLS. Key elements here are scalability and hardware independence, i.e., that the trade-off between scaling to large numbers of monitored objects and the performance of the monitoring system should be a matter for vendors and operators to resolve, and that the trade-off should be a soft transition rather than an abrupt one. Furthermore, there should be no requirement to execute any component (other than packet forwarding) in hardware to achieve usable performance.
考虑到兼容性的这一意图，MPLS-TP OAM协议应根据适用于现有已部署MPLS OAM的设计理念进行设计，这些设计理念已导致当前广泛采用MPLS。这里的关键要素是可伸缩性和硬件独立性，即，扩展到大量监控对象和监控系统性能之间的权衡应由供应商和运营商来解决，并且权衡应该是软过渡，而不是突然过渡。此外，不应要求在硬件中执行任何组件（包转发除外），以实现可用性能。
It is possible to argue that using MPLS for transport is only a stepping stone in the middle of a longer transition. Quite clearly, all communication applications are being moved to operate over the Internet protocol stack of TCP/IP/MPLS, and the various layers that have existed in communications networks are gradually being collapsed into the minimum necessary set of layers. Thus, for example, we no longer run IP over X.25 over High-Level Data Link Control (HDLC) over multi-layered Time Division Multiplexing (TDM) networks.
有可能争辩说，使用MPLS运输只是过渡期中的一块垫脚石。很明显，所有的通信应用程序都被转移到TCP/IP/MPLS的Internet协议栈上运行，而通信网络中存在的各个层正逐渐被压缩到最小必要的层组中。因此，例如，我们不再在多层时分复用（TDM）网络上的高级数据链路控制（HDLC）上运行IP over X.25。
Increasingly, the entire point of transport networks is to support the transmission of TCP/IP/MPLS. Using MPLS to construct a transport network may be a relatively short-term stepping stone toward running
传输网络的整个点越来越支持TCP/IP/MPLS的传输。使用MPLS构建传输网络可能是走向运行的相对短期的垫脚石
IP and MPLS directly over fiber optics. MPLS has been deployed in operational networks for approximately a decade, and the existing MPLS OAM techniques have seen wide deployment. Service providers are not going to stop using the MPLS-based OAM techniques that they have been using for years, and no one has proposed that they would. Thus, the question is not which OAM to use for transport networks; the question is whether service providers want to use two different sets of OAM tools in the future converged network. If we arrive at a destination where TCP/IP/MPLS runs directly over fiber, the operators will use MPLS OAM tools to make this work.
IP和MPLS直接通过光纤传输。MPLS已经在运营网络中部署了大约十年，现有的MPLS OAM技术已经得到了广泛的部署。服务提供商不会停止使用多年来一直使用的基于MPLS的OAM技术，也没有人建议他们停止使用。因此，问题不在于将哪个OAM用于传输网络；问题是服务提供商是否希望在未来的融合网络中使用两套不同的OAM工具。如果我们到达一个TCP/IP/MPLS直接通过光纤运行的目的地，运营商将使用MPLS OAM工具来实现这一点。
The purpose of OAM is usually to execute a function that operates end to end on the monitored object (such as an LSP or PW). Since LSPs and PWs provide edge-to-edge connectivity and can cross network operator boundaries, the OAM must similarly operate across network operator boundaries. This is particularly the case with the continuity check and connection verification functions that are needed to test the end-to-end connectivity of LSPs and PWs. It is, therefore, necessary that any two pieces of equipment that could ever be a part of an end-to-end communications path have a common OAM. This necessity is emphasized in the case of equipment executing an edge function, since with a global technology such as MPLS it could be interconnected with edge equipment deployed by any other operator in any part of the global network.
OAM的目的通常是执行一个在被监视对象（如LSP或PW）上端到端运行的函数。由于LSP和PW提供边到边连接，并且可以跨越网络运营商边界，因此OAM必须类似地跨网络运营商边界运行。测试LSP和PW的端到端连接所需的连续性检查和连接验证功能尤其如此。因此，可能是端到端通信路径一部分的任何两个设备都必须具有公共OAM。在设备执行边缘功能的情况下强调了这一必要性，因为使用诸如MPLS的全球技术，它可以与全球网络任何部分中任何其他运营商部署的边缘设备互连。
This leads to the conclusion that it is desirable for any network-layer protocol in all equipment to be able to execute or to interwork with a canonical form of the OAM. As discussed in Section 4, interworking between protocols adds significant complexity; thus, a single default OAM is strongly preferred.
这导致了这样一个结论，即所有设备中的任何网络层协议都希望能够执行OAM的标准形式或与之交互。如第4节所述，协议之间的互通增加了显著的复杂性；因此，强烈建议使用单个默认OAM。
A frequent driver for the replacement of an established technology is a perception that the new technology is simpler and thus of greater economic benefit to the user. In an isolated system, this may be the case; however, as is usually the case with communications technologies, simplification in one element of the system introduces an increase (possibly a non-linear one) in complexity elsewhere.
更换现有技术的一个常见驱动因素是认为新技术更简单，因此对用户具有更大的经济效益。在隔离系统中，可能会出现这种情况；然而，与通信技术通常的情况一样，系统中一个元素的简化会导致其他地方复杂性的增加（可能是非线性的）。
This creates the "squashed sausage" effect, where reduction in complexity at one place leads to significant increase in complexity at a remote location. When we drive complexity out of hardware by placing complexity in the control plane, there is frequently an economic benefit, as illustrated by MPLS itself.
这就产生了“挤压香肠”效应，一个地方的复杂性降低会导致远程位置的复杂性显著增加。当我们通过将复杂性放在控制平面上而将复杂性从硬件中去除时，通常会带来经济效益，如MPLS本身所示。
Some motivation for the second OAM solution is the simplicity of operation at a single node in conjunction with other transport OAM mechanisms. However, when we drive OAM complexity out of one network element at the cost of increased complexity at a peer network element, we lose out economically and, more importantly, we lose out in terms of the reliability of this important network functionality. Due to the need to ensure compatibility of an interworking function between the two MPLS-TP OAM solutions (in order to achieve end-to-end OAM), we create a situation where neither of two disjoint protocol developments is able to make technical advances. Such a restriction is unacceptable within the context of the Internet.
第二个OAM解决方案的一些动机是在单个节点上与其他传输OAM机制一起操作的简单性。然而，当我们以增加对等网络元素的复杂性为代价将OAM复杂性从一个网络元素中排除时，我们在经济上损失了，更重要的是，我们在这一重要网络功能的可靠性方面损失了。由于需要确保两个MPLS-TP OAM解决方案之间互通功能的兼容性（以实现端到端OAM），我们造成了两个不相交的协议开发都无法取得技术进步的情况。这种限制在互联网环境下是不可接受的。
The issue of OAM interworking can easily be illustrated by considering an analogy with people speaking different languages. Interworking is achieved through the use of an interpreter. The interpreter introduces cost, slows down the rate of information exchange, and may require transition through an intermediate language. There is considerable risk of translation errors and semantic ambiguities. These considerations also apply to computer protocols, particularly given the ultra-pedantic nature of such systems. In all cases, the availability of a single working language dramatically simplifies the system, reduces cost, and speeds reliable communication.
OAM互通的问题可以很容易地通过与说不同语言的人进行类比来说明。通过使用口译员实现互通。口译员会带来成本，降低信息交换速度，可能需要通过中间语言进行转换。翻译错误和语义歧义的风险很大。这些考虑也适用于计算机协议，特别是考虑到此类系统的超迂腐性。在所有情况下，单一工作语言的可用性极大地简化了系统，降低了成本，加快了可靠的通信。
If two MPLS OAM protocols were to be deployed, we would have to consider three possible scenarios:
如果要部署两个MPLS OAM协议，我们必须考虑三种可能的方案：
1. Isolation of the network into two incompatible and unconnected islands.
1. 将网络隔离为两个不兼容且未连接的孤岛。
2. Universal use of both OAM protocols.
2. 两种OAM协议的通用性。
3. Placement of interworking (translation) functions or gateways.
3. 互通（翻译）功能或网关的位置。
We have many existence proofs that isolation is not a viable approach, and the reader is referred to the early T-MPLS discussions for examples. In summary, the purpose of the Internet is to achieve an integrated universal connectivity. Partition of the Internet into incompatible and unconnected islands is neither desirable nor acceptable.
我们有许多证据证明隔离不是一种可行的方法，读者可以参考早期T-MPLS讨论的例子。总之，互联网的目的是实现综合的通用连接。将互联网划分为不兼容和不相连的岛屿既不可取，也不可接受。
Universal deployment of both OAM protocols requires the sum of the costs associated with each protocol. This manifests as implementation time, development costs, memory requirements, hardware components, and management systems. It introduces additional testing requirements to ensure there are no conflicts (processing state,
两个OAM协议的通用部署都需要与每个协议相关的成本总和。这表现为实现时间、开发成本、内存需求、硬件组件和管理系统。它引入了额外的测试要求，以确保没有冲突（处理状态，
fault detection, code path, etc.) when both protocols are run on a common platform. It also requires code and the processes to deal with the negotiation of which protocol to use and to deal with conflict resolution (which may be remote and multi-party) when an inconsistent choice is made. In short, this option results in more than double the cost, increases the complexity of the resulting system, risks the stability of the deployed network, and makes the networks more expensive and more complicated to operate.
当两个协议在一个公共平台上运行时，故障检测、代码路径等）。它还需要代码和流程来处理使用哪个协议的协商，以及在做出不一致的选择时处理冲突解决（可能是远程和多方的）。简言之，此选项会导致成本增加一倍以上，增加最终系统的复杂性，威胁已部署网络的稳定性，并使网络更昂贵，操作更复杂。
The third possibility is the use of some form of interworking function. This is not a simple solution and inevitably leads to cost and complexity in implementation, deployment, and operation. Where there is a chain of communication (end-to-end messages passed through a series of transit nodes), a choice must be made about where to apply the translation and interworking.
第三种可能性是使用某种形式的互通功能。这不是一个简单的解决方案，不可避免地会导致实施、部署和操作的成本和复杂性。如果存在通信链（通过一系列传输节点传递的端到端消息），则必须选择在何处应用翻译和互通。
o In a layered architecture, interworking can be achieved through tunneling with the translation points at the end-points of the tunnels. In simple network diagrams, this can look very appealing, and only one end-node is required to be able to perform the translation function (effectively speaking both OAM languages). But in the more complex reality of the Internet, nearly every network node performs the function of an end-node, and so the result is that nearly every node must be implemented with the capability to handle both OAM protocols and to translate between them. This turns out to be even more complex than the universal deployment of both protocols discussed above.
o 在分层架构中，可以通过隧道与隧道端点处的平移点实现互通。在简单的网络图中，这看起来非常吸引人，只需要一个终端节点就可以执行翻译功能（有效地说两种OAM语言）。但在更复杂的互联网现实中，几乎每个网络节点都执行一个终端节点的功能，因此结果是几乎每个节点都必须能够处理两个OAM协议并在它们之间进行转换。事实证明，这比上述两种协议的通用部署更加复杂。
o In a flat architecture, interworking is performed at a "gateway" between islands implementing different protocols. Gateways are substantially complex entities that usually have to maintain end-to-end state within the network (something that is against one of the fundamental design principles of the Internet) and must bridge the differences in state machines, message formats, and information elements in the two protocols. The complexity of gateways makes them expensive, fragile, and unstable; hard to update when new revisions of protocols are released; and difficult to manage.
o 在平面架构中，在实现不同协议的岛之间的“网关”上执行互通。网关是非常复杂的实体，通常必须在网络中保持端到端的状态（这违反了互联网的基本设计原则之一），并且必须弥合两个协议中状态机、消息格式和信息元素的差异。网关的复杂性使其昂贵、脆弱且不稳定；协议的新修订版本发布时难以更新；而且很难管理。
To deploy an interworking function, it is necessary to determine whether the OAM protocol on the arriving segment of the OAM is identical to the OAM protocol on the departing segment. Where the protocols are not the same, it is necessary to determine which party will perform the translation. It is then necessary to route the LSP or PW through a translation point that has sufficient translation capacity and sufficient data bandwidth, as well as adequate path
要部署互通功能，必须确定OAM到达段上的OAM协议是否与离开段上的OAM协议相同。如果协议不同，则有必要确定由哪一方执行翻译。然后有必要将LSP或PW路由通过具有足够翻译容量和足够数据带宽以及足够路径的翻译点
diversity. When an upgraded OAM function is required, the problem changes from a two-party negotiation to an n-party negotiation with commercial and deployment issues added to the mix.
差异当需要升级的OAM功能时，问题将从两方协商变为n方协商，并将商业和部署问题添加到混合中。
Note that when an end-to-end LSP or PW is deployed, it may transit many networks, and the OAM might require repeated translation back and forth between the OAM protocols. The consequent loss of information and potential for error is similar to the children's game of "telephone".
注意，当部署端到端LSP或PW时，它可能会传输许多网络，并且OAM可能需要在OAM协议之间来回重复转换。由此造成的信息丢失和潜在的错误类似于儿童的“电话”游戏。
When there is a choice of protocols for deployment or operation, a network operator must make a choice. Choice can be a good thing when it provides for selection between different features and functions, but it is a burden when the protocols offer essentially the same functions but are incompatible.
当需要选择用于部署或操作的协议时，网络运营商必须做出选择。当选择提供不同特性和功能之间的选择时，它可能是一件好事，但当协议提供基本相同的功能但不兼容时，它是一种负担。
In this case, the elements of the choice include the following:
在这种情况下，选择的要素包括：
o Which protocol will continue to be developed by its Standards Development Organization (SDO)?
o 哪个协议将继续由其标准开发组织（SDO）开发？
o Which protocol is most stable in implementations?
o 哪种协议在实现中最稳定？
o How does a network operator test and evaluate the two protocols?
o 网络运营商如何测试和评估这两个协议？
o Which vendors support and will continue to support which protocol?
o 哪些供应商支持并将继续支持哪种协议？
o What equipment from different vendors is compatible?
o 来自不同供应商的哪些设备是兼容的？
o Which management tools support which protocols?
o 哪些管理工具支持哪些协议？
o What protocols are supported by peer operators, and what interworking function is needed?
o 对等运营商支持哪些协议，需要哪些互通功能？
o Which protocols are engineers experienced with and trained in?
o 工程师在哪些协议方面有经验并接受过培训？
o What are the consequences of a wrong choice?
o 错误选择的后果是什么？
o Will it be possible to migrate from one protocol to another in the future?
o 将来是否可能从一个协议迁移到另一个协议？
o How is integration with other functions already present in the network accomplished?
o 如何实现与网络中已有的其他功能的集成？
o How does a network operator future-proof against the inclusion of new functions in the network?
o 网络运营商如何证明未来不会在网络中加入新功能？
At the very least, the evaluation of these questions constitutes a cost and introduces delay for the operator. The consequence of a wrong choice could be very expensive, and it is likely that any comparative testing will more than double the lab-test costs prior to deployment.
至少，对这些问题的评估构成了成本，并给运营商带来了延误。错误选择的后果可能非常昂贵，而且在部署之前，任何比较测试都可能使实验室测试成本增加一倍以上。
From a vendor's perspective, the choice is even harder. A vendor does not want to risk not offering a product for which there is considerable demand, so both protocols may need to be developed, leading to more than doubled development costs. Indeed, code complexity and defect rates have often been shown to increase more than linearly with code size, and (as noted in Section 3.5) the need to test for coexistence and interaction between the protocols adds to the cost and complexity.
从供应商的角度来看，选择更加困难。供应商不想冒险不提供需求量很大的产品，因此可能需要开发这两种协议，从而导致开发成本增加一倍以上。事实上，代码复杂度和缺陷率通常随着代码大小的增加而线性增加，并且（如第3.5节所述）需要测试协议之间的共存和交互增加了成本和复杂度。
It should be noted that, in the long run, it is the end-users who pay the price for the additional development costs and any network instability that arises.
应该指出的是，从长远来看，是最终用户为额外的开发成本和由此产生的任何网络不稳定付出了代价。
Deployment of a technology that is subsequently replaced or obsoleted often leads to the need to migrate from one technology to another. Such a situation might arise if an operator deploys one of the two OAM protocol solutions and discovers that he needs to migrate to the other one. A specific case would be when two operators merge their networks but are using different OAM solutions.
部署随后被替换或淘汰的技术通常需要从一种技术迁移到另一种技术。如果运营商部署两个OAM协议解决方案中的一个并发现需要迁移到另一个，则可能会出现这种情况。一种特殊情况是，两个运营商合并其网络，但使用不同的OAM解决方案。
When the migration is between versions of a protocol, it may be that the new version is defined to support the old version. If the implementation is in software (including FPGAs), upgrades can be managed centrally. However, neither of these would be the case with MPLS-TP OAM mechanisms, and hardware components would need to be upgraded in the field using expensive call-out services.
当在协议版本之间进行迁移时，可能会定义新版本以支持旧版本。如果采用软件（包括FPGA）实现，则可以集中管理升级。然而，对于MPLS-TP OAM机制来说，这两种情况都不会发生，硬件组件需要在现场使用昂贵的呼叫服务进行升级。
Hardware upgrades are likely to affect service, even with sophisticated devices with redundant hardware components. Furthermore, since it would be impractical to upgrade every device in the network at the same time, there is a need for either a significantly large maintenance period across the whole network or for a rolling plan that involves upgrading nodes one at a time with new hardware that has dual capabilities. Such hardware is, of course, more expensive and more complex to configure than hardware dedicated to just one OAM protocol.
硬件升级可能会影响服务，即使是带有冗余硬件组件的复杂设备。此外，由于同时升级网络中的每个设备是不切实际的，因此需要在整个网络中大大延长维护周期，或者需要一个滚动计划，该计划涉及使用具有双重功能的新硬件一次升级一个节点。当然，这样的硬件比只用于一个OAM协议的硬件更昂贵，配置也更复杂。
Additionally, the transition phase of migration leads to dual-mode networks as described in Section 4.3. Such networks are not desirable because of their cost and complexity.
此外，迁移的过渡阶段将导致第4.3节所述的双模网络。由于成本和复杂性，这样的网络是不可取的。
In short, the potential for future migration will need to be part of the deployment planning exercise when there are two OAM protocols to choose between. This issue will put pressure on making the "right" choice when performing the selection described in Section 3.6.
简言之，当有两种OAM协议可供选择时，未来迁移的可能性需要成为部署规划工作的一部分。在执行第3.6节所述的选择时，该问题将对做出“正确”的选择产生压力。
This section expands upon the discussion in Section 3 by examining three questions:
本节在第3节讨论的基础上进一步探讨了三个问题：
o What does it mean for two protocols to be incompatible?
o 两个协议不兼容意味着什么？
o Why can't we assume that the two solutions will never coexist in the same network?
o 为什么我们不能假设这两种解决方案永远不会在同一个网络中共存？
o What models could we support for coexistence?
o 我们可以支持什么样的共存模式？
Protocol incompatibility comes in a range of grades of seriousness. At the most extreme, the operation of one protocol will prevent the safe and normal operation of the other protocol. This was the case with the original T-MPLS, where MPLS labels that could be used for data in a native MPLS system were assigned special meaning in T-MPLS such that data packets would be intercepted and mistaken for OAM packets.
协议不兼容有一系列严重程度。在最极端的情况下，一个协议的操作将阻止另一个协议的安全和正常操作。最初的T-MPLS就是这种情况，在T-MPLS中，可以用于本机MPLS系统中的数据的MPLS标签被赋予了特殊的含义，这样数据包就会被截获并误认为是OAM包。
A lesser incompatibility arises where the packets of one protocol are recognized as "unknown" or "not valid" by implementations of the other protocol. In this case, the rules of one protocol require that the packets of the other protocol be discarded and may result in the LSP or PW being torn down.
当一个协议的数据包被另一个协议的实现识别为“未知”或“无效”时，会出现较小的不兼容性。在这种情况下，一个协议的规则要求丢弃另一个协议的分组，并且可能导致LSP或PW被撕毁。
The least serious level of incompatibility is where the packets of one protocol are recognized as "unknown" by implementations of the other protocol, but where the rules of one protocol allow the packets of the other protocol to be ignored; in this case, such packets are either silently discarded or forwarded untouched.
最不严重的不兼容性级别是一个协议的数据包被另一个协议的实现识别为“未知”，但一个协议的规则允许忽略另一个协议的数据包；在这种情况下，这样的数据包要么被悄悄地丢弃，要么被原封不动地转发。
These are issues with all of these grades of incompatibility; these issues range from disruption or corruption of user data, through connection failure, to the inability to provide end-to-end OAM function without careful planning and translation functions.
这些都是所有这些级别的不兼容问题；这些问题的范围从用户数据的中断或损坏（通过连接故障）到在没有仔细规划和转换功能的情况下无法提供端到端的OAM功能。
Networks expand and merge. For example, one service provider may acquire another and wish to merge the operation of the two networks. This makes partitioning networks by protocol deployment a significant issue for future-proofing commercial interactions. Although a network operator may wish to present difficulties in order to disincentivize hostile takeover (a poison pill), most operators are interested in future options to grow their networks.
网络扩展和合并。例如，一个服务提供商可能收购另一个服务提供商，并希望合并两个网络的运营。这使得通过协议部署对网络进行分区成为未来经得起考验的商业交互的一个重要问题。虽然网络运营商可能希望提出困难，以抑制敌意收购（一种毒药），但大多数运营商对未来发展网络的选择感兴趣。
As described in Section 3.2, MPLS is a convergence technology. That means that there is a tendency for an ever-increasing number of services to be supported by MPLS and for MPLS to be deployed in an increasing number of environments. It would be an unwise operator who deployed a high-function convergence technology in such a way that the network could never be expanded to offer new services or to integrate with other networks or technologies.
如第3.2节所述，MPLS是一种融合技术。这意味着MPLS支持的服务数量有不断增加的趋势，并且MPLS部署在越来越多的环境中。如果运营商部署了高功能融合技术，使网络永远无法扩展以提供新服务或与其他网络或技术集成，那将是不明智的。
As described in Section 3.3, there is a requirement for end-to-end OAM. That means that where LSPs and PWs span multiple networks, there is a need for OAM to span multiple networks.
如第3.3节所述，需要端到端的OAM。这意味着，当LSP和PW跨越多个网络时，OAM需要跨越多个网络。
All of this means that, if two different OAM protocol technologies are deployed, there will inevitably come a time when some form of coexistence is required, no matter how carefully the separation is initially planned.
所有这一切都意味着，如果部署两种不同的OAM协议技术，那么无论最初如何仔细地计划分离，都不可避免地会出现需要某种形式的共存的时候。
Two models for coexistence can be considered:
可以考虑两种共存模式：
1. An integrated model based on the "ships-in-the-night" approach. In this model, there is no protocol translation or mapping. This model can be decomposed as follows:
1. 基于“夜间船舶”方法的综合模型。在这个模型中，没有协议转换或映射。该模型可分解如下：
* A non-integrated mixed network, where some nodes support just one protocol, some support just the other, and no node supports both protocols.
* 一种非集成混合网络，其中一些节点仅支持一种协议，一些节点仅支持另一种协议，并且没有节点同时支持两种协议。
* Partial integration, where some nodes support just one protocol, some support just the other, and some support both protocols.
* 部分集成，其中一些节点仅支持一种协议，一些节点仅支持另一种协议，而一些节点同时支持两种协议。
* Fully integrated dual mode, where all nodes support both protocols.
* 完全集成的双模式，其中所有节点都支持两种协议。
2. An "island" model, where groups of similar nodes are deployed together. In this model, there may be translation or mapping, but it is not always required. This model can be further decomposed as follows:
2. “孤岛”模型，其中相似节点组部署在一起。在这个模型中，可能有转换或映射，但并不总是必需的。该模型可进一步分解如下：
* "Islands in a sea", where connectivity between islands of the same type is achieved across a sea of a different type.
* “海洋中的岛屿”，同一类型岛屿之间的连接跨越不同类型的海洋。
* "Border crossings", where connectivity between different islands is achieved at the borders between them.
* “过境点”，即在不同岛屿之间的边界实现连接。
The integrated model assumes that nodes of different capabilities coexist within a single network. Dual-mode nodes supporting both OAM solutions may coexist in the same network. Interworking is not required in this model, and no nodes are capable of performing translation or gateway function (see Section 4.3.2 for operational modes including translation and gateways).
集成模型假设不同功能的节点在单个网络中共存。支持两种OAM解决方案的双模式节点可以共存于同一网络中。该模型中不需要互通，并且没有节点能够执行翻译或网关功能（关于包括翻译和网关在内的操作模式，请参见第4.3.2节）。
In this model, protocol messages pass as "ships in the night" unaware of each other and without perturbing each other.
在这个模型中，协议消息作为“夜间船只”传递，彼此不知道，也不会相互干扰。
As noted above, there are several sub-models.
如上所述，有几个子模型。
In a mixed network with no integration, some nodes support one protocol and other nodes support the other protocol. There are no nodes that have dual capabilities.
在没有集成的混合网络中，一些节点支持一种协议，而其他节点支持另一种协议。没有具有双重功能的节点。
All nodes on the path of an LSP or PW that are required to play an active part in OAM must support the same OAM protocol. Nodes that do not support the OAM protocol will silently ignore (and possibly discard) OAM packets from the other protocol and cannot form part of the OAM function for the LSP or PW.
LSP或PW路径上需要在OAM中扮演活动角色的所有节点必须支持相同的OAM协议。不支持OAM协议的节点将静默地忽略（并可能丢弃）来自另一协议的OAM数据包，并且不能构成LSP或PW的OAM功能的一部分。
In order to provision an end-to-end connection that benefits from the full OAM functionality, the planning and path-computation tool must know the capabilities of each network node and must select a path that includes only nodes with the same OAM protocol capability. This can result in considerably suboptimal paths and may lead to the network being partitioned. In the most obvious case, connectivity can only be achieved between end-points with the same OAM capability. This leads to considerable operational complexity and expense, as well as the inability to provide a fully flexible mesh of services.
为了提供受益于完整OAM功能的端到端连接，规划和路径计算工具必须了解每个网络节点的功能，并且必须选择仅包括具有相同OAM协议功能的节点的路径。这可能导致相当次优的路径，并可能导致网络被分区。在最明显的情况下，只能在具有相同OAM功能的端点之间实现连接。这导致相当大的操作复杂性和费用，以及无法提供完全灵活的服务网格。
In the event of dynamic network changes (such as fast reroute) or if misconnectivity occurs, nodes of mismatched OAM capabilities may become interconnected. This will disrupt traffic delivery because end-to-end continuity checks may be disrupted, and it may be hard or impossible to diagnose the problem because connectivity verification and route trace functions will not work properly.
在发生动态网络更改（如快速重新路由）或发生错误连接的情况下，OAM功能不匹配的节点可能会相互连接。这将中断流量传输，因为端到端连续性检查可能会中断，并且由于连接验证和路由跟踪功能无法正常工作，因此可能很难或不可能诊断问题。
In a partially integrated network, the network described in Section 4.3.1.1 is enhanced by the addition of a number of nodes with dual capabilities. These nodes do not possess gateway or translation capabilities (this is covered in Section 4.3.2), but each such node can act as a transit point or end-node for an LSP or PW that uses either OAM protocol.
在部分集成网络中，第4.3.1.1节中描述的网络通过添加多个具有双重功能的节点而得到增强。这些节点不具备网关或转换功能（见第4.3.2节），但每个此类节点都可以充当使用OAM协议的LSP或PW的中转点或终端节点。
Complexity of network operation is not eased, but there is greater connectivity potential in the network.
网络运行的复杂性并未得到缓解，但网络中存在着更大的连接潜力。
Dual mode is a development of partial integration (Section 4.3.1.2) such that all nodes in the network are capable of both OAM protocols. As in that section, these nodes do not possess gateway or translation capabilities (this is covered in Section 4.3.2), but each such node can act as a transit point or end-node for an LSP or PW that uses either OAM protocol. Thus, every LSP or PW in the network can be configured to use either of the OAM protocols.
双模式是部分集成（第4.3.1.2节）的发展，使得网络中的所有节点都能够使用两种OAM协议。在该节中，这些节点不具备网关或转换功能（这在第4.3.2节中有介绍），但每个这样的节点都可以充当使用OAM协议的LSP或PW的中转点或终端节点。因此，可以将网络中的每个LSP或PW配置为使用任一OAM协议。
However, it seems unlikely that an operator would choose which OAM protocol to use on a per-LSP or per-PW basis. That would lead to additional complexity in the management system and potential confusion if additional diagnostic analytics need to be performed. This mode increases the complexity of implementation, deployment, and operation without adding to the function within the network (since both OAM solutions provide the same level of function), so this mode would not be selected for deployment except, perhaps, during migration of the network from one OAM protocol to the other.
然而，运营商似乎不太可能在每个LSP或每个PW的基础上选择使用哪个OAM协议。如果需要执行额外的诊断分析，这将导致管理系统的额外复杂性和潜在的混乱。此模式增加了实现、部署和操作的复杂性，而不增加网络内的功能（因为两个OAM解决方案都提供相同级别的功能），因此不会选择此模式进行部署，除非在网络从一个OAM协议迁移到另一个OAM协议的过程中。
In the island model, regions or clusters of nodes with the same OAM capabilities are grouped together. Tools to interconnect the technologies are deployed based on layered networking or on interworking between the protocols. These lead to the two sub-models described in the sections that follow.
在孤岛模型中，具有相同OAM功能的节点区域或集群被分组在一起。互连技术的工具是基于分层网络或协议之间的互通部署的。这就引出了下面几节中描述的两个子模型。
One way to view clusters of nodes supporting one OAM protocol is as an island in a sea of nodes supporting the other protocol. In this view, tunnels are used to carry LSPs or PWs using one OAM type across the sea and into another island of a compatible OAM type. The tunnel in this case is an LSP utilizing the OAM protocol supported by the nodes in the sea. Theoretically, an island can be as small as one node, and the strait between two islands can be as narrow as just one node.
查看支持一个OAM协议的节点集群的一种方法是将其视为支持另一个协议的节点海洋中的孤岛。从这个角度来看，隧道用于通过一种OAM类型将LSP或PW运送到另一个兼容OAM类型的岛上。本例中的隧道是一个LSP，它利用sea中节点支持的OAM协议。理论上，一个岛屿可以小到一个节点，两个岛屿之间的海峡可以窄到只有一个节点。
Layering in this way is an elegant solution to operating two protocols simultaneously and is, of course, used to support different technologies (such as MPLS over optical). However, in such layering deployments, there is no simple integration of OAM between the layers, and the OAM in the upper layer must regard the tunnel as a single hop with no visibility into the OAM of the lower layer. Diagnostics within the upper layer are complicated by this "hiding" of the nodes along the path of the tunnel in the lower layer.
以这种方式分层是同时操作两个协议的优雅解决方案，当然也用于支持不同的技术（例如光网络上的MPLS）。然而，在这种分层部署中，层之间没有OAM的简单集成，上层的OAM必须将隧道视为一个单跳，不能看到下层的OAM。上层中的诊断由于节点沿下层隧道路径的“隐藏”而变得复杂。
In the scenarios described so far, both ends of each connection have been placed in islands of compatible OAM types. It is possible to achieve connectivity between a node in an island and a node in the sea if the end-point in the sea has dual capabilities (i.e., can be viewed as a single-node island).
在目前描述的场景中，每个连接的两端都被放置在兼容OAM类型的孤岛中。如果sea中的端点具有双重功能（即，可以视为单个节点岛），则可以实现岛中节点和海上节点之间的连接。
A number of islands may lie along the path between end-points, necessitating the use of more than one tunnel. To further complicate matters, the islands may lie in an inland sea so that it is necessary to nest tunnels.
许多岛屿可能位于端点之间的路径上，因此需要使用多条隧道。使事情进一步复杂化的是，这些岛屿可能位于内海，因此有必要设置隧道。
Regardless of the scenario, operating such tunnels/layers adds to the management complexity and expense. Furthermore, it should be noted that in an MPLS network there is often a call for any-to-any connectivity. That is, any node in the network may need to establish an LSP or a PW to any other node in the network. As previously noted, the end-points of any LSP or PW must support the same OAM type in the islands-in-a-sea model, so this tends to imply that all, or nearly all, nodes will end up needing to support both OAM protocols.
无论何种情况，运营此类隧道/层都会增加管理复杂性和费用。此外，应当注意的是，在MPLS网络中，通常存在对任意对任意连接的呼叫。也就是说，网络中的任何节点可能需要建立到网络中任何其他节点的LSP或PW。如前所述，任何LSP或PW的端点都必须支持海中岛屿模型中相同的OAM类型，因此这往往意味着所有或几乎所有节点最终都需要支持两种OAM协议。
The use of tunnels can also degrade network services unless carefully coordinated. For example, a service in the upper layer may be provisioned with protection so that a working and backup path is constructed using diverse paths to make them robust against a single failure. However, the paths of the tunnels (in the lower layer) are not visible to the path computation in the upper layer, with the risk that the upper layer working and protection paths share a single point of failure in the lower layer. Traffic engineering techniques
除非仔细协调，否则隧道的使用也会降低网络服务。例如，可以为上层中的服务提供保护，以便使用不同的路径构建工作和备份路径，以使它们对单个故障具有鲁棒性。但是，隧道（下层）的路径对于上层的路径计算不可见，上层的工作路径和保护路径有可能在下层共享一个故障点。交通工程技术
have been developed to resolve this type of issue, but they add significant complexity to a system that would be a simple flat network if only one OAM technology was used.
已经开发出了解决这类问题的技术，但它们增加了系统的复杂性，如果只使用一种OAM技术，该系统将是一个简单的平面网络。
Instead of connecting islands with tunnels across the sea, islands of different types can be connected directly so that the LSP or PW transits the series of islands without tunneling. In this case, protocol translation is performed each time the LSP/PW crosses a border between islands that use a different OAM protocol.
不同类型的岛屿可以直接连接，而不是通过海底隧道连接岛屿，以便LSP或PW在不通过隧道的情况下通过一系列岛屿。在这种情况下，每当LSP/PW跨越使用不同OAM协议的岛之间的边界时，执行协议转换。
In principle, this makes for a straightforward end-to-end connection. However, protocol translation presents a number of issues, as described in Section 3. The complexity is that in planning the end-to-end connection, gateways with protocol translation capabilities must be selected to lie on the path.
原则上，这使得端到端连接变得简单。然而，如第3节所述，协议翻译存在许多问题。复杂性在于，在规划端到端连接时，必须选择具有协议转换功能的网关位于路径上。
The decision to define and develop an alternative MPLS-TP OAM solution was based on several assertions:
定义和开发替代MPLS-TP OAM解决方案的决定基于以下几点：
o The IETF solution is taking too long to standardize.
o IETF解决方案的标准化时间太长。
o Commonality with Ethernet solutions is beneficial.
o 与以太网解决方案的通用性是有益的。
o There are two different application scenarios.
o 有两种不同的应用场景。
o There is no risk of interaction between the solutions.
o 解决方案之间没有相互作用的风险。
o The market should be allowed to decide between competing solutions.
o 应该允许市场在相互竞争的解决方案之间做出决定。
The following sections look briefly at each of these claims.
以下各节将简要介绍这些权利要求。
The MPLS-TP OAM work carried out within the IETF is the product of joint work within the IETF and ITU-T communities. That is, all interested parties share the responsibility for progressing this work as quickly as possible. Since the work is contribution-driven, there is no reason to assume that consensus on the technical content of the work could be reached any more quickly.
在IETF内执行的MPLS-TP OAM工作是IETF和ITU-T社区内联合工作的产物。也就是说，所有相关方都有责任尽快推进这项工作。由于这项工作是由贡献驱动的，因此没有理由认为可以更快地就工作的技术内容达成共识。
Opening discussions on a second solution seems certain to increase the workload and will only slow down the speed at which consensus is reached.
就第二个解决方案展开讨论似乎肯定会增加工作量，只会减慢达成共识的速度。
The core work on MPLS-TP OAM within the IETF was completed, and the specifications were published as RFCs. For more information, see [ISOCAnnounce].
IETF中关于MPLS-TP OAM的核心工作已经完成，规范作为RFC发布。有关更多信息，请参阅[Isocannound]。
Ethernet can be used to build packet transport networks, and so there is an argument that Ethernet and MPLS-TP networks will be operated as peers. Examining the issues of end-to-end connections across mixed networks, many of the same issues as those discussed in Section 4 arise. If a peer networking gateway model (see Section 4.3.2.2) is applied, there is a strong argument for making the OAM technologies as similar as possible.
以太网可用于构建分组传输网络，因此有一种观点认为以太网和MPLS-TP网络将作为对等网络运行。在研究跨混合网络的端到端连接问题时，会出现许多与第4节中讨论的问题相同的问题。如果采用对等网络网关模型（见第4.3.2.2节），则有充分理由使OAM技术尽可能类似。
While this might be a valid discussion point when selecting the single OAM solution for MPLS-TP, it is countered by the need to achieve OAM consistency between MPLS and MPLS-TP networks. One might make the counter-argument that if there is a strong need to make MPLS-TP as similar as possible to Ethernet, it would be better to go the full distance and simply deploy Ethernet.
虽然在为MPLS-TP选择单一OAM解决方案时，这可能是一个有效的讨论点，但需要在MPLS和MPLS-TP网络之间实现OAM一致性。有人可能会反驳说，如果强烈需要使MPLS-TP尽可能类似于以太网，那么最好是全程部署以太网。
Furthermore, the approach of a second MPLS-TP OAM protocol does not resolve anything. Since MPLS-TP is not Ethernet, a gateway will still be needed. This would constitute a second MPLS-TP OAM, so additional gateways or interworking functions will be needed because coexistence is inevitable, as described in the rest of this document.
此外，第二个MPLS-TP OAM协议的方法不能解决任何问题。由于MPLS-TP不是以太网，因此仍然需要网关。这将构成第二个MPLS-TP OAM，因此需要额外的网关或互通功能，因为共存是不可避免的，如本文档其余部分所述。
Additionally, it may be claimed that implementation can be simplified if the OAM solution developed for MPLS-TP is similar to Ethernet OAM. This would apply both in the hardware/software implementing the OAM, and at the server-to-client interface where OAM-induced fault status is reported. The questions here are very much implementation dependent, as the necessary function is contained within individual nodes. The counter-argument is that implementation simplicity can also be achieved by making MPLS-TP OAM similar to MPLS OAM, especially since the client technology may well be IP/MPLS and since MPLS is an end-to-end technology.
此外，可以声称，如果为MPLS-TP开发的OAM解决方案类似于以太网OAM，则可以简化实现。这既适用于实现OAM的硬件/软件，也适用于报告OAM引起的故障状态的服务器到客户端接口。这里的问题在很大程度上取决于实现，因为必要的功能包含在各个节点中。相反的论点是，通过使MPLS-TP OAM类似于MPLS OAM，也可以实现实现的简单性，特别是因为客户端技术很可能是IP/MPLS，而且MPLS是端到端技术。
It has been suggested that two different applications of MPLS-TP exist: Packet Switched Networks (PSNs) and Packet Transport Networks (PTNs). These applications have not been documented in the IETF, and most of the support for this idea has been documented by the ITU-T [TD522].
有人认为MPLS-TP存在两种不同的应用：分组交换网络（PSN）和分组传输网络（PTN）。IETF中没有记录这些应用程序，ITU-T[TD522]也记录了对这一想法的大部分支持。
One of the stated differences between these applications lies in the OAM tools that are required to support the distinct operational scenarios. The OAM used in a PSN should be similar to that used in an MPLS network (and so should be the MPLS-TP OAM defined in the IETF), while the OAM used in a PTN should provide the same operational experience as that found in SONET/SDH and Optical Transport Networks (OTNs).
这些应用程序之间声明的差异之一在于支持不同操作场景所需的OAM工具。PSN中使用的OAM应类似于MPLS网络中使用的OAM（IETF中定义的MPLS-TP OAM也应如此），而PTN中使用的OAM应提供与SONET/SDH和光传输网络（OTN）中相同的操作体验。
The basic MPLS-TP OAM requirements in [RFC5654] make this point as follows:
[RFC5654]中的基本MPLS-TP OAM要求将这一点说明如下：
Furthermore, for carriers it is important that operation of such packet transport networks should preserve the look-and-feel to which carriers have become accustomed in deploying their optical transport networks, while providing common, multi-layer operations, resiliency, control, and multi-technology management.
此外，对于运营商而言，重要的是，此类分组传输网络的操作应保持运营商在部署其光传输网络时已习惯的外观，同时提供公共、多层操作、弹性、控制和多技术管理。
Thus, the look and feel of the OAM has been a concern in the design of MPLS-TP from the start, and the solutions that have been defined in the IETF were designed to comply with the requirements and to provide operational behavior, functionality, and processes similar to those available in existing transport networks. In particular, the toolset supports the same controls and indications as those present in other transport networks, and the same management information model can be used to support the MPLS-TP OAM tools (in areas where the technology type is irrelevant).
因此，OAM的外观从一开始就是MPLS-TP设计中的一个关注点，IETF中定义的解决方案旨在符合要求，并提供类似于现有传输网络中可用的操作行为、功能和过程。特别是，该工具集支持与其他传输网络中相同的控制和指示，并且可以使用相同的管理信息模型来支持MPLS-TP OAM工具（在技术类型无关的领域）。
It is important to note that the operational look and feel does not determine the way in which OAM function is achieved. There are multiple ways of achieving the required functionality while still providing the same operational experience and supporting the same management information model. Thus, the OAM protocol solution does not dictate the look and feel, and the demand for a particular operational experience does not necessitate the development of a second OAM protocol.
需要注意的是，操作外观并不决定OAM功能的实现方式。在提供相同的操作体验和支持相同的管理信息模型的同时，有多种方法可以实现所需的功能。因此，OAM协议解决方案不要求外观，并且对特定操作体验的需求不需要开发第二个OAM协议。
Section 3 of this document discusses how network convergence occurs and indicates that where two MPLS-TP solutions exist, they are in fact very likely to appear either in the same network or at gateways between networks in order to provide end-to-end OAM functionality.
本文档第3节讨论了网络融合是如何发生的，并指出如果存在两个MPLS-TP解决方案，它们实际上很可能出现在同一网络中或网络之间的网关上，以提供端到端OAM功能。
Indeed, since nodes offering either solution are likely to both be branded as "MPLS-TP", and since network interoperation (as described in Section 4) demands the existence of some nodes that are either dual-mode or act as protocol translators/gateways, there is considerable likelihood of the two OAM solutions interacting through
事实上，由于提供任一解决方案的节点都可能被标记为“MPLS-TP”，并且由于网络互操作（如第4节所述）需要存在一些双模或充当协议转换器/网关的节点，因此两个OAM解决方案通过
design or through accident. When a node is capable of supporting both OAM protocols, it must be configured to support the correct protocol for each interface and LSP/PW. When a device has interfaces that offer different MPLS-TP OAM functions, the risk of misconfiguration is significant. When a device is intended to support end-to-end connections, it may need to translate, map, or tunnel to accommodate both protocols.
设计或通过事故。当一个节点能够支持两种OAM协议时，必须将其配置为支持每个接口和LSP/PW的正确协议。当设备具有提供不同MPLS-TP OAM功能的接口时，配置错误的风险非常大。当设备打算支持端到端连接时，它可能需要转换、映射或隧道以适应这两种协议。
Thus, the very existence of two OAM protocols within the common MPLS-TP family makes copresence and integration most likely.
因此，在通用MPLS-TP系列中存在两个OAM协议，这使得最有可能实现共存和集成。
When two technologies compete, it is common to let the market decide which one will survive. Sometimes the resolution is quite fast, and one technology dominates the other before there is widespread deployment. Sometimes it takes considerable time before one technology overcomes the other, perhaps because one technology has become entrenched before the emergence of the other, as in the case of MPLS replacing ATM. In more cases, however, the market does not select in favor of one technology or the other -- as in many of the cases described in Sections 4 and 5 of this document, sometimes both technologies continue to live in the network.
当两种技术竞争时，通常由市场决定哪种技术能够生存。有时，解决方案相当快，在广泛部署之前，一种技术主导了另一种技术。有时，一种技术战胜另一种技术需要相当长的时间，这可能是因为一种技术在另一种技术出现之前就已经根深蒂固，就像MPLS取代ATM一样。然而，在更多的情况下，市场不会选择一种或另一种技术——正如本文件第4节和第5节所述的许多情况，有时这两种技术都继续存在于网络中。
Letting the market decide is not a cheap option. Even when the resolution is rapid, equipment vendors and early adopters pay the price of both technologies. When it takes longer to determine which technology is correct, there will be a period of coexistence followed by the need to transition equipment from the losing solution to the winning one. In the cases where no choice is made, the network is permanently complicated by the existence of the competing technologies.
让市场决定不是一个便宜的选择。即使解决速度很快，设备供应商和早期采用者也要为这两种技术付出代价。当需要更长的时间来确定哪种技术是正确的时，将有一段共存期，然后需要将设备从失败的解决方案过渡到成功的解决方案。在没有选择的情况下，由于存在竞争性技术，网络将永远变得复杂。
In fact, the only time when allowing the market to decide can be easily supported is when the competing technologies do not overlap. In those cases -- for example, different applications in the user space -- the core network is not perturbed by the decision-making process, and transition from one technology to the other is relatively painless. This is not the case for MPLS-TP OAM; coexistence while the market determines the correct approach would be expensive, while the necessary transition after the decision has been made would be difficult and costly.
事实上，只有在竞争技术不重叠的情况下，让市场做出决定才容易得到支持。在这些情况下——例如，用户空间中的不同应用程序——核心网络不会受到决策过程的干扰，从一种技术到另一种技术的过渡相对来说比较轻松。MPLS-TP OAM并非如此；在市场决定正确方法的同时共存将是昂贵的，而在作出决定后进行必要的过渡将是困难和昂贵的。
This informational document does not introduce any security issues.
此信息性文档不会引入任何安全问题。
However, it should be noted that the existence of two OAM protocols raises a number of security concerns:
但是，应该注意的是，两个OAM协议的存在引起了一些安全问题：
o Each OAM protocol must be secured. This leads to the existence of two security solutions that each need configuration and management. The increased complexity of operating security mechanisms tends to reduce the likelihood of them being used in the field and so increases the vulnerability of the network. Similarly, the existence of two security mechanisms raises the risk of misconfiguration.
o 必须保护每个OAM协议。这导致存在两个安全解决方案，每个解决方案都需要配置和管理。操作安全机制的复杂性增加，往往会降低其在现场使用的可能性，从而增加网络的脆弱性。同样，两种安全机制的存在也增加了配置错误的风险。
o One OAM protocol may be used as a vector to attack the other. Inserting an OAM message of the other OAM protocol onto a link may cause the service to be disrupted and, because some nodes may support both OAM protocols, it may be possible to cause the disruption at a remote point in the network.
o 一个OAM协议可用作攻击另一个的向量。将另一OAM协议的OAM消息插入链路可能导致服务中断，并且由于一些节点可能支持两种OAM协议，因此可能导致网络中的远程点中断。
o Securing a network protocol is not a trivial matter for protocol designers. Duplicating design effort is unlikely to result in a stronger solution and runs the risk of diluting the effort and creating two less-secure solutions.
o 保护网络协议对于协议设计者来说不是一件小事。重复的设计工作不太可能产生更强大的解决方案，并且会有稀释工作和创建两个不太安全的解决方案的风险。
Thanks to Brian Carpenter, Tom Petch, Rolf Winter, Alexander Vainshtein, Ross Callon, Malcolm Betts, and Martin Vigoureux for their review and useful comments.
感谢Brian Carpenter、Tom Petch、Rolf Winter、Alexander Vainstein、Ross Callon、Malcolm Betts和Martin Vigoureux的评论和有用的评论。
Thanks to Huub van Helvoort for supplying text and history about SONET/SDH.
感谢Huub van Helvoort提供有关SONET/SDH的文本和历史。
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654]Niven Jenkins，B.，Ed.，Brungard，D.，Ed.，Betts，M.，Ed.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月。
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[RFC5860]Vigoureux，M.，Ed.，Ward，D.，Ed.，和M.Betts，Ed.，“MPLS传输网络中的操作、管理和维护（OAM）要求”，RFC 58602010年5月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，Ed.“互联网的架构原则”，RFC19581996年6月。
[RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006.
[RFC4553]Vainstein，A.，Ed.，和YJ。Stein，Ed.“数据包上的结构不可知时分复用（TDM）（SAToP）”，RFC4553，2006年6月。
[RFC4929] Andersson, L., Ed., and A. Farrel, Ed., "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, June 2007.
[RFC4929]Andersson，L.，Ed.，和A.Farrel，Ed.“多协议标签交换（MPLS）和通用MPLS（GMPLS）协议和程序的变更过程”，BCP 129，RFC 49292007年6月。
[RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC 5086, December 2007.
[RFC5086]Vainstein，A.，Ed.，Sasson，I.，Metz，E.，Frost，T.，和P.Pate，“分组交换网络上的结构感知时分多路复用（TDM）电路仿真服务（CESoPSN）”，RFC 5086，2007年12月。
[RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, December 2007.
[RFC5087]Stein，Y（J.），Shashoua，R.，Insler，R.，和M.Anavi，“IP时分多路复用（TDMoIP）”，RFC 5087，2007年12月。
[RFC5317] Bryant, S., Ed., and L. Andersson, Ed., "Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile", RFC 5317, February 2009.
[RFC5317]Bryant，S.，Ed.，和L.Andersson，Ed.，“联合工作组（JWT）关于传输配置文件的MPLS体系结构考虑的报告”，RFC 53172009年2月。
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921]Bocci，M.，Ed.，Bryant，S.，Ed.，Frost，D.，Ed.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，RFC 59212010年7月。
[OAM-OVERVIEW] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", Work in Progress, March 2012.
[OAM概述]Mizrahi，T.，Sprecher，N.，Bellagamba，E.，和Y.Weingarten，“运营、管理和维护（OAM）机制概述”，进展中的工作，2012年3月。
[Y.Sup4] "Supplement on transport requirements for T-MPLS OAM and considerations for the application of IETF MPLS technology", ITU-T Y.1300-series Supplement 4, January 2008.
[Y.Sup4]“关于T-MPLS OAM传输要求和IETF MPLS技术应用注意事项的补充”，ITU-T Y.1300系列补充件4，2008年1月。
[G.707] "Network node interface for the synchronous digital hierarchy (SDH)", ITU-T Recommendation G.707, January 2007.
[G.707]“同步数字体系（SDH）的网络节点接口”，ITU-T建议G.707，2007年1月。
[TD7] "IETF and ITU-T cooperation on extensions to MPLS for transport network functionality", ITU-T TD7 (WP3/SG15), December 2008.
[TD7]“IETF和ITU-T在扩展MPLS以实现传输网络功能方面的合作”，ITU-T TD7（WP3/SG15），2008年12月。
[TD522] "Clarification of the PTN/solution X environment", ITU-T TD522 (WP3/SG15), February 2011.
[TD522]“PTN/解决方案X环境的澄清”，ITU-T TD522（WP3/SG15），2011年2月。
[LS26] "Cooperation Between IETF and ITU-T on the Development of MPLS-TP", ITU-T COM 15-LS26-E, December 2008, <http://datatracker.ietf.org/documents/LIAISON/ file596.pdf>.
[LS26]“IETF和ITU-T在MPLS-TP开发方面的合作”，ITU-T COM 15-LS26-E，2008年12月<http://datatracker.ietf.org/documents/LIAISON/ 文件596.pdf>。
[DesignReport] "MPLS-TP OAM Analysis", Proc. IETF 75, Stockholm, Sweden, July 2009, <http://www.ietf.org/proceedings/75/slides/ mpls-17/mpls-17_files/frame.htm>.
[设计报告]“MPLS-TP OAM分析”，过程。IETF 75，斯德哥尔摩，瑞典，2009年7月<http://www.ietf.org/proceedings/75/slides/ mpls-17/mpls-17_files/frame.htm>。
[ISOCAnnounce] "Milestone Achieved in Internet Carrier Network Standards - Multiprotocol Label Switching Transport Profile (MPLS-TP) Specifications Published", Internet Society, December 2011, <http://www.isoc.org/standards/mpls.shtml>.
[ISO公告]“互联网运营商网络标准实现的里程碑——多协议标签交换传输模式（MPLS-TP）规范发布”，互联网协会，2011年12月<http://www.isoc.org/standards/mpls.shtml>.
It is, of course, right to observe that there are a number of instances of multiple protocols serving the same purpose that have arisen within the Internet. It is valuable to examine these examples to understand what issues they have caused and how they have been mitigated.
当然，我们可以正确地看到，互联网上出现了许多为同一目的服务的多个协议实例。检查这些示例以了解它们造成了什么问题以及如何缓解这些问题是很有价值的。
IS-IS and OSPF are two competing link-state IGP routing protocols that derive from the same root technology and that, for political and personality reasons, were never reconciled prior to wide-scale deployment. It is an accident of history that one of these protocols did not gain overwhelming deployment and so force the other into retirement.
IS-IS和OSPF是两种相互竞争的链路状态IGP路由协议，它们源于同一根技术，并且由于政治和个性原因，在大规模部署之前从未协调。这些协议中的一个没有获得压倒性的部署，从而迫使另一个退出，这是历史上的一个意外。
The existence of these two widely deployed and highly functional competing IGPs doubles the cost of link-state IGP maintenance and deployment in the Internet. This is a situation that will almost certainly continue for the lifetime of the Internet. Although the Internet is clearly successful and operates well, the existence of these two IGPs forces router vendors to implement both protocols (doubling the protocol cost of all routers even when an operator only wants to deploy one of the protocols), forcing the operator to make an active choice between IGPs during deployment and requiring a gateway function between the islands of protocol use.
这两个广泛部署且功能高度竞争的IGP的存在使互联网中链路状态IGP维护和部署的成本翻了一番。这种情况几乎肯定会在互联网的整个生命周期中持续下去。尽管互联网显然是成功的，并且运行良好，但这两个IGP的存在迫使路由器供应商实施这两个协议（即使运营商只想部署其中一个协议，也会使所有路由器的协议成本翻倍），强制运营商在部署期间在IGP和协议使用孤岛之间需要网关功能之间进行主动选择。
A mitigating factor in this specific case is that, owing to the way networks are partitioned for administrative and scaling reasons, there already existed a gateway routing protocol called BGP that propagates a summarized form of the IGP reachability information throughout the Internet. BGP means that there is actually no requirement for IS-IS and OSPF to interwork directly: that is, there is no need for a translation function between OSPF and IS-IS, and the two IGPs can continue to exist without impacting the function of the Internet. Thus, unlike the situation with MPLS OAM, the choice of IGP protocol is truly a local decision; however, there is a cost to BGP implementations that must support interactions with both OSPF and IS-IS.
在这种特定情况下，一个缓解因素是，由于出于管理和扩展原因划分网络的方式，已经存在一种称为BGP的网关路由协议，该协议在整个互联网上传播IGP可达性信息的汇总形式。BGP意味着实际上不需要is-is和OSPF直接互通：也就是说，OSPF和is-is之间不需要翻译功能，两个IGP可以继续存在而不影响互联网的功能。因此，与MPLS OAM的情况不同，IGP协议的选择实际上是一个本地决定；但是，BGP实现必须支持与OSPF和is-is的交互，这会带来成本。
The IETF's PWE3 working group has published the specification of three different TDM PW types. This happened after considerable effort to reach a compromise failed to reduce the set of options.
IETF的PWE3工作组发布了三种不同TDM PW类型的规范。这是在做出相当大的努力以达成妥协，但未能减少选项集之后发生的。
o SAToP is a relatively simple design. It is a Proposed Standard RFC [RFC4553] and is the mandatory-to-implement, default mode of operation.
o SAToP是一种相对简单的设计。这是一个建议的标准RFC[RFC4553]，是强制实施的默认操作模式。
o CESoPSN [RFC5086] and TDMoIP [RFC5087] are more complex approaches with different degrees of bandwidth efficiency optimized for different applications. They are both published as Informational RFCs.
o CESoPSN[RFC5086]和TDMoIP[RFC5087]是更复杂的方法，具有针对不同应用优化的不同程度的带宽效率。它们都作为信息RFC发布。
In this case, all implementations must include the default mode of operation (SAToP). This means that end-to-end operation is guaranteed: an operator can select equipment from any vendor in the knowledge that he will be able to build and operate an end-to-end TDM PW service.
在这种情况下，所有实现必须包括默认操作模式（SAToP）。这意味着端到端的运行是有保证的：操作员可以从任何供应商那里选择设备，因为他知道他将能够构建和运行端到端的TDM PW服务。
If an operator wishes to deploy a TDM PW optimized for a specific application, he may select equipment from a vendor offering CESoPSN or TDMoIP in addition to SAToP. Provided that all of his equipment and his management system can handle the optimized approach, he can run this in his network, but he has to carry the cost of selecting, purchasing, configuring, and operating the extended mode of operation.
如果运营商希望部署针对特定应用优化的TDM PW，则除了SAToP外，还可以从提供CESoPSN或TDMoIP的供应商处选择设备。如果他的所有设备和管理系统能够处理优化方法，他可以在他的网络中运行，但他必须承担选择、购买、配置和操作扩展操作模式的成本。
This situation is far from ideal, and it is possible that long-distance, multi-operator optimized TDM PWs cannot be achieved. However, the existence of a default mode implemented in all devices helps to reduce pain for the operator and ensures that simpler end-to-end operation is always available. Additionally, the growth of other protocols is acting to diminish the use of long-distance TDM circuits, making this a self-limiting problem.
这种情况远非理想，可能无法实现长距离、多运营商优化的TDM PWs。然而，在所有设备中实现的默认模式的存在有助于减少操作员的痛苦，并确保始终可以使用更简单的端到端操作。此外，其他协议的增长正在减少长距离TDM电路的使用，这使得这成为一个自我限制的问题。
The n-squared codec interworking problem was brought to the attention of the IETF by the ITU-T when the IETF started its work on a royalty-free codec suitable for use in the Internet. Every time a new codec is deployed, translation between it and all other deployed codecs must be available within the network; each participating node must be able to handle the new codec. Translation between codecs is expensive and can lead to reduced quality.
当IETF开始研究适合互联网使用的免版税编解码器时，ITU-T将n平方编解码器互通问题提请IETF注意。每次部署一个新的编解码器时，它与所有其他部署的编解码器之间的转换必须在网络中可用；每个参与节点必须能够处理新的编解码器。编解码器之间的转换非常昂贵，可能会导致质量下降。
This problem seriously constrains the addition of new codecs to the available set, and new codecs are only designed and released when there is a well-established need (such as a major difference in functionality).
这个问题严重限制了向可用集添加新的编解码器，并且新的编解码器仅在有明确需求（例如功能上的重大差异）时才设计和发布。
The application layer of the Internet is, however, predicated on a business model that allows for the use of shared, free, and open-source software; this model requires the existence of a royalty-free codec. This, together with the specific characteristics of transmission over lossy packet networks, comprised requirements equivalent to a major difference in functionality and led to work in the IETF to specify a new codec.
然而，互联网的应用层是建立在允许使用共享、免费和开源软件的商业模式之上的；该模型要求存在免版税的编解码器。这一点，加上有损分组网络传输的特定特征，构成了相当于功能上主要差异的需求，并导致IETF中指定新编解码器的工作。
The complexity, economic, and quality costs associated with interworking with this new codec will need to be factored into the deployment model. This, in turn, may adversely affect its adoption and the viability of its use in the Internet.
在部署模型中，需要考虑与此新编解码器交互相关的复杂性、经济性和质量成本。这反过来可能会对其采用及其在互联网上使用的可行性产生不利影响。
There are three MPLS signaling control protocols used for distributing labels to set up LSPs and PWs in MPLS networks: LDP, RSVP - Traffic Engineering (RSVP-TE), and GMPLS.
在MPLS网络中，有三种用于分发标签以建立LSP和PWs的MPLS信令控制协议：LDP、RSVP-流量工程（RSVP-TE）和GMPLS。
The application domain for each of these protocols is different, and unlike the OAM situation, there is limited requirement for interworking between the protocols. For example, although one provider may use LDP to set up LSPs while its peer uses RSVP-TE, connectivity between the two providers usually takes place at the IP layer.
每个协议的应用程序域都不同，并且与OAM情况不同，协议之间的互通要求有限。例如，尽管一个提供商可以使用LDP建立LSP，而其对等方使用RSVP-TE，但两个提供商之间的连接通常发生在IP层。
It should be noted that the IETF initially worked on another signaling protocol called Constraint-based Routed LDP (CR-LDP) with variants applicable to MPLS and GMPLS. The development of this protocol was allowed to progress in parallel with RSVP-TE. However, once it was possible to determine that the solution preferred by the community of vendors and operators was RSVP-TE, the IETF terminated all further work on CR-LDP. No translation function or gateway point interfacing RSVP-TE to CR-LDP was ever proposed.
应该注意的是，IETF最初致力于另一种称为基于约束的路由LDP（CR-LDP）的信令协议，其变体适用于MPLS和GMPLS。该协议的开发允许与RSVP-TE并行进行。然而，一旦有可能确定供应商和运营商社区首选的解决方案是RSVP-TE，IETF就终止了所有关于CR-LDP的进一步工作。从未提出将RSVP-TE连接到CR-LDP的转换功能或网关点。
If there were ever an example of why protocol interworking is to be avoided if at all possible, it is the transition from IPv4 to IPv6.
如果说有一个例子可以说明为什么要尽可能避免协议互通，那就是从IPv4到IPv6的过渡。
The reasons for introducing IPv6 into the Internet are well known and don't need discussion here. IPv6 was not introduced as a competitor to IPv4 but rather as a planned replacement. The need for the
将IPv6引入互联网的原因众所周知，这里不需要讨论。IPv6不是作为IPv4的竞争对手引入的，而是作为计划中的替代品引入的。需要
transition to IPv6 arose from the expansion of the network size beyond the wildest dreams of the creators of the Internet and from the consequent depletion of the IPv4 address space.
向IPv6的过渡产生于网络规模的扩大，超出了互联网创造者最疯狂的梦想，并由此耗尽了IPv4地址空间。
This transition has proved to be the hardest problem that the IETF has ever addressed. The invention and standardization of IPv6 were straightforward by comparison, but it has been exceptionally difficult to migrate networks from one established protocol to a new protocol.
这一转变已被证明是IETF解决过的最困难的问题。相比之下，IPv6的发明和标准化非常简单，但要将网络从一个已建立的协议迁移到一个新的协议非常困难。
The early assumption that by the time the IPv4 address space was exhausted IPv6 would be universally deployed failed to materialize due to (understandable) short-term economic constraints. Early migration would have been simpler and less costly than the current plans. The Internet is now faced with the considerable complexity of implementing and deploying interworking functions.
由于（可以理解的）短期经济限制，早期的假设，即到IPv4地址空间耗尽时，IPv6将被普遍部署，但未能实现。与目前的计划相比，早期移民更简单，成本更低。互联网现在面临着实现和部署互通功能的相当复杂的问题。
If anything can be learned from the IPv4/IPv6 experience, it is that every effort should be applied to avoid the need to migrate or jointly operate two protocols within one network. Adding to the mix, a number of issues caused by OAM interworking of MPLS, one of the Internet's core protocols, would be most unwelcome and would complicate matters still further.
如果可以从IPv4/IPv6的经验中学到什么的话，那就是应该尽一切努力避免在一个网络中迁移或联合操作两个协议。除此之外，由于MPLS（互联网的核心协议之一）的OAM互通而引起的许多问题将是最不受欢迎的，并将使问题进一步复杂化。
SONET and SDH were defined as competing standards that basically provided the same functionality (simultaneous transport of multiple circuits of differing origin within a single framing protocol). SONET was developed first by ANSI, based on the 24-channel PDH hierarchy existing in North America and Japan. The basic rate is based on DS3. Some time later, ETSI developed SDH based on the 30-channel PDH deployed in Europe. The basic rate is based on E4 (3x DS3). The key difference between PDH and SDH is that the "S" stands for "synchronous" and the "P" for "plesiochronous". Thus, the difference between the technologies is timing related.
SONET和SDH被定义为基本上提供相同功能的竞争标准（在单个帧协议中同时传输不同来源的多个电路）。SONET首先由ANSI开发，基于北美和日本现有的24通道PDH层次结构。基本费率以DS3为基础。一段时间后，ETSI基于部署在欧洲的30信道PDH开发了SDH。基本费率基于E4（3倍DS3）。PDH和SDH之间的关键区别在于，“S”表示“同步”，而“P”表示“准同步”。因此，技术之间的差异与时间有关。
SONET was adopted in the U.S., Canada, and Japan, and SDH in the rest of the world.
SONET在美国、加拿大和日本得到采用，SDH在世界其他地区得到采用。
Until 1988, the standards were unpublished and under development.
直到1988年，这些标准还没有公布，正在制定中。
o The SONET standard ANSI T1.105-1988 was published in 1988.
o SONET标准ANSI T1.105-1988于1988年发布。
o The SDH standard ETSI EN 300 417 was first published in 1992.
o SDH标准ETSI EN 300 417于1992年首次发布。
o The compromise SDH/SONET standard ITU-T G.707 was published in 1988 (see below for the nature of this compromise).
o SDH/SONET折衷标准ITU-T G.707于1988年发布（该折衷的性质见下文）。
Some implementers were confused by this situation. Equipment manufacturers initially needed to select the market segment they intended to address. The cost of chipsets for a limited market increased, and only a limited number of equipment manufacturers were available for selection in each market.
一些实现者对这种情况感到困惑。设备制造商最初需要选择他们想要解决的细分市场。有限市场的芯片组成本增加，每个市场只有有限数量的设备制造商可供选择。
Obviously, most equipment vendors wanted to sell their equipment in both regions. Hence, today most chips support both SONET and SDH, and the selection is a matter of provisioning. The impact of the additional function to support both markets has had a mixed impact on cost. It has enabled a higher volume of production, which reduced cost, but it has required increased development and complexity, which increased cost.
显然，大多数设备供应商都想在这两个地区销售他们的设备。因此，今天大多数芯片都支持SONET和SDH，选择是一个供应问题。支持两个市场的附加功能对成本的影响好坏参半。它实现了更高的生产量，从而降低了成本，但它需要增加开发和复杂性，从而增加了成本。
Because the regions of applicability of SONET and SDH are well known, service providers do not need to consider the merits of the two standards and their long-term role in the industry when examining their investment options.
由于SONET和SDH的适用性区域是众所周知的，服务提供商不需要考虑这两个标准的优点以及它们在检查其投资选项时在行业中的长期作用。
To be able to deploy SONET and SDH worldwide, the regional SDO experts came together in the ITU-T to define a frame structure and a frame rate that would allow interconnection of SONET and SDH. A compromise was agreed upon and approved in an ITU-T meeting in Seoul in 1988.
为了能够在全球范围内部署SONET和SDH，区域SDO专家在ITU-T中聚集在一起，以定义允许SONET和SDH互连的帧结构和帧速率。1988年在首尔举行的一次ITU-T会议商定并批准了一项折衷方案。
The SDH standard supports both the North American and Japanese 24-channel/T1/T3 hierarchy and the European 30-channel/E1/E4-based hierarchy within a single multiplexing structure. SDH has options for payloads at VC-4 (150 Mb/s) and above. SDH allows T1/T3 services to be delivered in Europe and E1 services to be delivered in North America using a common infrastructure.
SDH标准在单一复用结构中支持北美和日本的24信道/T1/T3层次结构和基于欧洲30信道/E1/E4的层次结构。SDH具有VC-4（150 Mb/s）及以上的有效负载选项。SDH允许使用公共基础设施在欧洲提供T1/T3服务，在北美提供E1服务。
Deployment of an E1-only standard in North America would have required the conversion of all of the 24-channel/T1 deployed equipment and services into the 30-channel/E1 format. Similarly, deployment of a T1-only standard in Europe would have required the conversion of all of the 30-channel/E1 equipment and services into
在北美部署纯E1标准需要将所有24通道/T1部署设备和服务转换为30通道/E1格式。类似地，在欧洲部署仅T1标准需要将所有30信道/E1设备和服务转换为
the 24-channel/T1 format. Clearly, given the existing network deployments (in 1988), this was not a practical proposition and was the principal reason why a compromise was reached.
24通道/T1格式。显然，考虑到现有的网络部署（1988年），这不是一个实际的提议，也是达成妥协的主要原因。
The result of the compromise is documented in ITU-T Recommendation G.707 [G.707], which includes the frame definition and frame rates and also documents how SONET and SDH can interconnect.
妥协的结果记录在ITU-T建议G.707[G.707]中，其中包括帧定义和帧速率，还记录了SONET和SDH如何互连。
An extensive interworking function had to be implemented in order to provide global connectivity (e.g., throughout the U.S. and Europe), and this resulted in an increase in operational overhead. The interworking function has to be performed before the SDH-based segment is reached. The reason for placing the interworking function on the SONET side was that in a previous agreement on interconnection the functionality was placed on the European side.
必须实施广泛的互通功能，以提供全球连接（例如，在整个美国和欧洲），这导致运营开销增加。在到达基于SDH的段之前，必须执行互通功能。将互通功能置于SONET端的原因是，在先前的互连协议中，该功能置于欧洲端。
IEEE 802.16d and IEEE 802.16e were two different, incompatible iterations of the Worldwide Interoperability for Microwave Access (WiMAX) standards. In addition to the issues described for SONET/ SDH, developers who implemented IEEE 802.16d found that they could not reuse their equipment design when developing the IEEE 802.16e variant. This increased the cost of development and lengthened the time to market.
IEEE 802.16d和IEEE 802.16e是全球微波接入互操作性（WiMAX）标准的两个不同的、不兼容的迭代。除了针对SONET/SDH描述的问题外，实施IEEE 802.16d的开发人员发现，在开发IEEE 802.16e变体时，他们无法重用其设备设计。这增加了开发成本，延长了上市时间。
Code Division Multiple Access (CDMA) and the Global System for Mobile Communications (GSM) are two competing technologies for mobile connectivity.
码分多址（CDMA）和全球移动通信系统（GSM）是两种竞争性的移动连接技术。
In addition to all the undesirable effects described above, the existence of these two technologies adversely affected customers who used roaming when overseas. Sometimes, customers were obliged to obtain an additional device from their service providers in order to roam when traveling abroad (for example, when traveling from Europe to the U.S.).
除了上述所有不良影响外，这两种技术的存在对海外使用漫游的客户产生了不利影响。有时，客户在国外旅行时（例如，从欧洲到美国旅行时）必须从其服务提供商处获得额外的设备才能漫游。
Authors' Addresses
作者地址
Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon 45241 Israel
Nurit Sprecher诺基亚西门子网络3以色列内韦内曼哈沙隆市哈纳加街45241号
EMail: nurit.sprecher@nsn.com
EMail: nurit.sprecher@nsn.com
Kyung-Yeop Hong Cisco Systems 300 Beaver Brook Road Boxborough, Massachusetts 01719 USA
美国马萨诸塞州Boxborough市比弗布鲁克路300号Kyung Yeop Hong思科系统公司01719
EMail: hongk@cisco.com
EMail: hongk@cisco.com