Internet Engineering Task Force (IETF) Y. Weingarten
Request for Comments: 6974
Category: Informational S. Bryant
ISSN: 2070-1721 Cisco Systems
D. Ceccarelli
D. Caviglia
F. Fondelli
Ericsson
M. Corsi
Altran
B. Wu
ZTE Corporation
X. Dai
July 2013
Internet Engineering Task Force (IETF) Y. Weingarten
Request for Comments: 6974
Category: Informational S. Bryant
ISSN: 2070-1721 Cisco Systems
D. Ceccarelli
D. Caviglia
F. Fondelli
Ericsson
M. Corsi
Altran
B. Wu
ZTE Corporation
X. Dai
July 2013
Applicability of MPLS Transport Profile for Ring Topologies
MPLS传输配置文件对环形拓扑的适用性
Abstract
摘要
This document presents an applicability of existing MPLS protection mechanisms, both local and end-to-end, to the MPLS Transport Profile (MPLS-TP) in ring topologies. This document does not propose any new mechanisms or protocols. Requirements for MPLS-TP protection especially for protection in ring topologies are discussed in "Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP) Survivability Framework" (RFC 6372). This document discusses how most of the requirements are met by applying linear protection as defined in RFC 6378 in a ring topology.
本文档介绍了现有MPLS保护机制（本地和端到端）对环形拓扑中MPLS传输配置文件（MPLS-TP）的适用性。本文件未提出任何新的机制或协议。“MPLS传输配置文件的要求”（RFC 5654）和“MPLS传输配置文件（MPLS-TP）生存性框架”（RFC 6372）中讨论了MPLS-TP保护的要求，尤其是环形拓扑中的保护要求。本文件讨论了如何通过在环形拓扑中应用RFC 6378中定义的线性保护来满足大多数要求。
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/rfc6974.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6974.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope of the Document . . . . . . . . . . . . . . . . . . 4
1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 5
2. Point-to-Point (P2P) Ring Protection . . . . . . . . . . . . . 6
2.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. SPME for P2P Protection of a Ring Topology . . . . . . . . 10
2.3.1. Path SPME for Steering . . . . . . . . . . . . . . . . 11
2.3.2. Wrapping Link Protection with Segment-Based SPME . . . 12
2.3.3. Wrapping Node Protection . . . . . . . . . . . . . . . 13
2.3.4. Wrapping for Link and Node Protection . . . . . . . . 14
2.4. Analysis of P2P Protection . . . . . . . . . . . . . . . . 15
2.4.1. Recommendations for Protection of P2P Paths
Traversing a Ring . . . . . . . . . . . . . . . . . . 16
3. Point-to-Multipoint Protection . . . . . . . . . . . . . . . . 17
3.1. Wrapping for P2MP LSPs . . . . . . . . . . . . . . . . . . 17
3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 19
3.1.2. Multiple Failures Comparison . . . . . . . . . . . . . 20
3.2. Steering for P2MP Paths . . . . . . . . . . . . . . . . . 21
3.2.1. Context Labels . . . . . . . . . . . . . . . . . . . . 21
3.2.2. Walk-Through Using Context Labels . . . . . . . . . . 23
4. Coordination Protocol . . . . . . . . . . . . . . . . . . . . 26
5. Conclusions and Recommendations . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. Normative References . . . . . . . . . . . . . . . . . . . 27
7.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 29
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope of the Document . . . . . . . . . . . . . . . . . . 4
1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 5
2. Point-to-Point (P2P) Ring Protection . . . . . . . . . . . . . 6
2.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. SPME for P2P Protection of a Ring Topology . . . . . . . . 10
2.3.1. Path SPME for Steering . . . . . . . . . . . . . . . . 11
2.3.2. Wrapping Link Protection with Segment-Based SPME . . . 12
2.3.3. Wrapping Node Protection . . . . . . . . . . . . . . . 13
2.3.4. Wrapping for Link and Node Protection . . . . . . . . 14
2.4. Analysis of P2P Protection . . . . . . . . . . . . . . . . 15
2.4.1. Recommendations for Protection of P2P Paths
Traversing a Ring . . . . . . . . . . . . . . . . . . 16
3. Point-to-Multipoint Protection . . . . . . . . . . . . . . . . 17
3.1. Wrapping for P2MP LSPs . . . . . . . . . . . . . . . . . . 17
3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 19
3.1.2. Multiple Failures Comparison . . . . . . . . . . . . . 20
3.2. Steering for P2MP Paths . . . . . . . . . . . . . . . . . 21
3.2.1. Context Labels . . . . . . . . . . . . . . . . . . . . 21
3.2.2. Walk-Through Using Context Labels . . . . . . . . . . 23
4. Coordination Protocol . . . . . . . . . . . . . . . . . . . . 26
5. Conclusions and Recommendations . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. Normative References . . . . . . . . . . . . . . . . . . . 27
7.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 29
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 29
The MPLS Transport Profile (MPLS-TP) has been standardized as part of a joint effort between the Internet Engineering Task Force (IETF) and the International Telecommunications Union Telecommunications Standardization Sector (ITU-T). These specifications are based on the requirements that were generated from this joint effort.
作为互联网工程任务组（IETF）和国际电信联盟电信标准化部门（ITU-T）共同努力的一部分，MPLS传输配置文件（MPLS-TP）已经标准化。这些规范基于此联合工作产生的需求。
The MPLS-TP requirement document [RFC5654] includes a requirement to support a network that may include subnetworks that constitute an MPLS-TP ring as defined in the document. However, the document does not identify any protection requirements specific to a ring topology. The requirements state that specific protection mechanisms applying to ring topologies may be developed if these allow the network to minimize:
MPLS-TP需求文件[RFC5654]包括支持网络的需求，该网络可能包括构成文件中定义的MPLS-TP环的子网。但是，本文件并未确定特定于环形拓扑的任何保护要求。要求指出，如果允许网络最小化以下情况，则可以开发适用于环形拓扑的特定保护机制：
o the number of OAM entities needed to trigger the protection
o 触发保护所需的OAM实体数
o the number of elements of recovery needed
o 所需恢复要素的数量
o the number of labels required
o 所需标签的数量
o the number of control- and management-plane transactions during a maintenance operation
o 维护操作期间控制和管理平面事务的数量
o the impact of signaling and routing information exchanged during protection, in the presence of a control plane
o 在控制平面存在的情况下，保护期间交换的信令和路由信息的影响
This document describes how applying a set of basic MPLS-TP linear protection mechanisms defined in [RFC6378] can be used to provide protection of the data flows that traverse an MPLS-TP ring. These mechanisms provide data flow protection due to any switching trigger within a reasonable time frame and optimize the criteria set out in [RFC5654], as summarized above. This document does not define any new protocol mechanisms or procedures.
本文档描述了如何使用[RFC6378]中定义的一组基本MPLS-TP线性保护机制来保护穿过MPLS-TP环的数据流。如上所述，这些机制在合理的时间范围内提供任何切换触发的数据流保护，并优化[RFC5654]中规定的标准。本文件未定义任何新的协议机制或程序。
A related topic in [RFC5654] addresses the required support for interconnected rings. This topic involves various scenarios that require further study and will be addressed in a separate document, based on the principles outlined in this document.
[RFC5654]中的一个相关主题介绍了互连环所需的支持。本主题涉及需要进一步研究的各种场景，并将根据本文件中概述的原则在单独的文件中予以说明。
Ring topologies, as defined in [RFC5654], are used in transport networks. When designing a protection mechanism for a single ring topology, there is a need to address both of the following cases.
[RFC5654]中定义的环形拓扑用于传输网络。在为单环拓扑设计保护机制时，需要解决以下两种情况。
1. A point-to-point transport path that originates at a ring node or enters an MPLS-TP-capable ring at a single ingress node, and exits the ring at a single egress node, and possibly continues beyond the ring.
1. 一种点对点传输路径，其起源于环节点，或在单个入口节点处进入支持MPLS-TP的环，并在单个出口节点处退出环，并且可能在环之外继续。
2. Where the ring is being used as a branching point for a point-to-multipoint transport path, i.e., the transport path originates at or enters the MPLS-TP-capable ring at the ingress node and exits through a number of egress nodes, possibly continuing beyond the ring.
2. 其中，环被用作点到多点传输路径的分支点，即，传输路径在入口节点处发起或进入支持MPLS-TP的环，并通过多个出口节点退出，可能在环之外继续。
In either of these two situations, there is a need to address the following different cases.
在这两种情况中的任何一种情况下，都需要解决以下不同情况。
1. One of the ring links causes a fault condition. This could be either a unidirectional or bidirectional fault, and it should be detected by the neighboring nodes.
1. 其中一个环形链路导致故障状况。这可能是单向或双向故障，应由相邻节点检测。
2. One of the ring nodes causes a fault condition. This condition is invariably a bidirectional fault (although in rare cases of misconfiguration, this could be detected as a unidirectional fault), and it should be detected by the two neighboring ring nodes.
2. 其中一个环节点导致出现故障。这种情况通常是双向故障（尽管在少数情况下配置错误，这可能被检测为单向故障），并且应该由两个相邻的环节点检测。
3. An operator command is issued to a specific ring node; it either changes the operational state of a node or a link or explicitly triggers a protection action. An operator command changes the operational state of a node or a link, or specifically triggers a protection action is issued to a specific ring node. A description of the different operator commands is found in Section 4.13 of [RFC4427]. Examples of these commands include Manual Switch, Forced Switch, and Clear operations.
3. 向特定环节点发出操作员命令；它可以更改节点或链接的操作状态，也可以显式触发保护操作。操作员命令可更改节点或链路的操作状态，或在向特定环节点发出保护动作时，专门触发保护动作。不同操作员命令的说明见[RFC4427]第4.13节。这些命令的示例包括手动开关、强制开关和清除操作。
The protection domain addressed in this document is limited to the traffic that traverses on the ring. Protection triggers on the transport path prior to the ingress node of the ring or beyond the egress nodes may be protected by some other mechanism.
本文档中所述的保护域仅限于环上的通信量。在环的入口节点之前或出口节点之外的传输路径上的保护触发器可以由某种其他机制保护。
This document addresses the requirements that appear in Section 2.5.6.1 of [RFC5654] on ring protection, based on the application of the linear protection as defined in [RFC6378]. Requirement R93 regarding the support of interconnected rings and protection of faults in the interconnection nodes and links is for further study.
本文件基于[RFC6378]中定义的线性保护的应用，阐述了[RFC5654]第2.5.6.1节中关于环形保护的要求。关于互连环支撑和互连节点和链路故障保护的要求R93有待进一步研究。
In addition, requirement R105 requiring the support of lockout of specific nodes or spans is only supported to the degree that it is supported by the linear protection mechanism.
此外，要求支持锁定特定节点或跨度的要求R105仅在线性保护机制支持的程度上得到支持。
The terminology used in this document is based on the terminology defined in the MPLS-TP framework documents:
本文件中使用的术语基于MPLS-TP框架文件中定义的术语：
o MPLS-TP framework [RFC5921]
o MPLS-TP框架[RFC5921]
o MPLS-TP OAM framework [RFC6371]
o MPLS-TP OAM框架[RFC6371]
o MPLS-TP survivability framework [RFC6372]
o MPLS-TP生存性框架[RFC6372]
The MPLS-TP framework document [RFC5921] defines a Sub-Path Maintenance Entity (SPME) construct that can be defined between any two Label Switching Routers (LSRs) of an MPLS-TP Label Switched Path (LSP). This SPME may be configured as a co-routed bidirectional path. The SPME is defined to allow management and monitoring of any segment of a transport path. This concept will be used extensively throughout the document to support protection of the traffic that traverses an MPLS-TP ring.
MPLS-TP框架文件[RFC5921]定义了一个子路径维护实体（SPME）结构，该结构可在MPLS-TP标签交换路径（LSP）的任意两个标签交换路由器（LSR）之间定义。此SPME可配置为共路由双向路径。SPME定义为允许管理和监控传输路径的任何段。此概念将在整个文档中广泛使用，以支持对穿过MPLS-TP环的流量的保护。
In addition, we describe the use of the label stack in connection with the redirecting of data packets by the protection mechanism. The following syntax will be used to describe the contents of the label stack:
此外，我们还描述了标签堆栈在通过保护机制重定向数据包时的使用。以下语法将用于描述标签堆栈的内容：
1. The label stack will be enclosed in square brackets ("[]").
1. 标签堆栈将用方括号（“[]”）括起来。
2. Each level in the stack will be separated by the '|' character. It should be noted that the label stack may contain additional levels; however, we only present the levels that are germane to the protection mechanism.
2. 堆栈中的每个级别将由“|”字符分隔。应注意的是，标签堆栈可能包含额外的级别；然而，我们只提供与保护机制密切相关的水平。
3. When applicable, the S bit (signifying that a given label is the bottom of the label stack) will be denoted by the string '+S' within the label. If a label is not shown with '+S' , that label may or may not be the bottom label in the stack. '+S' is only shown when it is important to illustrate that a given label is definitely the last one in the label stack.
3. 适用时，S位（表示给定标签是标签堆栈的底部）将由标签内的字符串“+S”表示。如果标签未显示“+S”，则该标签可能是也可能不是堆栈中的底部标签+仅当必须说明给定标签肯定是标签堆栈中的最后一个标签时，才会显示“S”。
4. The label of the LSP at the ingress node of the ring will be denoted by the string "LI", and the label of the LSP that is expected at the egress point from the ring will be denoted by the string "LE". "LSE" will denote the label expected at the exit LSR of a SPME (if it is different from the egress point from the ring, for example, as described in Section 2.3).
4. 环的入口节点处的LSP的标签将由字符串“LI”表示，而环的出口点处预期的LSP的标签将由字符串“LE”表示。“LSE”将表示SPME出口LSR处预期的标签（如果它与环的出口点不同，例如，如第2.3节所述）。
5. The label Pxi(y) in the stack denotes the label that LSR-x would use to transport the packet to LSR-y over the SPME whose index is i.
5. 堆栈中的标签Pxi（y）表示LSR-x将用于通过索引为i的SPME将数据包传输到LSR-y的标签。
For example:
例如：
o The label stack [LI] denotes the label stack received at the ingress node of the ring. There may be additional labels after LI, e.g., a PW label; however, this is irrelevant to the discussion of the protection scenario.
o 标签栈[LI]表示在环的入口节点处接收的标签栈。LI之后可能会有其他标签，例如PW标签；但是，这与保护场景的讨论无关。
o [PB1(G) | LE] denotes a stack whose top label is the SPME-1 label for LSR-B to transmit the data packet to LSR-G, and the second label is the label that would be used by the egress LSR to continue to transmit the packet on the original LSP.
o [PB1（G）| LE]表示其顶部标签是用于LSR-B将数据分组传输到LSR-G的SPME-1标签的堆栈，并且第二标签是将由出口LSR用于继续在原始LSP上传输分组的标签。
o If "LE" were the bottom label in the stack, then the label stack would be shown as [PB1(G) | LE+S].
o 如果“LE”是堆栈中的底部标签，则标签堆栈将显示为[PB1（G）| LE+S]。
There are two protection architecture mechanisms -- "Wrapping" and "Steering" -- that have historically been applied to ring topologies, based on Synchronous Digital Hierarchy (SDH) specifications [G.841], and have been proposed in various forums to perform recovery of a topological ring network. The following subsections examine these two mechanisms, as applied to an MPLS transport network.
基于同步数字体系（SDH）规范[G.841]，有两种保护体系结构机制——“包装”和“导向”——历史上一直应用于环形拓扑，并在各种论坛上提出用于执行拓扑环形网络的恢复。以下小节将研究应用于MPLS传输网络的这两种机制。
Wrapping is defined as a local protection architecture. This mechanism is local to the nodes that are neighbors to the detected fault. When a fault is detected (either a link or node failure), the neighboring node can identify that the fault would prevent forwarding of the data along the data path. Therefore, in order to continue to transmit the data along the path, there is a need to "wrap" all data traffic around the ring, on an alternate data path, until the arrives at the node that is on the opposite side of the fault. When this far-side node also detects that there is a fault condition on the working path, it can identify that the data traffic that is arriving on the alternate (protecting) data path is intended for the "broken"
包装被定义为本地保护体系结构。该机制是与检测到的故障相邻的节点的本地机制。当检测到故障（链路或节点故障）时，相邻节点可以识别该故障将阻止沿数据路径转发数据。因此，为了继续沿路径传输数据，需要在备用数据路径上“包装”环上的所有数据通信量，直到到达故障另一侧的节点。当该远端节点还检测到工作路径上存在故障时，它可以识别到达备用（保护）数据路径的数据通信量是针对“断开”的
data path. Therefore, again making a local decision, the far-side node can wrap the data back onto the normal working path until the egress from the ring segment.
数据路径。因此，再次做出局部决策，远端节点可以将数据包装回正常工作路径，直到从环段出口。
Wrapping behavior is similar to MPLS-TE Fast Reroute, as defined in [RFC4090], which uses either bypass or detour tunnels. Applying Fast Reroute to MPLS, it is possible to wrap all LSPs using a bypass tunnel and a single label, or to wrap the traffic of each LSP around the failed links via a detour tunnel using a different label for each LSP.
包装行为类似于[RFC4090]中定义的MPLS-TE快速重路由，它使用旁路或迂回隧道。将快速重路由应用于MPLS，可以使用旁路隧道和单个标签包装所有LSP，或者通过迂回隧道使用每个LSP的不同标签包装故障链路周围的每个LSP流量。
___ ######## ___ ######## ___
======>/LSR\********/LSR\***XX***/LSR\
\_B_/@@@@@@@@\_A_/ \_F_/
*@ #*@
*@ #*@
*@ #*@
_*@ ___ #*@
/LSR\********/LSR\********/LSR\======>
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
___ ######## ___ ######## ___
======>/LSR\********/LSR\***XX***/LSR\
\_B_/@@@@@@@@\_A_/ \_F_/
*@ #*@
*@ #*@
*@ #*@
_*@ ___ #*@
/LSR\********/LSR\********/LSR\======>
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
===> connected LSP *** physical link
### working path @@@ wrapped data path
===> connected LSP *** physical link
### working path @@@ wrapped data path
Figure 1: Wrapping Protection for P2P Path
图1：P2P路径的包装保护
Consider the LSP that is shown in Figure 1 that enters the ring of LSRs at LSR-B and exits at LSR-E. The normal working path LSP follows through LSRs B-A-F-E. If a fault is detected on the link A<->F, then the wrapping mechanism decides that LSR-A would wrap the traffic around the ring, on a wrapped data path A-B-C-D-E-F, to arrive at LSR-F (on the far side of the failed link). LSR-F would then wrap the data packets back onto the working path F->E to the egress node. In this protection scheme, the traffic will follow the path B-A-B-C-D-E-F-E.
考虑图1所示的LSP，它在LSR-B进入LSR的环并在LSR-E退出。正常工作路径LSP通过LSRB-A—F—E。如果在链路A <-F上检测到故障，则包裹机制决定LSR-A在包裹的数据路径AB B-C-D-E-F上环绕环的业务到达LSR-F。（在故障链路的远端）。然后，LSR-F将数据包包装回到出口节点的工作路径F->E。在此保护方案中，流量将遵循路径B-A-B-C-D-E-F-E。
This protection scheme is simple in the sense that there is no need for coordination between the different LSRs in the ring -- only the LSRs that detect the fault must wrap the traffic, either onto the wrapped data path (at the near end) or back to the working path (at the far end). However, coordination of the switchover to the protection path would be needed to maintain the traffic on a co-routed bidirectional LSP even in cases of a unidirectional fault condition.
这种保护方案很简单，因为环中的不同LSR之间不需要协调——只有检测到故障的LSR必须将流量打包到打包的数据路径（在近端）或回工作路径（在远端）。然而，即使在单向故障情况下，也需要协调到保护路径的切换以维持共同路由的双向LSP上的流量。
The following considerations should be taken into account when considering use of wrapping protection:
考虑使用包装保护时，应考虑以下因素：
o Detection of mis-connectivity or loss of continuity should be performed at the link level and/or per LSR when using node-level protection. Configuration of the protection being performed (i.e., link protection or node protection) needs to be performed a priori, since the configuration of the proper protection path is dependent upon this decision.
o 当使用节点级保护时，应在链路级和/或每个LSR上检测连接错误或连续性丢失。所执行的保护的配置（即链路保护或节点保护）需要事先执行，因为正确保护路径的配置取决于该决定。
o There is a need to define a data path that traverses the alternate path around the ring to connect between the two neighbors of the detected fault. If protecting both the links and the nodes of an LSP, then, for a ring with N nodes, there is a need for O(2N) alternate paths.
o 需要定义一条数据路径，该路径穿过环周围的备用路径，以连接检测到的故障的两个邻居。如果同时保护LSP的链路和节点，则对于具有N个节点的环，需要O（2N）条备用路径。
o When wrapping, the data is transmitted over some of the links twice, once in each direction. For example, in the figure above the traffic is transmitted both B->A and then A->B, and later it is transmitted E->F and F->E. This means that there is additional bandwidth needed for this protection.
o 包装时，数据在某些链路上传输两次，每个方向一次。例如，在上图中，流量同时传输到B->A和A->B，然后再传输到E->F和F->E。这意味着此保护需要额外的带宽。
o If a double-fault situation occurs in the ring, then wrapping will not be able to deliver any packets except between the ingress and the first fault location encountered on the working path. This is based on the need for wrapping to connect between the neighbors of the fault location, and this is not possible in the segmented ring.
o 如果环中出现双重故障情况，则包装将无法传送任何数据包，除非在入口和工作路径上遇到的第一个故障位置之间。这是基于需要在故障位置的相邻点之间进行缠绕连接，而这在分段环中是不可能的。
o The resource pre-allocation for all of the alternate paths could be problematic (causing massive over subscription of the available resources). However, since most of these alternate paths will not be used simultaneously, there is the possibility of allocating zero resources and depending on the Network Management System (NMS) to allocate the proper resources around the ring, based on actual traffic usage.
o 所有备用路径的资源预分配可能会有问题（导致对可用资源的大量过度订阅）。但是，由于大多数备用路径不会同时使用，因此有可能分配零资源，并根据实际流量使用情况，根据网络管理系统（NMS）在环路周围分配适当的资源。
o Wrapping also involves a small increase in traffic latency in delivering the packets, as a result of traversing the entire ring, during protection.
o 由于在保护过程中遍历整个环，因此包装还涉及在传递数据包时稍微增加流量延迟。
The second common scheme for ring protection, steering, takes advantage of the ring topology by defining two paths from the ingress node of the ring to the egress point going in opposite directions around the ring. This is illustrated in Figure 2, where if we assume that the traffic needs to enter the ring from node B and exit through
第二种常见的环保护方案，即转向，通过定义从环的入口节点到环周围方向相反的出口点的两条路径，利用了环拓扑。这如图2所示，如果我们假设流量需要从节点B进入环，然后通过
node F, we could define a primary path through nodes B-A-F, and an alternate path through the nodes B-C-D-E-F. In steering, the switching is always performed by the ingress node (node B in Figure 2). If a fault condition is detected anywhere on the working path (B-A-F), then the traffic would be redirected by B to the alternate path (i.e., B-C-D-E-F).
节点F，我们可以定义通过节点B-a-F的主路径，以及通过节点B-C-D-E-F的备用路径。在转向中，切换始终由入口节点执行（图2中的节点B）。如果在工作路径（B-a-F）的任何位置检测到故障，则B会将流量重定向到备用路径（即B-C-D-e-F）。
___ ___ ___
======>/LSR\********/LSR\********/LSR\======>
\_B_/########\_A_/########\_F_/
*@ @*
*@ @*
*@ @*
_*@ ___ @*_
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
___ ___ ___
======>/LSR\********/LSR\********/LSR\======>
\_B_/########\_A_/########\_F_/
*@ @*
*@ @*
*@ @*
_*@ ___ @*_
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
===> connected LSP *** physical link
### working path @@@ protection path
===> connected LSP *** physical link
### working path @@@ protection path
Figure 2: Steering Protection in an MPLS-TP Ring
图2:MPLS-TP环中的转向保护
This mechanism bears similarities to linear 1:1 protection [RFC6372]. The two paths around the ring act as the working and protection paths. This requires that the ingress node be informed of the need to switch over to the protection path, and also that the ingress and egress nodes coordinate the switchover. There is need to communicate to the ingress node the need to switch over to the protection path and there is a need to coordinate the switchover between the two endpoints of the protected domain.
该机制与线性1:1保护[RFC6372]具有相似性。环周围的两条路径充当工作和保护路径。这要求入口节点被告知需要切换到保护路径，并且入口和出口节点协调切换。需要向入口节点传达切换到保护路径的需要，并且需要协调受保护域的两个端点之间的切换。
The following considerations must be taken into account regarding the steering architecture:
关于转向架构，必须考虑以下因素：
o Steering relies on a failure detection method that is able to notify the ingress node of the fault condition. This may involve OAM functionality described in [RFC6371], e.g., Remote Defect Indication, alarm reporting.
o 转向依赖于故障检测方法，该方法能够将故障情况通知入口节点。这可能涉及[RFC6371]中描述的OAM功能，例如远程缺陷指示、报警报告。
o The process of notifying the ingress node adds to the latency of the protection-switching process, after the detection of the fault condition.
o 在检测到故障状况后，通知入口节点的过程增加了保护切换过程的延迟。
o While there is no need for double bandwidth for the data path, there is the necessity for the ring to maintain enough capacity for all of the data in both directions around the ring.
o 虽然数据路径不需要双倍带宽，但环有必要为环周围两个方向上的所有数据保持足够的容量。
The SPME concept was introduced by [RFC5921] to support management and monitoring an arbitrary segment of a transport. However, an SPME is essentially a valid LSP that may be used to aggregate all LSP traffic that traverses the sub-path delineated by the SPME. An SPME may be monitored using the OAM mechanisms as described in the MPLS-TP OAM framework document [RFC6371].
[RFC5921]引入SPME概念，以支持管理和监控传输的任意段。然而，SPME本质上是一个有效的LSP，可用于聚合通过SPME所描绘的子路径的所有LSP流量。可以使用MPLS-TP OAM框架文档[RFC6371]中描述的OAM机制来监控SPME。
When defining an MPLS-TP ring as a protection domain, there is a need to design a protection mechanism that protects all the LSPs that cross the MPLS-TP ring. For this purpose, we associate a (working) SPME with the segment of the transport path that traverses the ring. In addition, we configure an alternate (protecting) SPME that traverses the ring in the opposite direction around the ring. The exact selection of the SPMEs is dependent on the types of transport path and protection that are being implemented. This will be detailed in the following subsections.
在将MPLS-TP环定义为保护域时，需要设计一种保护机制来保护穿过MPLS-TP环的所有LSP。为此，我们将（工作）SPME与穿过环的传输路径段相关联。此外，我们还配置了一个备用（保护）SPME，该SPME沿着环的相反方向穿过环。SPME的准确选择取决于正在实施的传输路径和保护的类型。这将在以下小节中详细说明。
Based on this architectural configuration for protection of ring topologies, it is possible to limit the number of alternate paths needed to protect the data traversing the ring. In addition, since we will perform all of the OAM functionality on the SPME configured for the traffic, we can minimize the number of OAM sessions needed to monitor the data traffic of the ring, rather than monitoring each individual LSP.
基于这种保护环拓扑的体系结构配置，可以限制保护穿过环的数据所需的备用路径的数量。此外，由于我们将在为流量配置的SPME上执行所有OAM功能，因此我们可以最小化监视环的数据流量所需的OAM会话数量，而不是监视每个LSP。
In all of the following subsections, we use 1:1 linear protection [RFC6372] [RFC6378] to perform protection switching and coordination when a signal fault is detected. The actual configuration of the SPMEs used may change depending upon the choice of methodology, and this will be detailed in the following sections. However, in all of these configurations, the mechanism will be to transmit the data traffic on the primary SPME, while applying OAM functionality over both the primary and the secondary SPME to detect signal fault conditions on either path. If a signal fault is detected on the primary SPME, then the mechanism described in [RFC6378] shall be used to coordinate a switchover of data traffic to the secondary SPME.
在以下所有小节中，我们使用1:1线性保护[RFC6372][RFC6378]在检测到信号故障时执行保护切换和协调。所用SPME的实际配置可能会根据方法的选择而变化，这将在以下章节中详细说明。然而，在所有这些配置中，机制将是在主SPME上传输数据流量，同时在主SPME和辅助SPME上应用OAM功能以检测任一路径上的信号故障状况。如果在主SPME上检测到信号故障，则应使用[RFC6378]中描述的机制来协调数据流量到辅助SPME的切换。
Assuming that the SPME is implemented as an hierarchical LSP, packets that arrive at LSR-B with a label stack [LI] will have the SPME label pushed at LSR-B, and the LSP label will be swapped for the label that is expected by the egress LSR (i.e., the packet will arrive at LSR-A with a label stack of [PA1(B) | LE] and arrive at LSR-F with [PE1(F) | LE]). The SPME label will be popped by LSR-F, and the LSP label will be treated appropriately at LSR-F and forwarded along the LSP, outside the ring. This scenario is true for all LSPs that are aggregated by this primary SPME.
假设SPME被实现为分层LSP，到达LSR-B时带有标签堆栈[LI]的数据包将在LSR-B处推送SPME标签，并且LSP标签将被交换为出口LSR预期的标签（即，数据包将到达LSR-a时带有[PA1（B）| LE]的标签堆栈，并到达LSR-F时带有[PE1（F）| LE]）。LSR-F将弹出SPME标签，LSP标签将在LSR-F处进行适当处理，并沿着LSP在环外转发。此场景适用于由此主SPME聚合的所有LSP。
A P2P SPME that traverses part of a ring has two Maintenance Entity Group End Points (MEPs), each one acts as the ingress and egress in one direction of the bidirectional SPME. Since the SPME is traversing a ring, we can take advantage of another characteristic of a ring -- there is always an alternative path between the two MEPs, i.e., traversing the ring in the opposite direction. This alternative SPME can be defined as the protection path for the working path that is configured as part of the LSP and defined as a SPME.
穿过环的一部分的P2P SPME具有两个维护实体组端点（mep），每个端点充当双向SPME的一个方向上的入口和出口。由于SPME正在穿过一个环，我们可以利用环的另一个特性——两个MEP之间总是有一条可选路径，即，以相反的方向穿过环。此替代SPME可定义为工作路径的保护路径，该工作路径配置为LSP的一部分，并定义为SPME。
For each pair of SPMEs that are defined in this way, it is possible to verify the connectivity and continuity by applying the MPLS-TP OAM functionality to both the working and protection SPME. If a discontinuity or mis-connectivity is detected, then the MEPs will become aware of this condition and could perform a protection switch of all LSPs to the alternate, protection SPME.
对于以这种方式定义的每对SPME，可以通过将MPLS-TP OAM功能应用于工作和保护SPME来验证连接性和连续性。如果检测到不连续或连接错误，则MEP将意识到这种情况，并可将所有LSP切换到备用保护SPME。
The following figure shows an MPLS-TP ring that is part of a larger MPLS-TP network. The ring could be used as a network segment that may be traversed by numerous LSPs. In particular, the figure shows that for all LSPs that connect to the ring at LSR-B and exit the ring from LSR-F, we configure two SPMEs through the ring (the first SPME traverses B-A-F, and the second SPME traverses B-C-D-E-F).
下图显示了作为更大MPLS-TP网络一部分的MPLS-TP环。环可用作可被多个LSP穿越的网段。特别是，该图显示，对于在LSR-B连接到环并从LSR-F退出环的所有LSP，我们通过环配置两个SPME（第一个SPME穿过B-A-F，第二个SPME穿过B-C-D-E-F）。
___ ___ ___
=====>/LSR\********/LSR\********/LSR\======>
\_B_/########\_A_/########\_F_/
*@ @*
*@ @*
*@ @*
_*@ ___ @*_
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
___ ___ ___
=====>/LSR\********/LSR\********/LSR\======>
\_B_/########\_A_/########\_F_/
*@ @*
*@ @*
*@ @*
_*@ ___ @*_
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
===> connected LSP *** physical link
### primary SPME @@@ secondary SPME
===> connected LSP *** physical link
### primary SPME @@@ secondary SPME
Figure 3: An MPLS-TP Ring
图3:MPLS-TP环
This protection mechanism is identical to the application of 1:1 linear protection [RFC6372] [RFC6378] to the pair of SPMEs. Under normal conditions, all LSP data traffic will be transmitted on the working SPME. If the linear protection is triggered by the OAM indication, another fault indication trigger, or an operator command, then the MEPs will select the protection SPME to transmit all LSP data packets.
该保护机制与对SPME应用1:1线性保护[RFC6372][RFC6378]相同。正常情况下，所有LSP数据流量将在工作SPME上传输。如果线性保护由OAM指示、另一个故障指示触发器或操作员命令触发，则MEP将选择保护SPME以传输所有LSP数据包。
The protection SPME will continue to transmit the data packets until the stable recovery of the fault condition. Upon recovery, i.e., the fault condition has cleared and the network is stabilized, the ingress LSR could switch traffic back to the working SPME, if the protection domain is configured for revertive behavior.
保护SPME将继续传输数据包，直到故障状态稳定恢复。恢复后，即故障条件已清除且网络稳定，如果保护域配置为恢复行为，则入口LSR可将流量切换回工作SPME。
The control of the protection switching, especially for cases of operator commands, would be covered by the protocol defined in [RFC6378].
[RFC6378]中定义的协议将涵盖保护切换的控制，尤其是在操作员命令的情况下。
It is possible to use the SPME mechanism to perform segment-based protection. For each link in the ring, we define two SPMEs -- the first is a SPME between the two LSRs that are connected by the link, and the second SPME is between those same two LSRs but traverses the entire ring (except the link that connects the LSRs). In Figure 4, we show the primary SPME that connects LSR-A and LSR-F over a segment connection, and the secondary SPME that connects these same LSRs by traversing the ring in the opposite direction.
可以使用SPME机制执行基于段的保护。对于环中的每个链路，我们定义了两个SPME——第一个是由链路连接的两个LSR之间的SPME，第二个SPME是在这两个相同的LSR之间，但穿过整个环（连接LSR的链路除外）。在图4中，我们显示了通过段连接连接LSR-A和LSR-F的主SPME，以及通过以相反方向穿过环连接这些相同LSR的次SPME。
___ ___ ___
/LSR\********/LSR\********/LSR\
\_B_/@@@@@@@@\_A_/########\_F_/
*@ *@
*@ *@
*@ *@
_*@ ___ _*@
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
___ ___ ___
/LSR\********/LSR\********/LSR\
\_B_/@@@@@@@@\_A_/########\_F_/
*@ *@
*@ *@
*@ *@
_*@ ___ _*@
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
*** physical link
### primary SPME @@@ secondary SPME
*** physical link
### primary SPME @@@ secondary SPME
Figure 4: Segment SPMEs
图4：分段SPME
By applying OAM monitoring of these two SPMEs (at each LSR), it is possible to effect a wrapping protection mechanism for the LSP traffic that traverses the ring. The LSR on either side of the segment would identify that there is a fault condition on the link and redirect all LSP traffic to the secondary SPME. The traffic would traverse the ring until arriving at the neighboring (relative to the segment) LSR. At this point, the LSP traffic would be redirected onto the original LSP, quite likely over the neighboring SPME.
通过对这两个spme（在每个LSR处）应用OAM监控，可以对穿过环的LSP通信量实施包装保护机制。段任一侧的LSR将识别链路上存在故障，并将所有LSP通信重定向到辅助SPME。流量将穿过环，直到到达相邻（相对于段）LSR。此时，LSP流量将被重定向到原始LSP，很可能通过相邻的SPME。
Following the progression of the label stack through this switching operation (for a LSP that enters the ring at LSR-B and exits the ring at LSR-E):
随着标签堆栈通过该切换操作的进行（对于在LSR-B处进入环并在LSR-E处退出环的LSP）：
1. The data packet arrives at LSR-A with label stack [L1+S] (i.e., the top label from the LSP and bottom-of-stack indicator)
1. 数据包到达LSR-A时带有标签堆栈[L1+S]（即，来自LSP的顶部标签和堆栈底部指示符）
2. In the normal case (no protection switching), LSR-A forwards the packet with label stack [PA1(F) | LSE+S] (i.e., swaps the label for the LSP, to be acceptable to the SPME egress, and pushes the label for the primary SPME from LSR-A to LSR-F).
2. 在正常情况下（无保护交换），LSR-A使用标签堆栈[PA1（F）| LSE+S]（即，交换LSP的标签，以便SPME出口接受，并将主SPME的标签从LSR-A推送到LSR-F）。
3. When protection switching is in effect, LSR-A forwards the packet with label stack [PA2(B) | LSE+S] (i.e., LSR-A pushes the label for the secondary SPME from LSR-A to LSR-F, after swapping the label of the lower-level LSP). This will be transmitted along the secondary SPME until LSR-E forwards it to LSR-F with label stack [PE2(F) | LSE+S].
3. 当保护交换生效时，LSR-A使用标签堆栈[PA2（B）| LSE+S]转发数据包（即，在交换较低级别LSP的标签后，LSR-A将辅助SPME的标签从LSR-A推送到LSR-F）。这将沿着辅助SPME传输，直到LSR-E使用标签堆栈[PE2（F）| LSE+S]将其转发给LSR-F。
4. When the packet arrives at LSR-F, it pops the SPME label, process the LSP label, and forwards the packet to the next point, possibly pushing a SPME label if the next segment is likewise protected.
4. 当数据包到达LSR-F时，它弹出SPME标签，处理LSP标签，并将数据包转发到下一点，如果下一段同样受到保护，则可能推送SPME标签。
Implementation of protection at the node level would be similar to the mechanism described in the previous subsection. The difference would be in the SPMEs that are used. For node protection, the primary SPME would be configured between the two LSRs that are connected to the node that is being protected (see the SPME between LSR-A and LSR-E through LSR-F in Figure 5), and the secondary SPME would be configured between these same nodes, going around the ring (see the secondary SPME in Figure 5).
在节点级别实施保护类似于上一小节中描述的机制。不同之处在于所使用的SPME。对于节点保护，主SPME将在连接到受保护节点的两个LSR之间配置（参见图5中通过LSR-F的LSR-A和LSR-E之间的SPME），次SPME将在这些相同节点之间配置，绕环运行（参见图5中的次SPME）。
___ ___ ___
/LSR\********/LSR\********/LSR\
\_B_/@@@@@@@@\_A_/########\_F_/
*@ *#
*@ *#
*@ *#
_*@ ___ _*#
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
___ ___ ___
/LSR\********/LSR\********/LSR\
\_B_/@@@@@@@@\_A_/########\_F_/
*@ *#
*@ *#
*@ *#
_*@ ___ _*#
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
*** physical link
### primary SPME @@@ secondary SPME
*** physical link
### primary SPME @@@ secondary SPME
Figure 5: Node-Protection SPMEs
图5：节点保护SPME
The protection mechanism would work similarly -- it would be based on 1:1 linear protection [RFC6372] and be triggered by OAM functions on both SPMEs. It would wrap the data packets onto the secondary SPME at the ingress MEP (e.g., LSR-A in the figure) of the SPME and back onto the continuation of the LSP at the egress MEP (e.g., LSR-E in the figure) of the SPME.
保护机制的工作原理类似——它基于1:1线性保护[RFC6372]，由两个SPME上的OAM函数触发。它将在SPME的入口MEP（例如，图中的LSR-A）将数据分组包装到辅助SPME上，并在SPME的出口MEP（例如，图中的LSR-e）将数据分组包装到LSP的延续上。
In the different types of wrapping presented in Section 2.3.2 and Section 2.3.3, there is a limitation that the protection mechanism must a priori decide whether it is protecting against link or node failure. In addition, the neighboring LSR, that detects the fault, cannot readily differentiate between a link failure or a node failure.
在第2.3.2节和第2.3.3节中介绍的不同类型的包装中，存在一个限制，即保护机制必须事先决定它是针对链路还是节点故障进行保护。此外，检测故障的相邻LSR不能轻易区分链路故障或节点故障。
It would be possible to configure extra SPMEs to protect both for link and node failures, arriving at a configuration of the ring that is shown in Figure 6. Here, there are three protection SPMEs configured:
可以配置额外的SPME来保护链路和节点故障，从而得到如图6所示的环配置。此处配置了三个保护SPME：
o Secondary node#1 would be used to divert traffic as a result of an indication that LSR-F is not available; it redirects the traffic to the path between LSR-A and LSR-E.
o 辅助节点#1将用于在指示LSR-F不可用时转移流量；它将流量重定向到LSR-A和LSR-E之间的路径。
o Secondary node#2 would be used to divert traffic as a result of an indication that LSR-A is not available; it redirects the traffic to the path between LSR-F and LSR-B.
o 辅助节点#2将用于在指示LSR-a不可用时转移流量；它将流量重定向到LSR-F和LSR-B之间的路径。
o Secondary segment would be used to divert traffic as a result of an indication that the segment between LSR-A and LSR-F is not available; it redirects the traffic to the path between LSR-A and LSR-F on the long circuit of the ring.
o 由于指示LSR-a和LSR-F之间的路段不可用，二级路段将用于分流交通；它将流量重定向到环长电路上LSR-A和LSR-F之间的路径。
However, choosing the SPME to use for the wrapping would then involve considerable effort and could result in the protected traffic not sharing the same protection path in both directions.
但是，选择用于包装的SPME将需要相当大的努力，并可能导致受保护的流量在两个方向上不共享相同的保护路径。
___ ++++++++ ___ ___
/LSR\********/LSR\********/LSR\
\_B_/@@@@@@@@\_A_/########\_F_/
$+*@ +*$
$+*@ +*$
$+*@ +*$
$+*@ ++++++++ ___ ++++++++ +*$
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
$$$$$$$$ $$$$$$$$
___ ++++++++ ___ ___
/LSR\********/LSR\********/LSR\
\_B_/@@@@@@@@\_A_/########\_F_/
$+*@ +*$
$+*@ +*$
$+*@ +*$
$+*@ ++++++++ ___ ++++++++ +*$
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
$$$$$$$$ $$$$$$$$
*** physical link
### primary SPME @@@ secondary node#1 SPME
$$$ secondary node#2 SPME +++ secondary segment SPME
*** physical link
### primary SPME @@@ secondary node#1 SPME
$$$ secondary node#2 SPME +++ secondary segment SPME
Figure 6: SPMEs for Protecting Segments and Node
图6：用于保护段和节点的SPME
Analyzing steering SPME protection (Section 2.3.1) and wrapping based on SPME (Sections 2.3.2 or 2.3.3), we can make the following observations (based on a ring with N nodes, where N is not more than 16):
分析转向SPME保护（第2.3.1节）和基于SPME的包装（第2.3.2节或第2.3.3节），我们可以进行以下观察（基于具有N个节点的环，其中N不超过16）：
o Number of SPMEs that need to be configured
o 需要配置的SPME数量
For steering: O(2N^2). There are two SPMEs from each ingress LSR to each of the other nodes in the ring.
转向：O（2N^2）。从每个入口LSR到环中的每个其他节点有两个SPME。
For wrapping: O(2N). (However, the operator must decide a priori whether to protect for link failures or node failures at each point.)
用于包装：O（2N）。（但是，操作员必须事先决定是否在每个点保护链路故障或节点故障。）
o Number of OAM sessions at each node
o 每个节点上的OAM会话数
For steering: O(2N)
转向：O（2N）
For wrapping: 3
包装：3
o Bandwidth requirements
o 带宽要求
For steering: single bandwidth at each link
转向：每条链路上的单一带宽
For wrapping: double bandwidth at links that are between ingress and wrapping node and between second wrapping node and egress.
对于包装：入口和包装节点之间以及第二个包装节点和出口之间的链路的带宽加倍。
o Special considerations
o 特别注意事项
For steering: latency of OAM detection of fault condition by ingress MEP. (Using alarm reporting could optimize over using CC-V only.)
转向：入口MEP检测故障状态的OAM延迟。（使用报警报告可以比仅使用CC-V进行优化。）
For wrapping: each node must decide a priori whether it is protecting for link or node failures. To protect for both node and link failures would increase the complexity of deciding which protection path to use, as well as violate the co-routedness of the protected traffic.
对于包装：每个节点必须事先决定是保护链路还是保护节点故障。对节点和链路故障进行保护将增加决定使用哪条保护路径的复杂性，并破坏受保护流量的共路由性。
Based on this analysis, using steering as described in Section 2.3.1 would be the recommended protection mechanism due to its simplicity. It should be pointed out that the number of SPMEs involved in this protection could be reduced by eliminating each SPME between a pair of LSRs that is not used as an ingress and egress pair.
基于此分析，由于其简单性，建议使用第2.3.1节中所述的转向装置。应该指出的是，通过消除一对不用作入口和出口对的LSR之间的每个SPME，可以减少该保护中涉及的SPME数量。
Based on the analysis presented, while applying linear protection to effect wrapping protection in a ring topology is possible as demonstrated, there are certain limitations in addressing some of the required behavior. The limitations include:
根据所提供的分析，虽然应用线性保护在环形拓扑中实现环绕保护是可能的，但在解决某些所需行为方面存在一定的限制。这些限制包括：
o the need to configure a priori whether link or node protection will be provided
o 需要预先配置是否提供链路或节点保护
o the higher number of SPMEs that need to be defined
o 需要定义的SPME数量较多
o the difficulty in addressing cases of multiple failures in the ring
o 解决环中多个故障的困难
Application of linear protection, based on the use of SPMEs within the ring, to implement a steering methodology to protect a ring topology is rather straightforward, overcomes the limitations listed above, and scales very well. For this and other reasons listed previously, the authors recommend the use of steering to provide protection of P2P paths that traverse a ring topology.
基于在环内使用SPME的线性保护的应用，以实现保护环拓扑的指导方法非常简单，克服了上面列出的限制，并且扩展性非常好。出于上述原因和其他原因，作者建议使用转向来保护穿越环形拓扑的P2P路径。
[RFC5654] requires that ring protection must provide protection for unidirectional point-to-multipoint paths through the ring. Ring topologies provide a ready platform for supporting such data paths. A point-to-multipoint (P2MP) LSP in an MPLS-TP ring would be characterized by a single ingress LSR and multiple egress LSRs. The following subsections will present methods to address the protection of the ring-based sections of these LSPs.
[RFC5654]要求环保护必须为通过环的单向点对多点路径提供保护。环形拓扑为支持此类数据路径提供了一个现成的平台。MPLS-TP环中的点对多点（P2MP）LSP具有单入口LSR和多出口LSR的特征。以下小节将介绍解决这些LSP基于环的部分保护的方法。
When protecting a P2MP ring data path using the wrapping architecture, the basic operation is similar to the description given, as the traffic has been wrapped back onto the normal working path on the far side of the detected fault and will continue to be transported to all of the egress points.
当使用包裹架构保护P2MP环形数据路径时，基本操作与给出的描述类似，因为流量已被包裹回检测故障远端的正常工作路径，并将继续传输到所有出口点。
It is possible to optimize the performance of the wrapping mechanism when applied to P2MP LSPs by exploiting the topology of ring networks.
利用环形网络的拓扑结构，可以优化包装机制应用于P2MP LSP时的性能。
This improved mechanism, which we call Ring Optimized Multipoint Wrapping (ROM-Wrapping), behaves much the same as classical wrapping. However, ROM-Wrapping configures a protection P2MP LSP, relative to each node that is considered a failure risk. The protection P2MP LSP will be routed between the failure risk node's upstream neighbor to all of the egress nodes (for the particular LSP) that are downstream of the failure risk node.
这种改进的机制，我们称之为环优化多点包装（ROM包装），其行为与经典包装基本相同。但是，ROM包装相对于每个被视为故障风险的节点配置保护P2MP LSP。保护P2MP LSP将在故障风险节点的上游邻居之间路由到故障风险节点下游的所有出口节点（对于特定LSP）。
Referring to Figure 7, it is possible to identify the protected (working) LSP (A-B-{C}-{D}-E-{F}) and one possible backup (protection) LSP. (Note: the egress nodes are indicated by the curly braces.) This protection LSP will be used to wrap the data back around the ring to protect against a failure on link B-C. This protection LSP is also a P2MP LSP that is configured with egress points (at nodes F, D, and C) complementary to the broken working data path.
参考图7，可以识别受保护（工作）LSP（A-B-{C}-{D}-E-{F}）和一个可能的备份（保护）LSP。（注意：出口节点用花括号表示。）此保护LSP将用于将数据包裹回环，以防止链路B-C上出现故障。此保护LSP也是一个P2MP LSP，配置有出口点（在节点F、D和C处）以补充中断的工作数据路径。
|
|
V Ingress
___ _V_ ___
/LSR\ /LSR\**************/LSR\
<@@\_F_/@@@@@@@@@@@@@\_A_/@@@@@@@@@@@@@@\_B_/
@ * *
@ * *
@ * XXXX Failure
@ * *
@_* ___ __*
/LSR\*************/LSR\**************/LSR\
\_E_/@@@@@@@@@@@@@\_D_/@@@@@@@@@@@@@@\_C_/
@ @
@ @
V V
|
|
V Ingress
___ _V_ ___
/LSR\ /LSR\**************/LSR\
<@@\_F_/@@@@@@@@@@@@@\_A_/@@@@@@@@@@@@@@\_B_/
@ * *
@ * *
@ * XXXX Failure
@ * *
@_* ___ __*
/LSR\*************/LSR\**************/LSR\
\_E_/@@@@@@@@@@@@@\_D_/@@@@@@@@@@@@@@\_C_/
@ @
@ @
V V
*** working LSP @@@ protection LSP
*** working LSP @@@ protection LSP
Figure 7: P2MP ROM-Wrapping
图7:P2MP ROM包装
Using this mechanism, there is a need to configure a particular protection LSP for each node on the working LSP. In the table below, "X's Backup" is the backup path activated by node X as a consequence of a failure affecting node Y (downstream node with respect to X) or link X-Y. (Note: Braces in the path indicate egress nodes.)
使用此机制，需要为工作LSP上的每个节点配置特定的保护LSP。在下表中，“X的备份”是节点X因影响节点Y（相对于X的下游节点）或链路X-Y的故障而激活的备份路径。（注：路径中的括号表示出口节点。）
Protected LSP: A->B->{C}->{D}->E->{F}
Protected LSP: A->B->{C}->{D}->E->{F}
-- LINK/NODE PROTECTION --
--链路/节点保护--
A's Backup: A->{F}->E->{D}->{C}
B's Backup: B->A->{F}->E->{D}->{C}
C's Backup: C->B->A->{F}->E->{D}
D's Backup: D->C->B->A->{F}
E's Backup: E->D->C->B->A->{F}
A's Backup: A->{F}->E->{D}->{C}
B's Backup: B->A->{F}->E->{D}->{C}
C's Backup: C->B->A->{F}->E->{D}
D's Backup: D->C->B->A->{F}
E's Backup: E->D->C->B->A->{F}
It should be noted that ROM-Wrapping is an LSP-based protection mechanism, as opposed to the SPME-based protection mechanisms that are presented in other sections of this document. While this may seem to be limited in scope, the mechanism may be very efficient for many applications that are based on P2MP distribution schemes. While ROM-Wrapping can be applied to any network topology, it is particularly efficient for interconnected ring topologies.
应该注意的是，ROM包装是一种基于LSP的保护机制，而不是本文档其他章节中介绍的基于SPME的保护机制。虽然这似乎在范围上受到限制，但对于许多基于P2MP分发方案的应用程序，该机制可能非常有效。虽然ROM包装可以应用于任何网络拓扑，但它对于互连环拓扑特别有效。
It is possible to compare the wrapping and the ROM-Wrapping mechanisms in various aspects and show some improvements offered by ROM-Wrapping.
可以在各个方面比较包装和ROM包装机制，并展示ROM包装提供的一些改进。
When configuring the protection LSP for wrapping, it is necessary to configure for a specific failure: link protection or node protection. If the protection method is configured to protect against node failures, but the actual failure affects a link, this could result in failing to deliver traffic to the node, when it should be possible to do so.
在为包装配置保护LSP时，需要针对特定故障进行配置：链路保护或节点保护。如果将保护方法配置为针对节点故障进行保护，但实际故障会影响链路，这可能会导致无法向节点传递通信量，而此时应该可以这样做。
ROM-Wrapping, however, does not have this limitation because there is no distinction between node and link protection. Whether link B-C or node C fails, the rerouting will attempt to reach C. If the failure is on the link, the traffic will be delivered to C; if the failure is at node C, the traffic will be rerouted correctly until node D, and will be blocked at this point. However, all egress nodes up to the failure will be able to deliver the traffic properly.
然而，ROM包装并没有这个限制，因为节点保护和链接保护之间并没有区别。无论链路B-C还是节点C发生故障，重新路由都将尝试到达C。如果故障发生在链路上，则通信量将传送到C；如果故障发生在节点C，则在节点D之前，通信量将被正确重新路由，并在此时被阻塞。但是，故障之前的所有出口节点都将能够正确地交付流量。
A second aspect is the number of hops needed to properly deliver the traffic. Referring to the example shown in Figure 7, where a failure is detected on link B-C, the following table lists the set of nodes traversed by the data in the protection:
第二个方面是正确传递流量所需的跳数。参考图7所示的示例，在链路B-C上检测到故障时，下表列出了保护中的数据所经过的节点集：
Basic Wrapping:
基本包装：
A-B B-A-F-E-D-C {C}-{D}-E-{F}
"Upstream" segment backup path "Downstream" segment
with respect to the with respect to the
failure failure
A-B B-A-F-E-D-C {C}-{D}-E-{F}
"Upstream" segment backup path "Downstream" segment
with respect to the with respect to the
failure failure
ROM-Wrapping:
ROM包装：
A-B B-A-{F}-E-{D}-{C} ..
"Upstream" segment backup path
with respect to the
failure
A-B B-A-{F}-E-{D}-{C} ..
"Upstream" segment backup path
with respect to the
failure
Comparing the two lists of nodes, it is possible to see that in this particular case the number of hops crossed when basic wrapping is used is significantly higher than the number of hops crossed by the traffic when ROM-Wrapping is used. Generally, the number of hops for basic wrapping is always greater than or equal to that for ROM-Wrapping. This implies a certain waste of bandwidth on all links that are crossed in both directions.
比较两个节点列表，可以看出，在这种特定情况下，使用基本包装时交叉的跳数明显高于使用ROM包装时通信量交叉的跳数。通常，基本包装的跃点数总是大于或等于ROM包装的跃点数。这意味着在双向交叉的所有链路上存在一定的带宽浪费。
Considering the ring network in Figure 7, it is possible to consider the bandwidth utilization. The protected LSP is set up from A to F clockwise and an M Mbps bandwidth is reserved along the path. All the protection LSPs are pre-provisioned counterclockwise, each of them may also have reserved bandwidth M. These LSPs share the same bandwidth in a SE (Shared Explicit) style, as described in [RFC2205].
考虑到图7中的环形网络，可以考虑带宽利用率。受保护的LSP从A到F顺时针设置，沿路径保留M Mbps带宽。所有保护LSP都是逆时针预配置的，每个LSP也可能具有保留带宽M。这些LSP以SE（共享显式）方式共享相同的带宽，如[RFC2205]中所述。
The bandwidth reserved counterclockwise is not used when the protected LSP is properly working and, in theory, could be used for extra traffic [RFC4427]. However, it should be noted that [RFC5654] does not require support of such extra traffic.
当受保护的LSP正常工作时，不使用逆时针保留的带宽，理论上，该带宽可用于额外流量[RFC4427]。但是，应该注意的是，[RFC5654]不需要支持此类额外流量。
The two recovery mechanisms require different protection bandwidths. In the case of wrapping, the bandwidth used is M in both directions on many of the links. While in the case of ROM-Wrapping, only the links from the ingress node to the node performing the actual wrapping utilize M bandwidth in both directions, while all other links utilize M bandwidth only in the counterclockwise direction.
这两种恢复机制需要不同的保护带宽。在缠绕的情况下，在许多链路上，在两个方向上使用的带宽为M。而在ROM环绕的情况下，只有从入口节点到执行实际环绕的节点的链路在两个方向上利用M带宽，而所有其他链路仅在逆时针方向上利用M带宽。
Consider the case of a failure detected on link B-C as shown in Figure 7. The following table lists the bandwidth utilization on each link (in units equal to M), for each recovery mechanism and for each direction (CW=clockwise, CCW=counterclockwise).
考虑链路B-C上检测到的故障的情况，如图7所示。下表列出了每个恢复机制和每个方向（CW=顺时针，CCW=逆时针）每个链路上的带宽利用率（单位为M）。
+----------+----------+--------------+
| | Wrapping | ROM-Wrapping |
+----------+----------+--------------+
| Link A-B | CW+CCW | CW+CCW |
| Link A-F | CCW | CCW |
| Link F-E | CW+CCW | CCW |
| Link E-D | CW+CCW | CCW |
| Link D-C | CW+CCW | CCW |
+----------+----------+--------------+
+----------+----------+--------------+
| | Wrapping | ROM-Wrapping |
+----------+----------+--------------+
| Link A-B | CW+CCW | CW+CCW |
| Link A-F | CCW | CCW |
| Link F-E | CW+CCW | CCW |
| Link E-D | CW+CCW | CCW |
| Link D-C | CW+CCW | CCW |
+----------+----------+--------------+
A further comparison of wrapping and ROM-Wrapping can be done with respect to their ability to react to multiple failures. The wrapping recovery mechanism does not have the ability to recover from multiple failures on a ring network, while ROM-Wrapping is able to recover from some multiple failures.
可以进一步比较包装和ROM包装对多个故障的反应能力。包装恢复机制不能从环形网络上的多个故障中恢复，而ROM包装可以从一些多个故障中恢复。
Consider, for example, a double link failure affecting links B-C and C-D shown in Figure 7. The wrapping mechanism is not able to recover from the failure because B, upon detecting the failure, has no alternative paths to reach C. All the P2MP traffic is lost. The
例如，考虑影响链路B-C和C-D的双链路故障，如图7所示。包装机制无法从故障中恢复，因为B在检测到故障后，没有其他路径可以到达C。所有P2MP通信量都会丢失。这个
ROM-Wrapping mechanism is able to partially recover from the failure, because the backup P2MP LSP to F and D is correctly set up and continues delivering traffic.
ROM包装机制能够从故障中部分恢复，因为F和D的备份P2MP LSP已正确设置并继续提供流量。
When protecting P2MP traffic that uses an MPLS-TP ring as its branching point (i.e., the traffic enters the ring at a head-end node and exits the ring at multiple nodes), we can employ a steering mechanism based on 1+1 linear protection [RFC6372]. We can configure two P2MP unidirectional SPMEs from each node on the ring; they traverse the ring in both directions. These SPMEs will be configured with an egress at each ring node. In order to be able to direct the LSP traffic to the proper egress point for that particular LSP, we need to employ context labeling as defined in [RFC5331]. The method for using these labels is expanded upon in Section 3.2.1.
当保护使用MPLS-TP环作为其分支点的P2MP流量（即，流量在前端节点进入环，在多个节点退出环）时，我们可以采用基于1+1线性保护的转向机制[RFC6372]。我们可以从环上的每个节点配置两个P2MP单向SPME；它们从两个方向穿过环。这些SPME将在每个环节点配置一个出口。为了能够将LSP流量引导到特定LSP的适当出口点，我们需要使用[RFC5331]中定义的上下文标记。第3.2.1节对使用这些标签的方法进行了扩展。
For every LSP that enters the ring at a given node, the traffic will be sent through both of these SPMEs, each with its own context label and the context-specific label for the particular LSP. The egress nodes should select the traffic that is arriving on the working SPME. When a failure condition is identified, the egress nodes should select the traffic from whichever of the two SPMEs whose traffic arrives at that node, i.e., since one of the two (presumably the working SPME) will be blocked by the failure. In this way, all egress nodes are able to receive the data traffic. While each node detects that there is connectivity from the ingress node of the ring, it continues to select the data that is coming from the working SPME. If a particular node stops receiving the connectivity messages from the working SPME, it identifies that it must select to read the data packets from the protection SPME.
对于在给定节点进入环的每个LSP，流量将通过这两个SPME发送，每个SPME都有自己的上下文标签和特定LSP的上下文特定标签。出口节点应选择到达工作SPME的流量。当识别出故障条件时，出口节点应从其流量到达该节点的两个SPME中的任何一个中选择流量，即，因为两个SPME中的一个（可能是工作SPME）将被故障阻塞。这样，所有出口节点都能够接收数据流量。当每个节点检测到有来自环的入口节点的连接时，它继续选择来自工作SPME的数据。如果某个特定节点停止接收来自工作SPME的连接消息，则该节点会标识它必须选择从保护SPME读取数据包。
Figure 8 shows the two unidirectional P2MP SPMEs that are configured from LSR-A with egress points at all of the nodes on the ring. The clockwise SPME (i.e., A-B-C-D-E-F) is configured as the working SPME that will aggregate all traffic for P2MP LSPs that enter the ring at LSR-A and must be sent out of the ring at any subset of the ring nodes. The counter-clockwise SPME (i.e., A-F-E-D-C-B) is configured as the protection SPME.
图8显示了从LSR-A配置的两个单向P2MP SPME，其出口点位于环上的所有节点。顺时针SPME（即A-B-C-D-e-F）配置为工作SPME，该SPME将聚合在LSR-A处进入环的P2MP LSP的所有通信量，并且必须在环节点的任何子集处从环发送出去。逆时针SPME（即A-F-e-D-C-B）配置为保护SPME。
^ ^ ^
_|_ _|_ _|_
----->/LSR\********/LSR\********/LSR\
\_A_/========\_B_/========\_C_/
+* <+++++++++*||
+* +*||
+* +*||
+* +*||
+*_ ++++++++ ___ +++++++++*||
/LSR\********/LSR\********/LSR\
\_F_/<=======\_E_/========\_D_/
| | |
V V V
^ ^ ^
_|_ _|_ _|_
----->/LSR\********/LSR\********/LSR\
\_A_/========\_B_/========\_C_/
+* <+++++++++*||
+* +*||
+* +*||
+* +*||
+*_ ++++++++ ___ +++++++++*||
/LSR\********/LSR\********/LSR\
\_F_/<=======\_E_/========\_D_/
| | |
V V V
---> connected LSP *** physical link
=== working SPME +++ protection SPME
---> connected LSP *** physical link
=== working SPME +++ protection SPME
Figure 8: P2MP SPMEs
图8:P2MP SPME
[RFC5331] defines the concept of context labels. A context-identifying label defines a context label space that is used to interpret the context-specific labels (found directly below the context-identifying label) for a specific tunnel. The SPME label is a context-identifying label. This means that at each hop the node that receives the SPME label uses it to point not directly to a forwarding table, but to a Label Information Base (LIB). As a node receives an SPME label, it examines it, discovers that it is a context label, pops off the SPME label, and looks up the next label down in the stack in the LIB indicated by the context label.
[RFC5331]定义了上下文标签的概念。上下文标识标签定义上下文标签空间，用于解释特定隧道的上下文特定标签（位于上下文标识标签的正下方）。SPME标签是上下文标识标签。这意味着，在每个跃点处，接收SPME标签的节点使用它来指向标签信息库（LIB），而不是直接指向转发表。当一个节点收到一个SPME标签时，它会检查它，发现它是一个上下文标签，弹出SPME标签，并在由上下文标签指示的库中的堆栈中向下查找下一个标签。
The label below this context-identifying label should be used by the forwarding function of the node to decide the actions to take for this packet. In MPLS-TP protection of ring topologies, there are two context LIBs. One is the context LIB for the working SPME, and the other is the context LIB for the protection SPME. All context LIBs have a behavior defined for the end-to-end LSP label, but the behavior at each node may be different in the context of each SPME.
节点的转发功能应使用此上下文标识标签下方的标签来决定对此数据包采取的操作。在环拓扑的MPLS-TP保护中，有两个上下文库。一个是用于工作SPME的上下文库，另一个是用于保护SPME的上下文库。所有上下文库都有一个为端到端LSP标签定义的行为，但在每个SPME的上下文中，每个节点的行为可能不同。
For example, using the ring that is shown in Figure 8, the working SPME is configured to have a context-identifying label of CW at each node on the ring, and the protection SPME is configured to have a context-identifying label of CP at each node. For the specific LSP, we will designate the context-specific label used on the working SPME as WL(x-y), where it's the label used as node-x forwards the packet to node-y. Similarly, a context-specific label on the protection SPME would be designated PL(x-y). An explicit example of label values appears in the next subsection.
例如，使用图8所示的环，工作SPME被配置为在环上的每个节点上具有CW的上下文识别标签，而保护SPME被配置为在每个节点上具有CP的上下文识别标签。对于特定的LSP，我们将在工作SPME上使用的上下文特定标签指定为WL（x-y），其中它是用作node-x将数据包转发给node-y的标签。类似地，保护SPME上特定于上下文的标签将被指定为PL（x-y）。标签值的明确示例将在下一小节中显示。
Assume we are applying 1+1 linear protection, as outlined above, for a P2MP LSP that enters the ring at LSR-A and has egress points from the ring at LSR-C and LSR-E using the two SPMEs shown in Figure 8. A packet that arrives at LSR-A with a label stack [LI+S] will be forwarded on the working SPME with a label stack [CW | WL(A-B)]. The packet should then be forwarded to LSR-C arriving with a label [CW | WL(B-C)], where WL(B-C) should instruct the forwarding function to egress the packet with [LE(C)] and forward a copy to LSR-D with label stack [CW | WL(C-D)].
假设我们正在对P2MP LSP应用1+1线性保护，如上所述，该LSP在LSR-a处进入环，并使用图8所示的两个SPME从LSR-C和LSR-E处的环中有出口点。到达带有标签堆栈[LI+S]的LSR-A的数据包将在带有标签堆栈[CW|WL（A-B）]的工作SPME上转发。然后，数据包应转发给带有标签[CW | WL（B-C）]的LSR-C，其中WL（B-C）应指示转发功能使用[LE（C）]退出数据包，并使用标签堆栈[CW | WL（C-D）]将副本转发给LSR-D。
If a fault condition is detected (for example, on the link C-D), then the nodes that are beyond the fault point (in this example, nodes LSR-D, LSR-E, and LSR-F), will cease to receive the data packets from the clockwise (working) SPME. Each of these LSRs should then begin to switch its "selector bridge" and accept the data packets from the protection (counter-clockwise) SPME. At the ingress point (LSR-A), all data packets will have been transmitted on both the working SPME and the protection SPME. Continuing the example, LSR-A will transmit one copy of the data to LSR-B with stack [CW | WL(A-B)] and one copy to LSR-F with stack [CP | PL(A-F)]. The packet will arrive at LSR-C from the working SPME and egress from the ring. LSR-E will receive the packet from the protection SPME with stack [CP | PL(F-E)], and the context-sensitive label PL(F-E) will instruct the forwarding function to send a copy out of the ring with label LE(E) and a second copy to LSR-D with stack [CP | PL(E-D)]. In this way, each of the egress points receives the packet from the SPME that is available at that point.
如果检测到故障条件（例如，在链路C-D上），则故障点以外的节点（在此示例中，节点LSR-D、LSR-E和LSR-F）将停止从顺时针（工作）SPME接收数据包。然后，这些LSR中的每一个都应开始切换其“选择器网桥”，并接受来自保护（逆时针）SPME的数据包。在入口点（LSR-A），所有数据包都将在工作SPME和保护SPME上传输。继续该示例，LSR-A将使用堆栈[CW | WL（A-B）]向LSR-B发送一份数据副本，并使用堆栈[CP | PL（A-F）]向LSR-F发送一份数据副本。数据包将从工作SPME到达LSR-C，并从环中退出。LSR-E将使用堆栈[CP | PL（F-E）]从保护SPME接收数据包，上下文敏感标签PL（F-E）将指示转发功能使用标签LE（E）从环发送一份副本，并使用堆栈[CP | PL（E-D）]向LSR-D发送第二份副本。这样，每个出口点从该点可用的SPME接收分组。
This architecture has the added advantages that there is no need for the ingress node to identify the existence of the mis-connectivity, and there is no need for a return path from the egress points to the ingress.
该架构具有附加的优点，即入口节点不需要识别是否存在mis连接，并且不需要从出口点到入口的返回路径。
In order to better demonstrate the use of the context labels, we present a walk-through of an example application of the P2MP protection presented in this section. Referring to Figure 9, there is a P2MP LSP that traverses the ring, entering the ring at LSR-B and branching off at LSR-D, LSR-E, and LSR-H, and it does not continue beyond LSR-H. For purposes of protection, two P2MP unidirectional SPMEs are configured on the ring starting from LSR-B. One of the SPMEs, the working SPME, is configured with egress points at each of the LSRs -- C, D, E, F, G, H, J, K, A. The second SPME, the protection SPME, is configured with egress points at each of the LSRs -- A, K, J, H, G, F, E, D, C.
为了更好地演示上下文标签的使用，我们将介绍本节介绍的P2MP保护的示例应用程序。参考图9，有一个P2MP LSP穿过环，在LSR-B处进入环，并在LSR-D、LSR-E和LSR-H处分支，它不会在LSR-H之外继续。出于保护目的，在环上从LSR-B开始配置两个P2MP单向SPME。其中一个SPME，即工作SPME，在每个LSR--C、D、E、F、G、H、J、K、A处配置出口点。第二SPME，即保护SPME，在每个LSR--A、K、J、H、G、F、E、D、C处配置出口点。
^ ^ ^ ^
^ ^ ^ ^
___ xxxxxxxxx_+_ xxxxxxxxxX+_xxxxxxxxxX+_ xxxxxxxx_+_
xxxxx>/LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\
\_B_/========\_C_/========\_D_/=======\_E_/=======\_F_/
*+ <+++++++++ +++++++ ++++++++*||x
*+ +*||x
*+ +*||x
*+ +*||x
_*++++++++++ ___ +++++++++___ ++++++++___+++++++++*||x
/LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\
\_A_/<=======\_K_/========\_J_/=======\_H_/=======\_G_/
+ + + +Xxxxxxxxxx +
v v v v v
v v v v v
^ ^ ^ ^
^ ^ ^ ^
___ xxxxxxxxx_+_ xxxxxxxxxX+_xxxxxxxxxX+_ xxxxxxxx_+_
xxxxx>/LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\
\_B_/========\_C_/========\_D_/=======\_E_/=======\_F_/
*+ <+++++++++ +++++++ ++++++++*||x
*+ +*||x
*+ +*||x
*+ +*||x
_*++++++++++ ___ +++++++++___ ++++++++___+++++++++*||x
/LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\
\_A_/<=======\_K_/========\_J_/=======\_H_/=======\_G_/
+ + + +Xxxxxxxxxx +
v v v v v
v v v v v
xxx P2MP LSP (X LSP egress) *** physical link
=== working SPME +++ protection SPME
+>> protection SPME egress
xxx P2MP LSP (X LSP egress) *** physical link
=== working SPME +++ protection SPME
+>> protection SPME egress
Figure 9: P2MP SPMEs
图9:P2MP SPME
For this example, we suppose that the LSP traffic enters the ring at LSR-B with the label stack [99], and leaves the ring:
对于本例，我们假设LSP通信量使用标签堆栈[99]在LSR-B处进入环，然后离开环：
o at LSR-D with stack [199]
o 具有堆栈的LSR-D处[199]
o at LSR-E with stack [299]
o 在LSR-E和堆栈[299]
o at LSR-H with stack [399]
o 在LSR-H和堆栈[399]
While it is possible for the context-identifying label for the SPME to be configured as a different value at each LSR, for the sake of this example, we will suppose a configuration of 200 as the context-identifying label for the working SPME at each of the LSRs in the ring, and 400 as the context-identifying label for the protection SPME at each LSR.
虽然SPME的上下文标识标签可以在每个LSR处配置为不同的值，但为了本示例，我们将假设200的配置作为环中每个LSR处工作SPME的上下文标识标签，以及400作为每个LSR处的保护SPME的上下文识别标签。
For the specific connected LSP, we configure the following context-specific labels:
对于特定连接的LSP，我们配置以下特定于上下文的标签：
+------+-----------------------------+------------------------------+
| node | W-context(200) | P-context(400) |
+------+-----------------------------+------------------------------+
| A | 65 {drop packet} | 165 {fwd w/ [400 | 190]} |
| C | 90 {fwd w/ [200 | 80]} | 190 {drop packet} |
| D | 80 {fwd w/ [200 | 75] + | 180 {egress w/ [199]} |
| | egress w/ [199]} | |
| E | 75 {fwd w/ [200 | 65] + | 175 {fwd w/ [400 | 180] + |
| | egress w/ [299]} | egress w/ [299]} |
| F | 65 {fwd w/ [200 | 55]} | 165 {fwd w/ [400 | 175]} |
| G | 55 {fwd w/ [200 | 45]} | 155 {fwd w/ [400 | 165]} |
| H | 45 {egress w/ [399]} | 145 {fwd w/ [400 | 155] + |
| | | egress w/ [399]} |
| J | 65 {drop packet} | 165 {fwd w/ [400 | 145]} |
| K | 65 {drop packet} | 190 {fwd w/ [400 | 165]} |
+------+-----------------------------+------------------------------+
+------+-----------------------------+------------------------------+
| node | W-context(200) | P-context(400) |
+------+-----------------------------+------------------------------+
| A | 65 {drop packet} | 165 {fwd w/ [400 | 190]} |
| C | 90 {fwd w/ [200 | 80]} | 190 {drop packet} |
| D | 80 {fwd w/ [200 | 75] + | 180 {egress w/ [199]} |
| | egress w/ [199]} | |
| E | 75 {fwd w/ [200 | 65] + | 175 {fwd w/ [400 | 180] + |
| | egress w/ [299]} | egress w/ [299]} |
| F | 65 {fwd w/ [200 | 55]} | 165 {fwd w/ [400 | 175]} |
| G | 55 {fwd w/ [200 | 45]} | 155 {fwd w/ [400 | 165]} |
| H | 45 {egress w/ [399]} | 145 {fwd w/ [400 | 155] + |
| | | egress w/ [399]} |
| J | 65 {drop packet} | 165 {fwd w/ [400 | 145]} |
| K | 65 {drop packet} | 190 {fwd w/ [400 | 165]} |
+------+-----------------------------+------------------------------+
When a packet arrives on the LSP to LSR-B with stack [99], the forwarding function determines that it is necessary to forward the packet to both the working SPME with stack [200 | 90] and the protection SPME with stack [400 | 165]. Each LSR on the SPME will identify the top label, i.e., 200 or 400, to be the context-identifying label and use the next label in the stack to select the forwarding action from the specific context table.
当数据包到达具有堆栈[99]的LSP到LSR-B时，转发功能确定有必要将数据包转发到具有堆栈[200 | 90]的工作SPME和具有堆栈[400 | 165]的保护SPME。SPME上的每个LSR将识别顶部标签，即200或400，作为上下文识别标签，并使用堆栈中的下一个标签从特定上下文表中选择转发操作。
Therefore, at LSR-C, the packet on the working SPME will arrive with stack [200 | 90], and the 200 will point to the middle column of the table above. After popping the 200, the next label, i.e., 90, will select the forwarding action "fwd w/ [200 | 80]", and the packet will be forwarded to LSR-D with stack [200 | 80]. In this manner, the packet will be forwarded along both SPMEs according to the configured behavior in the context tables. However, the egress points at LSR-D, LSR-E, and LSR-H will each be configured with a selector bridge so they will use only the input from the working SPME. If any of these egress points identifies that there is a connection fault on the working SPME, then the selector bridge will cause the LSR to read the input from the protection SPME.
因此，在LSR-C，工作SPME上的数据包将与堆栈[200 | 90]一起到达，200将指向上表的中间列。弹出200后，下一个标签（即90）将选择转发操作“fwd w/[200 | 80]”，数据包将通过堆栈[200 | 80]转发到LSR-D。以这种方式，数据包将根据上下文表中配置的行为沿两个spme转发。然而，LSR-D、LSR-E和LSR-H处的出口点将分别配置一个选择器桥，以便它们仅使用来自工作SPME的输入。如果这些出口点中的任何一个确定工作SPME上存在连接故障，则选择器电桥将导致LSR从保护SPME读取输入。
The survivability framework [RFC6372] indicates that there is a need to coordinate protection switching between the endpoints of a protected bidirectional domain. The coordination is necessary for particular cases, in order to maintain the co-routed nature of the bidirectional transport path. The particular cases where this becomes necessary include when unidirectional fault detection or operator commands are used.
生存性框架[RFC6372]指出，需要协调受保护双向域端点之间的保护切换。在特殊情况下，协调是必要的，以保持双向传输路径的共路由性质。需要这样做的特殊情况包括使用单向故障检测或操作员命令时。
By using the same mechanisms defined in [RFC6378] for linear protection to protect a single ring topology, we are able to gain a consistent solution for this coordination between the endpoints of the protection domain. The Protection State Coordination Protocol that is specified in [RFC6378] provides coverage for all the coordination cases, including support for operator commands, e.g., Forced Switch.
通过使用[RFC6378]中定义的线性保护机制来保护单环拓扑，我们能够获得保护域端点之间协调的一致解决方案。[RFC6378]中规定的保护状态协调协议涵盖了所有协调情况，包括对操作员命令的支持，例如强制切换。
Ring topologies are prevalent in traditional transport networks and will continue to be used for various reasons. Protection for transport paths that traverse a ring within an MPLS network can be provided by applying an appropriate instance of linear protection, as defined in [RFC6372]. This document has shown that for each of the traditional ring-protection architectures there is an application of linear protection that provides efficient coverage, based on the use of the Sub-Path Maintenance Entity (SPME), defined in [RFC5921] and [RFC6371]. For example:
环形拓扑在传统的传输网络中很普遍，由于各种原因将继续使用。通过应用[RFC6372]中定义的适当的线性保护实例，可以为穿过MPLS网络中的环的传输路径提供保护。本文件表明，对于每一种传统的环形保护体系结构，都有一种线性保护应用，该应用基于[RFC5921]和[RFC6371]中定义的子路径维护实体（SPME）的使用，提供有效的覆盖。例如：
o P2P steering - Configuration of two SPMEs, from the ingress node of the ring to the egress node of the ring, and 1:1 linear protection.
o P2P转向-配置两个SPME，从环的入口节点到环的出口节点，以及1:1线性保护。
o P2P Wrapping for link protection - Configuration of two SPMEs, one for the protected link and the second for the long route between the two neighboring nodes, and 1:1 linear protection.
o 用于链路保护的P2P包装-配置两个SPME，一个用于受保护链路，另一个用于两个相邻节点之间的长路由，以及1:1线性保护。
o P2P wrapping for node protection - Configuration of two SPMEs, one between the two neighbors of the protected node and the second between these two nodes on the long route, and 1:1 linear protection.
o 节点保护的P2P包装-配置两个SPME，一个在受保护节点的两个邻居之间，另一个在长路由上这两个节点之间，以及1:1线性保护。
o P2MP wrapping - it is possible to optimize the performance of the wrapping by configuring the proper protection path to egress the data at the proper branching nodes.
o P2MP包装-可以通过配置适当的保护路径来优化包装的性能，以便在适当的分支节点上输出数据。
o P2MP steering - by combining 1+1 linear protection and configuration of the SPME based on context-sensitive labeling of the protection path.
o P2MP转向-通过结合1+1线性保护和基于保护路径上下文敏感标签的SPME配置。
This document shows that use of the protection architecture and mechanisms suggested provides the optimizations needed to justify ring-specific protection as defined in [RFC5654].
本文档表明，使用建议的保护体系结构和机制提供了证明[RFC5654]中定义的特定于环的保护的合理性所需的优化。
Protection of traffic over a ring topology based on the steering architecture using basic 1:1 linear protection is a very efficient implementation for sections of a P2P transport path that traverses a ring. Steering should be the preferred mechanism for P2P protection in a ring topology since it reduces the extra bandwidth required when traffic doubles through wrapped protection, and it provides the ability to protect both against link and node failures without complicating the fault detection or requiring that multiple protection paths be configured. While this is true, it's possible to support either wrapping or steering while depending upon the OAM functionality (outlined in [RFC6371] and specified in various documents) and the coordination protocol specified for linear protection in [RFC6378].
使用基本的1:1线性保护，基于控制体系结构的环形拓扑上的流量保护是穿越环形的P2P传输路径部分的非常有效的实现。在环形拓扑中，转向应该是P2P保护的首选机制，因为它减少了流量通过包装保护翻倍时所需的额外带宽，它还提供了针对链路和节点故障进行保护的能力，而不会使故障检测复杂化，也不需要配置多个保护路径。虽然这是事实，但根据OAM功能（在[RFC6371]中概述并在各种文档中指定）和[RFC6378]中为线性保护指定的协调协议，可以支持包装或转向。
This document does not add any security risks to the network. Any security considerations are defined in [RFC6378], and their applicability to the information contained in this document follows naturally from the applicability of the mechanism defined in that document.
本文档不会给网络增加任何安全风险。[RFC6378]中定义了任何安全注意事项，其对本文件所含信息的适用性自然源于该文件中定义的机制的适用性。
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, October 2011.
[RFC6378]Y.Weingarten、S.Bryant、E.Osborne、N.Sprecher和A.Fulignoli，“MPLS传输模式（MPLS-TP）线性保护”，RFC 6378，2011年10月。
[G.841] ITU, "Types and characteristics of SDH network protection architectures", ITU-T G.841, October 1998.
[G.841]ITU，“SDH网络保护体系结构的类型和特征”，ITU-T G.841，1998年10月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Swallow，G.，和A.Atlas，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4427]Mannie，E.和D.Papadimitriou，“通用多协议标签交换（GMPLS）的恢复（保护和恢复）术语”，RFC 4427，2006年3月。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC5331]Aggarwal，R.，Rekhter，Y.，和E.Rosen，“MPLS上游标签分配和上下文特定标签空间”，RFC 53312008年8月。
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654]Niven Jenkins，B.，Brungard，D.，Betts，M.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月。
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921]Bocci，M.，Bryant，S.，Frost，D.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，RFC 59212010年7月。
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[RFC6371]Busi，I.和D.Allan，“基于MPLS的传输网络的运营、管理和维护框架”，RFC 6371，2011年9月。
[RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, September 2011.
[RFC6372]Sprecher，N.和A.Farrel，“MPLS传输配置文件（MPLS-TP）生存能力框架”，RFC 63722011年9月。
The authors would like to acknowledge the strong contributions from all the people who commented on this document and made suggestions for improvements.
作者要感谢所有对本文件发表评论并提出改进建议的人的大力贡献。
The authors would like to acknowledge the following individuals that contributed their insights and advice to this work:
作者要感谢以下个人，他们为这项工作提供了见解和建议：
Nurit Sprecher (NSN)
努里特·斯普雷彻（新南威尔士州）
Akira Sakurai (NEC)
樱井明（日本电气公司）
Rolf Winter (NEC)
罗尔夫冬季（NEC）
Eric Osborne (Cisco)
埃里克·奥斯本（思科）
Authors' Addresses
作者地址
Yaacov Weingarten 34 Hagefen St. Karnei Shomron, 4485500 Israel
Yaacov Weingarten 34 Hagefen St.Karnei Shomron，以色列4485500
Phone: EMail: wyaacov@gmail.com
电话：电邮：wyaacov@gmail.com
Stewart Bryant Cisco Systems 10 New Square, Bedfont Lakes Feltham, Middlesex, TW18 8HA UK
斯图尔特·布莱恩特·思科系统10新广场，贝德方特湖费尔瑟姆，米德尔塞克斯，TW18 8HA英国
EMail: stbryant@cisco.com
EMail: stbryant@cisco.com
Danielle Ceccarelli Ericsson Via A. Negrone 1/A Genova, Sestri Ponente Italy
Danielle Ceccarelli Ericsson Via A.Negrone 1/A Genova，意大利塞斯特里波南特
EMail: daniele.ceccarelli@ericsson.com
EMail: daniele.ceccarelli@ericsson.com
Diego Caviglia Ericsson Via A. Negrone 1/A Genova, Sestri Ponente Italy
Diego Caviglia Ericsson Via A.Negrone 1/A Genova，意大利塞斯特里波南特
EMail: diego.caviglia@ericsson.com
EMail: diego.caviglia@ericsson.com
Francesco Fondelli Ericsson Via A. Negrone 1/A Genova, Sestri Ponente Italy
弗朗西斯科·丰德利·爱立信途经A.内格罗内1/A热那亚，意大利塞斯特里·波南特
EMail: francesco.fondelli@ericsson.com
EMail: francesco.fondelli@ericsson.com
Marco Corsi Altran Via A. Negrone 1/A Genova, Sestri Ponente Italy
马可·科尔西·阿尔特兰途经A.内格罗内1/A热那亚，意大利塞斯特里·波南特
EMail: corsi.marco@gmail.com
EMail: corsi.marco@gmail.com
Bo Wu ZTE Corporation 4F, RD Building 2, Zijinghua Road Nanjing, Yuhuatai District P.R. China
中国南京市雨花台区紫荆华路2号路4楼博武中兴通讯有限公司
EMail: wu.bo@zte.com.cn
EMail: wu.bo@zte.com.cn
Xuehui Dai
戴学辉
EMail: xuehuiwfsy@gmail.com
EMail: xuehuiwfsy@gmail.com