Internet Engineering Task Force (IETF) Y. Weingarten
Request for Comments: 7412
Category: Informational S. Aldrin
ISSN: 2070-1721 Huawei Technologies
P. Pan
Infinera
J. Ryoo
ETRI
G. Mirsky
Ericsson
December 2014
Internet Engineering Task Force (IETF) Y. Weingarten
Request for Comments: 7412
Category: Informational S. Aldrin
ISSN: 2070-1721 Huawei Technologies
P. Pan
Infinera
J. Ryoo
ETRI
G. Mirsky
Ericsson
December 2014
Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection
MPLS传输配置文件（MPLS-TP）共享网状网保护的要求
Abstract
摘要
This document presents the basic network objectives for the behavior of Shared Mesh Protection (SMP) that are not based on control-plane support. This document provides an expansion of the basic requirements presented in RFC 5654 ("Requirements of an MPLS Transport Profile") and RFC 6372 ("MPLS Transport Profile (MPLS-TP) Survivability Framework"). This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane.
本文档介绍了非基于控制平面支持的共享网格保护（SMP）行为的基本网络目标。本文件扩展了RFC 5654（“MPLS传输配置文件的要求”）和RFC 6372（“MPLS传输配置文件（MPLS-TP）生存性框架”）中提出的基本要求。本文件提供了在将保护交换机协调委托给数据平面的网络中，用于实现MPLS-TP数据路径SMP的任何机制的要求。
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/rfc7412.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7412.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 ....................................................3
2. Terminology and Notation ........................................3
2.1. Acronyms and Terminology ...................................4
3. Shared Mesh Protection Reference Model ..........................4
3.1. Protection or Restoration ..................................5
3.2. Scope of Document ..........................................5
3.2.1. Relationship to MPLS ................................5
4. SMP Architecture ................................................6
4.1. Coordination of Resources ..................................8
4.2. Control Plane or Data Plane ................................8
5. SMP Network Objectives ..........................................9
5.1. Resource Reservation and Coordination ......................9
5.1.1. Checking Resource Availability for Multiple
Protection Paths ....................................9
5.2. Multiple Triggers .........................................10
5.2.1. Soft Preemption ....................................10
5.2.2. Hard Preemption ....................................10
5.3. Notification ..............................................11
5.4. Reversion .................................................11
5.5. Protection Switching Time .................................11
5.6. Timers ....................................................12
5.7. Communication Channel and Fate-Sharing ....................12
6. Manageability Considerations ...................................13
7. Security Considerations ........................................13
8. Normative References ...........................................13
Acknowledgements ..................................................15
Contributors ......................................................15
Authors' Addresses ................................................16
1. Introduction ....................................................3
2. Terminology and Notation ........................................3
2.1. Acronyms and Terminology ...................................4
3. Shared Mesh Protection Reference Model ..........................4
3.1. Protection or Restoration ..................................5
3.2. Scope of Document ..........................................5
3.2.1. Relationship to MPLS ................................5
4. SMP Architecture ................................................6
4.1. Coordination of Resources ..................................8
4.2. Control Plane or Data Plane ................................8
5. SMP Network Objectives ..........................................9
5.1. Resource Reservation and Coordination ......................9
5.1.1. Checking Resource Availability for Multiple
Protection Paths ....................................9
5.2. Multiple Triggers .........................................10
5.2.1. Soft Preemption ....................................10
5.2.2. Hard Preemption ....................................10
5.3. Notification ..............................................11
5.4. Reversion .................................................11
5.5. Protection Switching Time .................................11
5.6. Timers ....................................................12
5.7. Communication Channel and Fate-Sharing ....................12
6. Manageability Considerations ...................................13
7. Security Considerations ........................................13
8. Normative References ...........................................13
Acknowledgements ..................................................15
Contributors ......................................................15
Authors' Addresses ................................................16
The MPLS Transport Profile (MPLS-TP) is described in [RFC5921]. [RFC6372] provides a survivability framework for MPLS-TP and is the foundation for this document.
[RFC5921]中描述了MPLS传输配置文件（MPLS-TP）。[RCF632]提供了MPLS-TP的生存性框架，是本文档的基础。
Terminology for recovery of connectivity in networks is provided in [RFC4427] and includes the concept of surviving network faults (survivability) through the use of re-established connections (restoration) and switching of traffic to pre-established backup paths (protection). MPLS provides control-plane tools to support various survivability schemes, some of which are identified in [RFC4426]. In addition, recent efforts in the IETF have started providing for data-plane tools to address aspects of data protection. In particular, [RFC6378] and [RFC7271] define a set of triggers and coordination protocols for 1:1 and 1+1 linear protection of point-to-point paths.
[RFC4427]中提供了网络连接性恢复的术语，包括通过使用重新建立的连接（恢复）和将通信量切换到预先建立的备份路径（保护）来保持网络故障（生存能力）的概念。MPLS提供了控制平面工具，以支持各种生存性方案，其中一些在[RFC4426]中确定。此外，IETF最近的工作已经开始提供数据平面工具，以解决数据保护方面的问题。特别是，[RFC6378]和[RFC7271]为点到点路径的1:1和1+1线性保护定义了一组触发器和协调协议。
When considering a full-mesh network and the protection of different paths that traverse the mesh, it is possible to provide an acceptable level of protection while conserving the amount of protection resources needed to protect the different data paths. As pointed out in [RFC6372] and [RFC4427], applying 1+1 protection requires that resources are allocated for use by both the working and protection paths. Applying 1:1 protection requires that the same resources are allocated but allows the resources of the protection path to be utilized for preemptible extra traffic. Extending this to 1:n or m:n protection allows the resources of the protection path to be shared in the protection of several working paths. However, 1:n or m:n protection architecture is limited by the restriction that all of the n+1 or m+n paths must have the same endpoints. m:n protection architecture provides m protection paths to protect n working paths, where m or n can be 1.
当考虑全网状网络和对穿过网状网络的不同路径的保护时，可以提供可接受的保护级别，同时节省保护不同数据路径所需的保护资源量。正如[RFC6372]和[RFC4427]中所指出的，应用1+1保护要求分配资源供工作路径和保护路径使用。应用1:1保护要求分配相同的资源，但允许将保护路径的资源用于可抢占的额外流量。将其扩展到1:n或m:n保护，可以在多个工作路径的保护中共享保护路径的资源。但是，1:n或m:n保护体系结构受到所有n+1或m+n路径必须具有相同端点的限制。m:n保护体系结构提供m个保护路径来保护n个工作路径，其中m或n可以是1。
This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane.
本文件提供了在将保护交换机协调委托给数据平面的网络中，用于实现MPLS-TP数据路径SMP的任何机制的要求。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Although this document is not a protocol specification, the use of this language clarifies the instructions to protocol designers producing solutions that satisfy the requirements set out in this document.
尽管本文件不是协议规范，但本语言的使用澄清了协议设计师的指示，以生产满足本文件规定要求的解决方案。
The terminology used in this document is based on the terminology defined in the MPLS-TP Survivability Framework document [RFC6372], which in turn is based on [RFC4427].
本文件中使用的术语基于MPLS-TP生存能力框架文件[RFC6372]中定义的术语，而该文件又基于[RFC4427]。
This document uses the following acronyms:
本文件使用以下首字母缩略词：
LSP Label Switched Path SLA Service Level Agreement SMP Shared Mesh Protection SRLG Shared Risk Link Group
LSP标签交换路径SLA服务级别协议SMP共享网格保护SRLG共享风险链路组
This document defines the following term:
本文件定义了以下术语：
SMP Protection Group: the set of different protection paths that share a common segment.
SMP保护组：共享一个公共段的一组不同保护路径。
As described in [RFC6372], SMP supports the sharing of protection resources, while providing protection for multiple working paths that need not have common endpoints and do not share common points of failure. Note that some protection resources may be shared, while some others may not be. An example of data paths that employ SMP is shown in Figure 1. It shows two working paths -- <ABCDE> and <VWXYZ> -- that are protected employing 1:1 linear protection by protection paths <APQRE> and <VPQRZ>, respectively. The two protection paths that traverse segment <PQR> share the protection resources on this segment.
如[RFC6372]所述，SMP支持共享保护资源，同时为不需要具有公共端点且不共享公共故障点的多个工作路径提供保护。请注意，有些保护资源可能是共享的，而有些则可能不是。使用SMP的数据路径示例如图1所示。它显示了两条工作路径--<ABCDE>和<VWXYZ>，分别通过保护路径<APQRE>和<VPQRZ>采用1:1线性保护进行保护。穿过段<PQR>的两条保护路径共享该段上的保护资源。
A----B----C----D----E
\ /
\ /
\ /
P-----Q-----R
/ \
/ \
/ \
V----W----X----Y----Z
A----B----C----D----E
\ /
\ /
\ /
P-----Q-----R
/ \
/ \
/ \
V----W----X----Y----Z
Figure 1: Basic SMP Architecture
图1：基本SMP体系结构
[RFC6372], based upon the definitions in [RFC4427], differentiates between "protection" and "restoration", depending on the dynamism of the resource allocation. The same distinction is used in [RFC3945], [RFC4426], and [RFC4428].
[RFC6372]根据[RFC4427]中的定义，根据资源分配的动态性区分“保护”和“恢复”。[RFC3945]、[RFC4426]和[RFC4428]中使用了相同的区别。
This document also uses the same distinction between protection and restoration as the distinction stated in [RFC6372].
本文件还使用了与[RFC6372]中所述区别相同的保护和恢复区别。
[RFC5654] establishes that MPLS-TP SHOULD support shared protection (Requirement 68) and that MPLS-TP MUST support sharing of protection resources (Requirement 69). This document presents the network objectives and a framework for applying SMP within an MPLS network, without the use of control-plane protocols. Although there are existing control-plane solutions for SMP within MPLS, a data-plane solution is required for networks that do not employ a full control-plane operation for some reason (e.g., service provider preferences or limitations) or require service restoration faster than is achievable with control-plane mechanisms.
[RFC5654]确定MPLS-TP应支持共享保护（要求68），并且MPLS-TP必须支持共享保护资源（要求69）。本文档介绍了在MPLS网络中应用SMP的网络目标和框架，无需使用控制平面协议。尽管MPLS中存在用于SMP的现有控制平面解决方案，但对于出于某种原因（例如，服务提供商偏好或限制）未采用完全控制平面操作或需要比控制平面机制更快的服务恢复的网络，需要数据平面解决方案。
The network objectives will also address possible additional restrictions on the behavior of SMP in networks that delegate protection switching for resiliency to the data plane. Definitions of logic and specific protocol messaging are out of scope for this document.
网络目标还将解决SMP在网络中行为的可能附加限制，这些网络将保护切换的弹性委托给数据平面。逻辑和特定协议消息的定义超出了本文档的范围。
While some of the restrictions presented by this document originate from the properties of transport networks, nothing prevents the information presented here from being applied to MPLS networks outside the scope of the Transport Profile of MPLS.
虽然本文档提出的一些限制源于传输网络的特性，但没有任何东西阻止此处提供的信息应用于MPLS传输配置文件范围之外的MPLS网络。
Figure 1 shows a very basic configuration of working and protection paths that may employ SMP. We may consider a slightly more complex configuration, such as the one in Figure 2 in order to illustrate characteristics of a mesh network that implements SMP.
图1显示了可能采用SMP的工作和保护路径的基本配置。我们可以考虑一个稍微复杂的配置，例如图2中的一个，以便说明实现SMP的Mesh网络的特性。
A----B----C----D----E---N
\ / / \
\ M ---/-- \
\ / \ \
P-----Q-----R-----S----T
/| \ \ \ \
/ F---G---H J--K---L \
/ \
V------W-------X-------Y-------Z
A----B----C----D----E---N
\ / / \
\ M ---/-- \
\ / \ \
P-----Q-----R-----S----T
/| \ \ \ \
/ F---G---H J--K---L \
/ \
V------W-------X-------Y-------Z
Figure 2: Example of a Larger SMP Architecture
图2：更大的SMP体系结构示例
Consider the network presented in Figure 2. There are five working paths:
考虑图2中所示的网络。有五种工作路径：
- <ABCDE>
- <ABCDE>
- <MDEN>
- <MDEN>
- <FGH>
- <FGH>
- <JKL>
- <JKL>
- <VWXYZ>
- <VWXYZ>
Each of these has a corresponding protection path:
其中每个都有相应的保护路径：
- <APQRE> (p1)
- <APQRE>（p1）
- <MSTN> (p2)
- <MSTN>（p2）
- <FPQH> (p3)
- <FPQH>（第3页）
- <JRSL> (p4)
- <JRSL>（第4页）
- <VPQRSTZ> (p5)
- <VPQRSTZ>（第5页）
The following segments are shared by two or more of the protection
paths -- <PQ> is shared by p1, p3, and p5; <QR> is shared by p1 and
p5; <RS> is shared by p4 and p5; and <ST> is shared by p2 and p5. In
Figure 2, we have the following SMP Protection Groups -- {p1, p3, p5}
for <PQ>, {p1, p5} for <QR>, {p4, p5} for <RS>, and {p2, p5}
for <ST>.
The following segments are shared by two or more of the protection
paths -- <PQ> is shared by p1, p3, and p5; <QR> is shared by p1 and
p5; <RS> is shared by p4 and p5; and <ST> is shared by p2 and p5. In
Figure 2, we have the following SMP Protection Groups -- {p1, p3, p5}
for <PQ>, {p1, p5} for <QR>, {p4, p5} for <RS>, and {p2, p5}
for <ST>.
We assume that the available protection resources for these shared segments are not sufficient to support the complete traffic capacity of the respective working paths that may use the protection paths. We can further observe that with a method of coordinating sharing and preemption, there are no co-routing constraints on shared components at the segment level.
我们假设这些共享段的可用保护资源不足以支持可能使用保护路径的各个工作路径的完整通信容量。我们可以进一步观察到，通过协调共享和抢占的方法，在段级共享组件上不存在共路由约束。
The use of preemption in the network is typically a business or policy decision such that when protection resources are contested, priority can be applied to determine which parties utilize the protection resources.
在网络中使用抢占权通常是一种业务或策略决策，因此当保护资源受到质疑时，可以应用优先级来确定哪些方使用保护资源。
As opposed to the case of simple linear protection, where the relationship between the working and protection paths is defined and the resources for the protection path are fully dedicated, the protection path in the case of SMP consists of segments that are used for the protection of the related working path and also segments that are shared with other protection paths such that typically the protection resources are oversubscribed to support working paths that do not share common points of failure. What is required is a preemption mechanism to implement business priority when multiple failure scenarios occur. As such, the protection resources may be allocated but would not be utilized until requested and resolved in relation to other members of the SMP Protection Group as part of a protection switchover.
与简单线性保护的情况相反，简单线性保护定义了工作路径和保护路径之间的关系，并且保护路径的资源完全专用，在SMP的情况下，保护路径包括用于保护相关工作路径的段，以及与其他保护路径共享的段，从而通常过度订阅保护资源以支持不共享公共故障点的工作路径。当出现多个故障场景时，需要一种抢占机制来实现业务优先级。因此，保护资源可以被分配，但在作为保护切换的一部分被请求并解决与SMP保护组的其他成员相关的问题之前，不会被使用。
[RFC6372] defines two types of preemption that can be considered for how the resources of SMP Protection Groups are shared: "soft preemption", where traffic of lower-priority paths is degraded; and "hard preemption", where traffic of lower-priority paths is completely blocked. The traffic of lower-priority paths in this document can be viewed as the extra traffic being preempted, as described in [RFC6372]. "Hard preemption" requires the programming of selectors at the ingress of each shared segment to specify the priorities of backup paths, so that traffic of lower-priority paths can be preempted. When any protection mechanism where the protection endpoint may have a choice of protection paths (e.g., m:n or m:1) is deployed, the shared segment selectors require coordination with the protection endpoints as well.
[RFC6372]定义了两种类型的抢占，可以考虑如何共享SMP保护组的资源：“软抢占”，其中较低优先级路径的流量会降级；以及“硬抢占”，即低优先级路径的流量被完全阻塞。如[RFC6372]所述，本文档中较低优先级路径的流量可视为被抢占的额外流量。“硬抢占”要求在每个共享段的入口对选择器进行编程，以指定备份路径的优先级，从而可以抢占低优先级路径的通信量。当部署了保护端点可以选择保护路径（例如m:n或m:1）的任何保护机制时，共享段选择器也需要与保护端点协调。
Typical deployment of services that use SMP requires various network planning activities. These include the following:
使用SMP的服务的典型部署需要各种网络规划活动。这些措施包括：
o Determining the number of working and protection paths required to achieve resiliency targets for the service.
o 确定实现服务弹性目标所需的工作和保护路径的数量。
o Reviewing network topology to determine which working or protection paths are required to be disjoint from each other, and excluding specified resources such as links, nodes, or shared risk link groups (SRLGs).
o 查看网络拓扑以确定哪些工作或保护路径需要彼此分离，并排除指定的资源，如链路、节点或共享风险链路组（SRLGs）。
o Determining the size (bandwidth) of the shared resource.
o 确定共享资源的大小（带宽）。
When a protection switch is triggered, the SMP network performs two operations -- switching data traffic over to a protection path and coordinating the utilization of the associated shared resources. Both operations should occur at the same time, or as close together as possible, to provide fast protection. The resource utilization coordination is dependent upon their availability at each of the shared segments.
当触发保护交换机时，SMP网络执行两个操作——将数据流量切换到保护路径和协调相关共享资源的利用。两种操作应同时进行，或尽可能靠近，以提供快速保护。资源利用协调取决于每个共享段的可用性。
When the reserved resources of the shared segments are utilized by a particular protection path, there may not be sufficient resources available for an additional protection path. This then implies that if another working path of the SMP domain triggers a protection switch, the resource utilization coordination may fail. The different working paths in the SMP network are involved in the resource utilization coordination, which is a part of a whole SMP protection switching coordination.
当共享段的保留资源被特定保护路径利用时，可能没有足够的资源可用于附加保护路径。这意味着，如果SMP域的另一个工作路径触发保护交换机，则资源利用协调可能会失败。SMP网络中的不同工作路径参与资源利用协调，这是整个SMP保护切换协调的一部分。
As stated in both [RFC6372] and [RFC4428], full control of SMP, including both configuration and the coordination of the protection switching, is potentially very complex. Therefore, it is suggested that this be carried out under the control of a dynamic control plane based on Generalized MPLS (GMPLS) [RFC3945]. Implementations for SMP with GMPLS exist, and the general principles of its operation are well known, if not fully documented.
如[RFC6372]和[RFC4428]中所述，SMP的完全控制，包括保护切换的配置和协调，可能非常复杂。因此，建议在基于广义MPLS（GMPLS）[RFC3945]的动态控制平面的控制下执行此操作。存在使用GMPLS的SMP实现，其操作的一般原则是众所周知的，如果没有完整的文档记录的话。
However, there are operators, in particular in the transport sector, that do not operate their MPLS-TP networks under the control of a control plane or for other reasons have delegated executive action for resilience to the data plane, and require the ability to utilize
然而，有些运营商，特别是运输部门的运营商，不在控制平面的控制下运营其MPLS-TP网络，或出于其他原因，已授权执行行动以恢复数据平面，并要求能够利用
SMP protection. For such networks, it is imperative that it be possible to perform all required coordination of selectors and endpoints for SMP via data-plane operations.
SMP保护。对于此类网络，必须能够通过数据平面操作执行SMP选择器和端点的所有必要协调。
SMP is based on pre-configuration of the working paths and the corresponding protection paths. This configuration may be based on either a control protocol or static configuration by the management system. However, even when the configuration is performed by a control protocol, e.g., GMPLS, the control protocol SHALL NOT be used as the primary mechanism for detecting or reporting network failures, or for initiating or coordinating protection switchover. That is, it SHALL NOT be used as the primary resilience mechanism.
SMP基于工作路径和相应保护路径的预配置。该配置可基于控制协议或管理系统的静态配置。然而，即使通过控制协议（如GMPLS）执行配置，控制协议也不得用作检测或报告网络故障或启动或协调保护切换的主要机制。也就是说，它不应被用作主要的恢复机制。
The protection relationship between the working and protection paths SHOULD be configured, and the shared segments of the protection path MUST be identified prior to use of the protection paths. Relative priority for working paths to be used to resolve contention for protection path usage by multiple working paths MAY also be specified ahead of time.
应配置工作路径和保护路径之间的保护关系，并且必须在使用保护路径之前识别保护路径的共享段。还可以提前指定用于解决多个工作路径使用保护路径的争用的工作路径的相对优先级。
When a protection switch is triggered by any fault condition or operator command, the SMP network MUST perform two operations -- switch data traffic over to a protection path, and coordinate the utilization of the associated shared resources. To provide fast protection, both operations MUST occur at the same time or as close to the same time as possible.
当任何故障条件或操作员命令触发保护交换机时，SMP网络必须执行两项操作——将数据流量切换到保护路径，并协调相关共享资源的利用。为了提供快速保护，两种操作必须同时进行或尽可能接近同时进行。
In the case of multiple working paths failing, the shared resource utilization coordination SHALL be between the different working paths in the SMP network.
如果多条工作路径出现故障，共享资源利用协调应在SMP网络中的不同工作路径之间进行。
In a hard-preemption scenario, when an endpoint identifies a protection switching trigger and has more than one potential action (e.g., m:1 protection), it MUST verify that the necessary protection resources are available on the selected protection path. The resources may not be available because they have already been utilized for the protection of, for example, one or more higher-priority working paths.
在硬抢占场景中，当端点识别保护切换触发器并具有多个潜在动作（例如，m:1保护）时，它必须验证所选保护路径上是否有必要的保护资源可用。资源可能不可用，因为它们已经被用于保护例如一个或多个更高优先级的工作路径。
If more than one working path is triggering a protection switch such that a protection segment is oversubscribed, there are two different actions that the SMP network can choose -- soft preemption and hard preemption [RFC6372].
如果有多条工作路径触发保护交换机，从而导致保护段被超额订阅，SMP网络可以选择两种不同的操作——软抢占和硬抢占[RFC6372]。
For networks that support multiplexing packets over the shared segments, the requirement is as follows:
对于支持在共享段上复用数据包的网络，要求如下：
o All of the protection paths MAY be allowed to share the resources of the shared segments.
o 可以允许所有保护路径共享共享段的资源。
There are networks that require the exclusive use of the protection resources when a protection segment is oversubscribed. Traffic of lower-priority paths is completely blocked. These include networks that support the requirements in [RFC5654], and in particular support Requirement 58. For such networks, the following requirements apply:
有些网络在保护段被超额订阅时需要独占使用保护资源。较低优先级路径的通信量被完全阻塞。这些包括支持[RFC5654]中要求的网络，特别是支持要求58。对于此类网络，以下要求适用：
1. Relative priority MAY be assigned to each of the working paths of an SMP domain. If the priority is not assigned, the working paths are assumed to have equal priority.
1. 可以将相对优先级分配给SMP域的每个工作路径。如果未分配优先级，则假定工作路径具有相同的优先级。
2. Resources of the shared segments SHALL be utilized by the protection path according to the highest priority amongst those requesting use of the resources.
2. 共享段的资源应由保护路径根据请求使用资源者中的最高优先级来使用。
3. If multiple protection paths of equal priority are requesting the shared resources, the resources SHALL be utilized on a first come first served basis. Traffic of the protection paths that request the shared resources late SHALL be preempted. In order to cover the situation where the first come first served principle cannot resolve the contention among multiple equal-priority requests, i.e., when the requests occur simultaneously, tie-breaking rules SHALL be defined in the scope of an SMP domain.
3. 如果多个具有同等优先级的保护路径请求共享资源，则应按照先到先得的原则使用这些资源。延迟请求共享资源的保护路径的流量应被抢占。为了涵盖先到先得原则无法解决多个同等优先级请求之间的争用的情况，即当请求同时发生时，应在SMP域的范围内定义中断规则。
4. If a higher-priority path requires the protection resources that are being utilized by a lower-priority path, the resources SHALL be utilized by the higher-priority path. Traffic with the lower priority SHALL be preempted.
4. 如果高优先级路径需要由低优先级路径使用的保护资源，则该资源应由高优先级路径使用。优先级较低的流量应优先。
5. Once resources of shared segments have been successfully utilized by a protection path, the traffic on that protection path SHALL NOT be interrupted by any protection traffic whose priority is equal to or lower than the protecting path currently in use.
5. 一旦共享段的资源被保护路径成功利用，该保护路径上的流量不得被优先级等于或低于当前使用的保护路径的任何保护流量中断。
6. During preemption, shared segment resources MAY be used by both existing traffic (that is being preempted) and higher-priority traffic.
6. 在抢占期间，共享段资源可由现有流量（即被抢占的流量）和更高优先级的流量使用。
When a working path endpoint has a protection switch triggered, it SHOULD attempt to switch the traffic to the protection path and request the coordination of the shared resource utilization. If the necessary shared resources are unavailable, the endpoints of the requesting working path SHALL be notified of protection switchover failure, and switchover will not be completed.
当工作路径终结点触发了保护切换时，它应该尝试将流量切换到保护路径，并请求协调共享资源的利用。如果必要的共享资源不可用，则应通知请求工作路径的端点保护切换失败，并且切换将不会完成。
Similarly, if preemption is supported and the resources currently utilized by a particular working path are being preempted, then the endpoints of the affected working path whose traffic is being preempted SHALL be notified that the resources are being preempted. As described in [RFC6372], the event of preemption may be detected by Operations, Administration, and Maintenance (OAM) and reported as a fault or a degradation of traffic delivery.
类似地，如果支持抢占且特定工作路径当前使用的资源被抢占，则应通知其流量被抢占的受影响工作路径的端点资源被抢占。如[RFC6372]所述，抢占事件可由操作、管理和维护（OAM）检测到，并报告为故障或流量传输降级。
When the condition that triggered the protection switch is cleared, it is possible to either revert to using the working path resources or continue to utilize the protection resources. Continuing the use of protection resources allows the operator to delay the disruption of service caused by the switchover until periods of lighter traffic. The switchover would need to be performed via an explicit operator command, unless the protection resources are preempted by a higher-priority fault. Hence, both automatic and manual revertive behaviors MUST be supported for hard preemption in an SMP domain. Normally, the network should revert to use of the working path resources in order to clear the protection resources for protection of other path triggers. However, the protocol MUST support non-revertive configurations.
当触发保护开关的条件被清除时，可以恢复使用工作路径资源或继续使用保护资源。继续使用保护资源可使运营商将切换造成的服务中断延迟至交通量较轻的时段。除非保护资源被更高优先级的故障抢占，否则需要通过显式操作员命令执行切换。因此，SMP域中的硬抢占必须支持自动和手动恢复行为。通常，网络应恢复使用工作路径资源，以便清除保护资源以保护其他路径触发器。但是，协议必须支持非还原配置。
Protection switching time refers to the transfer time (Tt) defined in [G.808.1] and recovery switching time defined in [RFC4427], and is defined as the interval after a switching trigger is identified until the traffic begins to be transmitted on the protection path. This
保护切换时间是指[G.808.1]中定义的传输时间（Tt）和[RFC4427]中定义的恢复切换时间，并定义为识别切换触发器后直到流量开始在保护路径上传输的间隔。这
time does not include the time needed to initiate the protection switching process after a failure occurred, and the time needed to complete preemption of existing traffic on the shared segments as described in Section 4.2. The time needed to initiate the protection switching process, which is known as detection time or correlation time in [RFC4427], is related to the OAM or management process, but the time needed to complete preemption is related to the actions within an SMP domain. Support for a protection switching time of 50 ms is dependent upon the initial switchover to the protection path, but the preemption time SHOULD also be taken into account to minimize total service interruption time.
时间不包括发生故障后启动保护切换过程所需的时间，以及第4.2节所述的共享段上现有通信量的抢占完成所需的时间。启动保护切换过程所需的时间（在[RFC4427]中称为检测时间或相关时间）与OAM或管理过程有关，但完成抢占所需的时间与SMP域内的操作有关。对50 ms保护切换时间的支持取决于初始切换到保护路径，但也应考虑抢占时间，以最小化总服务中断时间。
When triggered, protection switching action SHOULD be initiated immediately to minimize service interruption time.
触发时，应立即启动保护切换动作，以尽量减少服务中断时间。
In order to prevent multiple switching actions for a single switching trigger, when there are multiple layers of networks, SMP SHOULD be controlled by a hold-off timer that would allow lower-layer mechanisms to complete their switching actions before invoking SMP protection actions as described in [RFC6372].
为了防止单个切换触发器的多个切换动作，当存在多层网络时，SMP应由延迟计时器控制，该计时器允许较低层机制在调用[RFC6372]中所述的SMP保护动作之前完成其切换动作。
In order to prevent an unstable recovering working path from invoking intermittent switching operations, SMP SHOULD employ a Wait-To-Restore timer during any reversion switching, as described in [RFC6372].
为了防止不稳定的恢复工作路径调用间歇切换操作，SMP应在任何恢复切换期间使用等待恢复计时器，如[RFC6372]中所述。
SMP SHOULD provide a communication channel, along the protection path, between the endpoints of the protection path, to support fast protection switching.
SMP应沿保护路径在保护路径端点之间提供通信信道，以支持快速保护切换。
SMP in hard-preemption mode SHOULD include support for communicating information to coordinate the use of the shared protection resources among multiple working paths. The message encoding and communication channel between the nodes of the shared protection resource and the endpoints of the protection path are out of the scope of this document.
硬抢占模式下的SMP应包括对通信信息的支持，以协调多个工作路径之间共享保护资源的使用。共享保护资源的节点与保护路径的端点之间的消息编码和通信通道不在本文档的范围内。
Bidirectional protection switching SHOULD be supported in SMP.
SMP中应支持双向保护切换。
The network management architecture and requirements for MPLS-TP are specified in [RFC5951]. They derive from the generic specifications described in ITU-T G.7710/Y.1701 [G.7710] for transport technologies. This document does not introduce any new manageability requirements beyond those covered in those documents.
[RFC5951]中规定了MPLS-TP的网络管理架构和要求。它们源自ITU-T G.7710/Y.1701[G.7710]中描述的传输技术通用规范。本文件不引入任何超出这些文件所涵盖范围的新的可管理性要求。
General security considerations for MPLS-TP are covered in [RFC5921]. The security considerations for the generic associated control channel are described in [RFC5586].
[RFC5921]中介绍了MPLS-TP的一般安全注意事项。[RFC5586]中描述了通用相关控制通道的安全注意事项。
Security considerations for any proposed solution should consider exhaustion of resources related to preemption, especially by a malicious actor as a threat vector against which the resources should be protected. Protections should also be considered to prevent a malicious actor from attempting to create an alternate path on which to force traffic from a sensor/device, thereby enabling pervasive monitoring [RFC7258].
任何建议的解决方案的安全考虑应考虑与抢占有关的资源的耗尽，尤其是由恶意参与者作为威胁向量，资源应该被保护。还应考虑采取保护措施，以防止恶意参与者试图创建另一条路径，在该路径上强制来自传感器/设备的流量，从而实现普遍监控[RFC7258]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004, <http://www.rfc-editor.org/info/rfc3945>.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月<http://www.rfc-editor.org/info/rfc3945>.
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, March 2006, <http://www.rfc-editor.org/info/rfc4426>.
[RFC4426]Lang，J.，Ed.，Rajagopalan，B.，Ed.，和D.Papadimitriou，Ed.，“通用多协议标签交换（GMPLS）恢复功能规范”，RFC 4426，2006年3月<http://www.rfc-editor.org/info/rfc4426>.
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006, <http://www.rfc-editor.org/info/rfc4427>.
[RFC4427]Mannie，E.，Ed.和D.Papadimitriou，Ed.“通用多协议标签交换（GMPLS）的恢复（保护和恢复）术语”，RFC 4427，2006年3月<http://www.rfc-editor.org/info/rfc4427>.
[RFC4428] Papadimitriou, D., Ed., and E. Mannie, Ed., "Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)", RFC 4428, March 2006, <http://www.rfc-editor.org/info/rfc4428>.
[RFC4428]Papadimitriou，D.，Ed.，和E.Mannie，Ed.“基于通用多协议标签交换（GMPLS）的恢复机制分析（包括保护和恢复）”，RFC 4428，2006年3月<http://www.rfc-editor.org/info/rfc4428>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009, <http://www.rfc-editor.org/info/rfc5586>.
[RFC5586]Bocci，M.，Ed.，Vigoureux，M.，Ed.，和S.Bryant，Ed.，“MPLS通用关联信道”，RFC 55862009年6月<http://www.rfc-editor.org/info/rfc5586>.
[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, <http://www.rfc-editor.org/info/rfc5654>.
[RFC5654]Niven Jenkins，B.，Ed.，Brungard，D.，Ed.，Betts，M.，Ed.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月<http://www.rfc-editor.org/info/rfc5654>.
[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, <http://www.rfc-editor.org/info/rfc5921>.
[RFC5921]Bocci，M.，Ed.，Bryant，S.，Ed.，Frost，D.，Ed.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，RFC 59212010年7月<http://www.rfc-editor.org/info/rfc5921>.
[RFC5951] Lam, K., Mansfield, S., and E. Gray, "Network Management Requirements for MPLS-based Transport Networks", RFC 5951, September 2010, <http://www.rfc-editor.org/info/rfc5951>.
[RFC5951]Lam，K.，Mansfield，S.，和E.Gray，“基于MPLS的传输网络的网络管理要求”，RFC 59512010年9月<http://www.rfc-editor.org/info/rfc5951>.
[RFC6372] Sprecher, N., Ed., and A. Farrel, Ed., "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, September 2011, <http://www.rfc-editor.org/info/rfc6372>.
[RFC6372]Sprecher，N.，Ed.，和A.Farrel，Ed.，“MPLS传输配置文件（MPLS-TP）生存能力框架”，RFC 6372，2011年9月<http://www.rfc-editor.org/info/rfc6372>.
[RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, October 2011, <http://www.rfc-editor.org/info/rfc6378>.
[RFC6378]Y.Weingarten，Ed.，Bryant，S.，Osborne，E.，Sprecher，N.，和A.Fulignoli，Ed.，“MPLS传输配置文件（MPLS-TP）线性保护”，RFC 6378，2011年10月<http://www.rfc-editor.org/info/rfc6378>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，2014年5月<http://www.rfc-editor.org/info/rfc7258>.
[RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators", RFC 7271, June 2014, <http://www.rfc-editor.org/info/rfc7271>.
[RFC7271]Ryoo，J.，Ed.，Gray，E.，Ed.，van Helvoort，H.，D'Alessandro，A.，Cheung，T.，和E.Osborne，“MPLS传输配置文件（MPLS-TP）线性保护，以满足同步数字体系、光传输网络和以太网传输网络运营商的运营期望”，RFC 72712014年6月， <http://www.rfc-editor.org/info/rfc7271>.
[G.7710] International Telecommunication Union, "Common equipment management function requirements", ITU-T Recommendation G.7710/Y.1701, February 2012.
[G.7710]国际电信联盟，“通用设备管理功能要求”，ITU-T建议G.7710/Y.17012012年2月。
[G.808.1] International Telecommunication Union, "Generic Protection Switching - Linear trail and subnetwork protection", ITU-T Recommendation G.808.1, May 2014.
[G.808.1]国际电信联盟，“通用保护交换——线性线路和子网保护”，ITU-T建议G.808.1，2014年5月。
Acknowledgements
致谢
This document is the outcome of discussions on Shared Mesh Protection for MPLS-TP. The authors would like to thank all contributors to these discussions, and especially Eric Osborne for facilitating them.
本文档是关于MPLS-TP共享网格保护讨论的结果。作者要感谢所有参与这些讨论的人，特别是埃里克·奥斯本为他们提供了便利。
We would also like to thank Matt Hartley for working on the English review and Lou Berger for his valuable comments and suggestions on this document.
我们还要感谢Matt Hartley为《英语评论》工作，以及Lou Berger对本文件提出的宝贵意见和建议。
Contributors
贡献者
David Allan Ericsson EMail: david.i.allan@ericsson.com
David Allan Ericsson电子邮件：David.i。allan@ericsson.com
Daniel King Old Dog Consulting EMail: daniel@olddog.co.uk
Daniel King老狗咨询电子邮件：daniel@olddog.co.uk
Taesik Cheung ETRI EMail: cts@etri.re.kr
张泰锡ETRI电子邮件：cts@etri.re.kr
Authors' Addresses
作者地址
Yaacov Weingarten 34 Hagefen St. Karnei Shomron, 4485500 Israel
Yaacov Weingarten 34 Hagefen St.Karnei Shomron，以色列4485500
EMail: wyaacov@gmail.com
EMail: wyaacov@gmail.com
Sam Aldrin Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 United States
美国加利福尼亚州圣克拉拉中央高速公路2330号Sam Aldrin华为技术公司，邮编95050
EMail: aldrin.ietf@gmail.com
EMail: aldrin.ietf@gmail.com
Ping Pan Infinera
平盘酒店
EMail: ppan@infinera.com
EMail: ppan@infinera.com
Jeong-dong Ryoo ETRI 218 Gajeongno Yuseong, Daejeon 305-700 South Korea
韩国大田广野裕盛区郑东良ETRI 218 305-700
EMail: ryoo@etri.re.kr
EMail: ryoo@etri.re.kr
Greg Mirsky Ericsson
格雷格·米尔斯基·爱立信
EMail: gregory.mirsky@ericsson.com
EMail: gregory.mirsky@ericsson.com