[要約] 要約：RFC 6974は、MPLSトランスポートプロファイルがリングトポロジーに適用可能であることを示しています。 目的：このRFCの目的は、MPLSトランスポートプロファイルがリングトポロジーでの使用に適していることを明確にすることです。
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-TP）に対する、ローカルおよびエンドツーエンドの既存のMPLS保護メカニズムの適用性について説明します。このドキュメントでは、新しいメカニズムやプロトコルを提案していません。 MPLS-TP保護の要件、特にリングトポロジでの保護の要件については、「MPLSトランスポートプロファイルの要件」（RFC 5654）および「MPLSトランスポートプロファイル（MPLS-TP）存続可能性フレームワーク」（RFC 6372）で説明します。このドキュメントでは、RFC 6378で定義されている線形保護をリングトポロジに適用することにより、ほとんどの要件がどのように満たされるかについて説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
MPLSトランスポートプロファイル（MPLS-TP）は、インターネット技術標準化委員会（IETF）と国際電気通信連合電気通信標準化部門（ITU-T）の間の共同作業の一環として標準化されています。これらの仕様は、この共同作業から生成された要件に基づいています。
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.
これら2つの状況のいずれかで、次の異なるケースに対処する必要があります。
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. リングリンクの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. リングノードの1つが障害状態を引き起こしています。この状態は常に双方向の障害であり（構成が誤っていることはまれですが、これは単方向の障害として検出される可能性があります）、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]は、MPLS-TPラベルスイッチドパス（LSP）の任意の2つのラベルスイッチングルーター（LSR）間で定義できるサブパスメンテナンスエンティティ（SPME）構成を定義します。この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ラベルをトップラベルとするスタックを示し、2番目のラベルは、パケットを送信し続けるために出力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]に基づいて歴史的にリングトポロジに適用され、さまざまなフォーラムで提案されている2つの保護アーキテクチャメカニズム（「ラッピング」と「ステアリング」）があります。トポロジーリングネットワークの回復。以下のサブセクションでは、MPLSトランスポートネットワークに適用されるこれらの2つのメカニズムを調べます。
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 Fast Rerouteに似ており、バイパスまたは迂回トンネルのいずれかを使用します。 MPLSにFast Rerouteを適用すると、バイパストンネルと単一のラベルを使用してすべてのLSPをラップするか、各LSPに異なるラベルを使用して迂回トンネル経由で各LSPのトラフィックを障害リンクの周りにラップすることができます。
___ ######## ___ ######## ___
======>/LSR\********/LSR\***XX***/LSR\
\_B_/@@@@@@@@\_A_/ \_F_/
*@ #*@
*@ #*@
*@ #*@
_*@ ___ #*@
/LSR\********/LSR\********/LSR\======>
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
===> 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.
LSR-BでLSRのリングに入り、LSR-Eで終了する、図1に示されているLSPについて考えます。通常の現用パスLSPは、LSR B-A-F-Eを通過します。リンクA <-> Fで障害が検出された場合、ラッピングメカニズムは、LSR-AがラップされたデータパスABCDEFでリングの周りにトラフィックをラップし、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 検出された障害の2つの隣接ノード間を接続するために、リングの周りの代替パスを通過するデータパスを定義する必要があります。 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 ラップする場合、データは一部のリンクを介して2回、各方向に1回送信されます。たとえば、上の図では、トラフィックは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 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).
リング保護の2番目の一般的なスキームであるステアリングは、リングの入口ノードからリングの周りを反対方向に進む出口ポイントまでの2つのパスを定義することにより、リングトポロジを利用します。これを図2に示します。トラフィックがノードBからリングに入り、ノード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_/
===> 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]との類似点があります。リングの周囲の2つのパスは、現用パスと保護パスとして機能します。これには、入力ノードに保護パスに切り替える必要があることを通知し、入力ノードと出力ノードがスイッチオーバーを調整する必要があります。入力ノードと通信して、保護パスに切り替える必要があり、保護ドメインの2つのエンドポイント間の切り替えを調整する必要があります。
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 データパスに2倍の帯域幅は必要ありませんが、リングの周りの両方向のすべてのデータに対して十分な容量をリングが維持する必要があります。
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].
SPMEの概念は、トランスポートの任意のセグメントの管理と監視をサポートするために[RFC5921]によって導入されました。ただし、SPMEは基本的に有効なLSPであり、SPMEで指定されたサブパスを通過するすべてのLSPトラフィックを集約するために使用できます。 SPMEは、MPLS-TP OAMフレームワークドキュメント[RFC6371]で説明されているOAMメカニズムを使用して監視できます。
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の正確な選択は、実装されているトランスポートパスと保護のタイプによって異なります。これについては、以下のサブセクションで詳しく説明します。
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機能を実行するため、個々のLSPを監視するのではなく、リングのデータトラフィックを監視するために必要なOAMセッションの数を最小限に抑えることができます。
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に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]で到着するパケットには、SPMEラベルがLSR-Bにプッシュされ、LSPラベルは、出力LSR（つまり、パケットは[PA1（B）| LE]のラベルスタックでLSR-Aに到着し、[PE1（F）| LE]でLSR-Fに到着する）。 SPMEラベルはLSR-Fによってポップされ、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には2つのメンテナンスエンティティグループエンドポイント（MEP）があり、それぞれが双方向SPMEの1方向の入力および出力として機能します。 SPMEはリングを通過するため、リングの別の特性を利用できます。つまり、2つの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に対して、リングを介して2つのSPMEを構成することを示しています（最初のSPMEはB-A-Fを通過し、2番目のSPMEはB-C-D-E-Fを通過します）。
___ ___ ___
=====>/LSR\********/LSR\********/LSR\======>
\_B_/########\_A_/########\_F_/
*@ @*
*@ @*
*@ @*
_*@ ___ @*_
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
===> 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はすべてのLSPデータパケットを送信する保護SPMEを選択します。
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メカニズムを使用して、セグメントベースの保護を実行することが可能です。リング内の各リンクについて、2つのSPMEを定義します。最初のリンクは、リンクによって接続されている2つのLSR間のSPMEであり、2番目のSPMEは、同じ2つのLSRの間にありますが、リング全体を横断します（接続するリンクを除く） LSR）。図4では、LSR-AとLSR-Fをセグメント接続で接続するプライマリSPMEと、リングを逆方向にたどってこれらの同じLSRを接続するセカンダリSPMEを示しています。
___ ___ ___
/LSR\********/LSR\********/LSR\
\_B_/@@@@@@@@\_A_/########\_F_/
*@ *@
*@ *@
*@ *@
_*@ ___ _*@
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
*** 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.
これらの2つのSPMEのOAMモニタリングを（各LSRで）適用することにより、リングを通過する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. データパケットは、ラベルスタック[L1 + S]でLSR-Aに到着します（つまり、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]（つまり、LSMEのラベルを交換して、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]（つまり、LSR-Aは、下位レベルのLSPのラベルを交換した後、セカンダリSPMEのラベルをLSR-AからLSR-Fにプッシュします）。これは、LSR-Eがラベルスタックを使用してLSR-Fに転送するまで、セカンダリSPMEに沿って送信されます[PE2（F）| LSE + S]。
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は、保護されているノードに接続されている2つのLSR間に構成され（図5のLSR-AとLSR-E間のLSPを参照）、セカンダリSPMEは、これらの同じノード間でリングを構成します（図5のセカンダリSPMEを参照）。
___ ___ ___
/LSR\********/LSR\********/LSR\
\_B_/@@@@@@@@\_A_/########\_F_/
*@ *#
*@ *#
*@ *#
_*@ ___ _*#
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
*** 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にデータパケットをラップし、出力MEP（たとえば、図のLSR-E）でLSPの続きに折り返します。 SPME。
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に示すリングの構成に到達することができます。ここでは、3つの保護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_/
$$$$$$$$ $$$$$$$$
*** 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からリング内の他の各ノードへの2つの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.
ラッピングの場合：入力とラッピングノードの間、および2番目のラッピングノードと出力の間のリンクで帯域幅が2倍になります。
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で説明されているようにステアリングを使用することは、その単純さのために推奨される保護メカニズムです。この保護に関与するSPMEの数は、入力と出力のペアとして使用されていないLSRのペア間の各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}）と1つの可能なバックアップ（保護）LSPを特定できます。 （注：出力ノードは中括弧で示されます。）この保護LSPは、リンクB-Cの障害から保護するためにリングの周りにデータを折り返すために使用されます。この保護LSPは、壊れた現用データパスを補完する出口ノード（ノードF、D、およびC）で構成されたP2MP LSPでもあります。
|
|
V Ingress
___ _V_ ___
/LSR\ /LSR\**************/LSR\
<@@\_F_/@@@@@@@@@@@@@\_A_/@@@@@@@@@@@@@@\_B_/
@ * *
@ * *
@ * XXXX Failure
@ * *
@_* ___ __*
/LSR\*************/LSR\**************/LSR\
\_E_/@@@@@@@@@@@@@\_D_/@@@@@@@@@@@@@@\_C_/
@ @
@ @
V V
*** 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のバックアップ」は、ノードY（Xの下流ノード）またはリンクX-Yに影響を与える障害の結果としてノードXによってアクティブ化されるバックアップパスです。 （注：パスの波括弧は出力ノードを示します。）
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}
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.
このドキュメントの他のセクションで説明されているSPMEベースの保護メカニズムとは対照的に、ROMラッピングはLSPベースの保護メカニズムであることに注意してください。これは範囲が制限されているように見えるかもしれませんが、このメカニズムは、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:
2番目の側面は、トラフィックを適切に配信するために必要なホップ数です。図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
ROM-Wrapping:
ROMラッピング：
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.
ノードの2つのリストを比較すると、この特定のケースでは、基本的なラッピングが使用されている場合に通過するホップ数が、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は反時計回りに事前にプロビジョニングされており、それぞれに予約済み帯域幅Mがある場合があります。これらのLSPは、[RFC2205]で説明されているように、SE（Shared Explicit）スタイルで同じ帯域幅を共有します。
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.
2つの回復メカニズムには、異なる保護帯域幅が必要です。ラッピングの場合、使用される帯域幅は、多くのリンクで両方向で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).
図7に示すように、リンクBCで障害が検出された場合を考えてみます。次の表は、各リンクの帯域幅使用率（Mに等しい単位）を、各回復メカニズムおよび各方向（CW =時計回り、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 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.
たとえば、図7に示すリンクBCおよびCDに影響を与えるダブルリンク障害を考えてみます。Bは障害を検出すると、Cに到達するための代替パスがないため、ラッピングメカニズムは障害から回復できません。すべてのP2MPトラフィック失われます。 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]。リング上の各ノードから2つの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を介して送信され、それぞれに独自のコンテキストラベルと特定のLSPのコンテキスト固有のラベルが付いています。出力ノードは、稼働中のSPMEに到着するトラフィックを選択する必要があります。障害状態が特定された場合、出口ノードは、そのノードにトラフィックが到達する2つのSPMEのいずれかからトラフィックを選択する必要があります。つまり、2つのうちの1つ（おそらくは機能している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から構成された2つの単方向P2MP SPMEを示しており、リング上のすべてのノードに出力ポイントがあります。時計回りのSPME（つまり、A-B-C-D-E-F）は、LSR-Aでリングに入るP2MP LSPのすべてのトラフィックを集約し、リングノードの任意のサブセットでリングから送信する必要がある作業SPMEとして構成されます。反時計回りのSPME（つまり、A-F-E-D-C-B）は、保護SPMEとして構成されます。
^ ^ ^
_|_ _|_ _|_
----->/LSR\********/LSR\********/LSR\
\_A_/========\_B_/========\_C_/
+* <+++++++++*||
+* +*||
+* +*||
+* +*||
+*_ ++++++++ ___ +++++++++*||
/LSR\********/LSR\********/LSR\
\_F_/<=======\_E_/========\_D_/
| | |
V V V
---> 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ラベルをポップし、コンテキストラベルが示すLIBのスタックで次のラベルを検索します。
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保護では、2つのコンテキストLIBがあります。 1つは、動作中のSPMEのコンテキストLIBであり、もう1つは、保護SPMEのコンテキストLIBです。すべてのコンテキストLIBには、エンドツーエンド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に示すリングを使用すると、リング上の各ノードでCWのコンテキスト識別ラベルを持つように作業SPMEが構成され、CPのコンテキスト識別ラベルを持つように保護SPMEが構成されます。各ノード。特定の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)].
図8に示す2つのSPMEを使用して、LSR-Aでリングに入り、LSR-CとLSR-Eでリングからの出力ポイントを持つP2MP LSPに、上記のように1 + 1線形保護を適用するとします。ラベルスタック[LI + S]でLSR-Aに到着したパケットは、ラベルスタック[CW | WL（A-B）]。次に、パケットはラベルが付いたLSR-Cに転送されます[CW | WL（B-C）]、ここでWL（B-C）はフォワーディング機能に[LE（C）]を使用してパケットを出力し、ラベルスタックを使用してコピーをLSR-Dに転送する必要があります[CW | WL（C-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.
障害状態が検出された場合（たとえば、リンクCDで）、障害ポイントを超えているノード（この例では、ノードLSR-D、LSR-E、およびLSR-F）は、時計回り（動作中）のSPMEからのデータパケット。これらの各LSRは、「セレクタブリッジ」の切り替えを開始し、保護（反時計回り）SPMEからのデータパケットを受け入れます。入力ポイント（LSR-A）では、すべてのデータパケットが、動作中のSPMEと保護SPMEの両方で送信されています。例を続けると、LSR-Aはスタックを使用してデータの1つのコピーをLSR-Bに送信します[CW | WL（A-B）]およびスタック付きLSR-Fへの1つのコピー[CP | PL（A-F）]。パケットは、動作中のSPMEからLSR-Cに到着し、リングから出力されます。 LSR-Eはスタックを持つ保護SPMEからパケットを受信します[CP | PL（F-E）]、および状況依存ラベルPL（F-E）は、転送機能に、ラベルLE（E）のリングからコピーを送信し、スタック[CP | PL（E-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.
このアーキテクチャには、入力ノードが誤接続の存在を識別する必要がなく、出力ポイントから入力への戻りパスが不要であるという追加の利点があります。
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を参照すると、リングを通過し、LSR-Bでリングに入り、LSR-D、LSR-E、およびLSR-Hで分岐するP2MP LSPがあり、LSR-Hを超えて継続しません。保護の目的で、LSR-Bから始まるリング上に2つのP2MP単方向SPMEが構成されています。 SPMEの1つである現用SPMEは、各LSR-C、D、E、F、G、H、J、K、Aの出口ポイントで構成されます。2番目の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
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の構成を、それぞれの作業SPMEのコンテキスト識別ラベルとして想定します。リング内のLSRの数、および各LSRでの保護SPMEのコンテキスト識別ラベルとして400
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]} |
+------+-----------------------------+------------------------------+
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 |を使用して両方の作業SPMEにパケットを転送する必要があると判断します。 90]およびスタック付きの保護SPME [400 | 165]。 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に転送されます。 80]。このようにして、パケットは、コンテキストテーブルで構成された動作に従って、両方の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ステアリング-リングの入力ノードからリングの出力ノードまでの2つの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ラッピング-2つのSPMEの構成。1つは保護されたリンク用、もう1つは2つの隣接ノード間の長いルート用で、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ラッピング-2つのSPMEの構成。1つは保護ノードの2つのネイバー間で、もう1つは長いルートのこれら2つのノード間で、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の構成を組み合わせて、保護パスの状況依存ラベルに基づいて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トランスポートパスのセクションに対して非常に効率的な実装です。ステアリングは、ラップされた保護によってトラフィックが2倍になったときに必要な余分な帯域幅を減らし、障害検出を複雑にしたり、複数の保護を要求したりせずにリンクとノードの両方の障害から保護する機能を提供するため、リングトポロジーの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] Weingarten、Y.、Bryant、S.、Osborne、E.、Sprecher、N。、およびA. Fulignoli、「MPLS Transport Profile（MPLS-TP）Linear Protection」、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、「Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification」、RFC 2205、1997年9月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]パン、P。、スワロー、G。、およびA.アトラス、「LSPトンネル用のRSVP-TEへの高速リルート拡張」、RFC 4090、2005年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 5331、2008年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 5654、2009年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、「A Transport Framework in MPLS in MPLS」、RFC 5921、2010年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、「Operations、Administration、and Maintenance Framework for MPLS-Based Transport Networks」、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 Transport Profile（MPLS-TP）Survivability Framework」、RFC 6372、2011年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)
Nuritスポークスパーソン（NSN）
Akira Sakurai (NEC)
あきら さくらい （ねＣ）
Rolf Winter (NEC)
ロルフ・ウィンター（NEC）
Eric Osborne (Cisco)
エリックオズボーン（Cisco）
Authors' Addresses
著者のアドレス
Yaacov Weingarten 34 Hagefen St. Karnei Shomron, 4485500 Israel
Yaacov Weingarten 34 Hagefen St. Karnei Shomron、4485500 Israel
Phone: EMail: wyaacov@gmail.com
電話：メール：wyaacov@gmail.com
Stewart Bryant Cisco Systems 10 New Square, Bedfont Lakes Feltham, Middlesex, TW18 8HA UK
Stewart Bryant Cisco Systems 10 New Square、Bedfont Lakes Feltham、Middlesex、TW18 8HA UK
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 Diego Caviglia Ericsson Via A. Negrone 1/A Genova, Sestri Ponente Italy
メール：daniele.ceccarelli@ericsson.com Diego Caviglia Ericsson Via A. Negrone 1 / A Genoa、Sestri Ponente Italy
EMail: diego.caviglia@ericsson.com
Francesco Fondelli Ericsson Via A. Negrone 1/A Genova, Sestri Ponente Italy
フランチェスコフォンデリエリクソンVia A. Negrone 1 / Aジェノヴァ、セストリポネンテイタリア
EMail: francesco.fondelli@ericsson.com
Marco Corsi Altran Via A. Negrone 1/A Genova, Sestri Ponente Italy
マルココルシアルトランVia A. Negrone 1 / Aジェノヴァ、セストリポネンテイタリア
EMail: corsi.marco@gmail.com
Bo Wu ZTE Corporation 4F, RD Building 2, Zijinghua Road Nanjing, Yuhuatai District P.R. China
bow u ZT Eコーポレーション4F、RDビルディング2、Z iエッセンスロードNaN京、Y U Huatai地区P.R.中国
EMail: wu.bo@zte.com.cn
Xuehui Dai
X UEは愛する
EMail: xuehuiwfsy@gmail.com