[要約] RFC 8104は、Pseudowire（PW）エンドポイントの高速障害保護に関する標準化された手法を提供します。その目的は、PWのエンドポイントでの障害が発生した場合に、迅速かつ信頼性の高い障害回復を実現することです。
Internet Engineering Task Force (IETF) Y. Shen
Request for Comments: 8104 Juniper Networks
Category: Standards Track R. Aggarwal
ISSN: 2070-1721 Arktan, Inc.
W. Henderickx
Nokia
Y. Jiang
Huawei Technologies Co., Ltd.
March 2017
Pseudowire (PW) Endpoint Fast Failure Protection
疑似配線（PW）エンドポイントの高速障害保護
Abstract
概要
This document specifies a fast mechanism for protecting pseudowires (PWs) transported by IP/MPLS tunnels against egress endpoint failures, including egress attachment circuit (AC) failure, egress provider edge (PE) failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure. Operating on the basis of multihomed customer edge (CE), redundant PWs, upstream label assignment, and context-specific label switching, the mechanism enables local repair to be performed by the router upstream adjacent to a failure. The router can restore a PW in the order of tens of milliseconds, by rerouting traffic around the failure to a protector through a pre-established bypass tunnel. Therefore, the mechanism can be used to reduce traffic loss before global repair reacts to the failure and the network converges on the topology changes due to the failure.
このドキュメントでは、IP / MPLSトンネルによって転送される疑似配線（PW）を、出力接続回線（AC）障害、出力プロバイダーエッジ（PE）障害、マルチセグメントPW終端PE障害、マルチ-セグメントPWスイッチングPE障害。このメカニズムは、マルチホームのカスタマーエッジ（CE）、冗長PW、アップストリームラベル割り当て、およびコンテキスト固有のラベルスイッチングに基づいて動作し、障害に隣接するルーターアップストリームによってローカル修復を実行できます。ルーターは、障害の前後のトラフィックを事前に確立されたバイパストンネルを介してプロテクターに再ルーティングすることにより、数十ミリ秒のオーダーでPWを復元できます。したがって、このメカニズムを使用して、グローバル修復が障害に反応し、ネットワークが障害によるトポロジーの変更に収束する前に、トラフィックの損失を減らすことができます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8104.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8104で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Specification of Requirements . . . . . . . . . . . . . . . . 5
3. Reference Models for Egress Endpoint Failures . . . . . . . . 5
3.1. Single-Segment PW . . . . . . . . . . . . . . . . . . . . 6
3.2. Multi-Segment PW . . . . . . . . . . . . . . . . . . . . 9
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 10
4.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Local Repair . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Context Identifier . . . . . . . . . . . . . . . . . . . 14
4.3.1. Semantics . . . . . . . . . . . . . . . . . . . . . . 15
4.3.2. FEC . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.3. IGP Advertisement and Path Computation . . . . . . . 16
4.4. Protection Models . . . . . . . . . . . . . . . . . . . . 17
4.4.1. Co-located Protector . . . . . . . . . . . . . . . . 17
4.4.2. Centralized Protector . . . . . . . . . . . . . . . . 19
4.5. Transport Tunnel . . . . . . . . . . . . . . . . . . . . 20
4.6. Bypass Tunnel . . . . . . . . . . . . . . . . . . . . . . 21
4.7. Examples of Forwarding State . . . . . . . . . . . . . . 22
4.7.1. Co-located Protector Model . . . . . . . . . . . . . 22
4.7.2. Centralized Protector Model . . . . . . . . . . . . . 26
5. Restorative and Revertive Behaviors . . . . . . . . . . . . . 29
6. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 30
6.1. Egress Protection Capability TLV . . . . . . . . . . . . 31
6.2. PW Label Distribution from Primary PE to Protector . . . 32
6.3. PW Label Distribution from Backup PE to Protector . . . . 33
6.4. Protection FEC Element TLV . . . . . . . . . . . . . . . 34
6.4.1. Encoding Format for PWid with IPv4 PE Addresses . . . 35
6.4.2. Encoding Format for Generalized PWid with IPv4 PE
Addresses . . . . . . . . . . . . . . . . . . . . . . 36
6.4.3. Encoding Format for PWid with IPv6 PE Addresses . . . 37
6.4.4. Encoding Format for Generalized PWid with IPv6 PE
Addresses . . . . . . . . . . . . . . . . . . . . . . 38
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
8. Security Considerations . . . . . . . . . . . . . . . . . . . 40
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.1. Normative References . . . . . . . . . . . . . . . . . . 40
9.2. Informative References . . . . . . . . . . . . . . . . . 41
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
Per [RFC3985], [RFC8077], and [RFC5659], a pseudowire (PW) or PW segment can be thought of as a connection between a pair of forwarders hosted by two PEs, carrying an emulated Layer 2 service over a packet switched network (PSN). In the single-segment PW (SS-PW) case, a forwarder binds a PW to an attachment circuit (AC). In the multi-segment PW (MS-PW) case, a forwarder on a terminating PE (T-PE) binds a PW segment to an AC, while a forwarder on a switching PE (S-PE) binds one PW segment to another PW segment. In each direction between the PEs, PW packets are transported by a PSN tunnel, which is also called a transport tunnel.
[RFC3985]、[RFC8077]、および[RFC5659]によると、疑似配線（PW）またはPWセグメントは、2つのPEによってホストされ、パケット交換ネットワーク上でエミュレートされたレイヤー2サービスを伝送する1対のフォワーダー間の接続と考えることができます。 （PSN）。単一セグメントPW（SS-PW）の場合、フォワーダーはPWを接続回線（AC）にバインドします。マルチセグメントPW（MS-PW）の場合、終端PE（T-PE）のフォワーダーはPWセグメントをACにバインドし、スイッチングPE（S-PE）のフォワーダーは1つのPWセグメントを別のPWセグメントにバインドします。 PWセグメント。 PE間の各方向で、PWパケットはトランスポートトンネルとも呼ばれるPSNトンネルによってトランスポートされます。
In order to protect the PW service against network failures, it is necessary to protect every link and node along the entire data path. For the traffic in a given direction, this includes ingress AC, ingress (T-)PE, intermediate routers of the transport tunnel, S-PEs, egress (T-)PE, and egress AC. To minimize service disruption upon a failure, it is also desirable that each of these components is protected by a fast protection mechanism based on local repair. Such mechanisms generally involve a bypass path that is pre-computed and pre-installed in the data plane on the router upstream adjacent to an anticipated failure. This router is referred to as a "point of local repair" (PLR). The bypass path has the property that it can guide traffic around the failure, while remaining unaffected by the topology changes resulting from the failure. When the failure occurs, the PLR can invoke the bypass path to achieve fast restoration for the service.
PWサービスをネットワーク障害から保護するには、データパス全体に沿ってすべてのリンクとノードを保護する必要があります。特定の方向のトラフィックの場合、これには、入力AC、入力（T-）PE、トランスポートトンネルの中間ルーター、S-PE、出力（T-）PE、および出力ACが含まれます。障害発生時のサービスの中断を最小限に抑えるには、これらの各コンポーネントをローカルでの修復に基づく高速保護メカニズムで保護することも望まれます。このようなメカニズムには、通常、予測される障害に隣接するルーター上流のデータプレーンに事前に計算およびインストールされたバイパスパスが含まれます。このルーターは、「Point of Local Repair」（PLR）と呼ばれます。バイパスパスには、障害に起因するトポロジ変更の影響を受けずに、障害を迂回してトラフィックを誘導できるという特性があります。障害が発生すると、PLRはバイパスパスを呼び出して、サービスの高速復元を実現できます。
Today, fast protection against ingress AC failure and ingress (T-)PE failure can be achieved by using a multihomed CE and redundant ACs, such as a multi-chassis link aggregation group (MC-LAG). Fast protection against the failure of an intermediate router of the transport tunnel can be achieved through RSVP fast reroute [RFC4090] or IP/LDP fast reroute [RFC5286] [RFC5714]. However, there is no equivalent mechanism that can be used against an egress AC failure, an egress (T-)PE failure, or an S-PE failure. For these failures, service restoration has to rely on global repair or control-plane convergence. Global repair normally involves the ingress CE or the ingress (T-)PE switching traffic to an alternative path, based on remote failure detection via PW status notification, end-to-end Operations, Administration, and Maintenance (OAM), and others. Control-plane convergence relies on control protocols to react on the topology changes due to a failure. Compared to local repair, these mechanisms are relatively slow in reacting to a failure and restoring traffic.
今日、入力AC障害と入力（T-）PE障害に対する高速保護は、マルチシャーシリンクアグリゲーショングループ（MC-LAG）などのマルチホームCEと冗長ACを使用することで実現できます。トランスポートトンネルの中間ルーターの障害に対する高速保護は、RSVP高速リルート[RFC4090]またはIP / LDP高速リルート[RFC5286] [RFC5714]によって実現できます。ただし、出力AC障害、出力（T-）PE障害、またはS-PE障害に対して使用できる同等のメカニズムはありません。これらの障害の場合、サービスの復元は、グローバルな修復またはコントロールプレーンの収束に依存する必要があります。グローバルな修復には、通常、PWステータス通知によるリモート障害検出、エンドツーエンドの運用、管理、および保守（OAM）などに基づいて、代替パスへの入力CEまたは入力（T-）PEスイッチングトラフィックが含まれます。コントロールプレーンコンバージェンスは、障害によるトポロジーの変化に対応するために、制御プロトコルに依存しています。ローカル修復と比較して、これらのメカニズムは、障害への対応とトラフィックの復元が比較的低速です。
This document addresses the above need. It specifies a fast protection mechanism based on local repair to protect PWs against the following endpoint failures:
このドキュメントでは、上記のニーズに対処します。次のエンドポイント障害からPWを保護するために、ローカル修復に基づく高速保護メカニズムを指定します。
a. Egress AC failure.
a. 出力AC障害。
b. Egress PE failure: Link or node failure of an egress PE of an SS-PW or a T-PE of an MS-PW.
b. 出力PE障害：SS-PWの出力PEまたはMS-PWのT-PEのリンクまたはノードの障害。
c. Switching PE failure: Link or node failure of an S-PE of an MS-PW.
c. スイッチングPE障害：MS-PWのS-PEのリンクまたはノードの障害。
The mechanism is applicable to LDP-signaled PWs. It is relevant to networks with redundant PWs and multihomed CEs. It is designed on the basis of MPLS upstream label assignment and context-specific label switching [RFC5331]. Fast protection refers to its ability to restore traffic in the order of tens of milliseconds. Compared with global repair and control-plane convergence, this mechanism can provide faster service restoration. However, it is intended to complement these mechanisms, rather than replacing them, as networks rely on them to eventually move traffic to fully functional alternative paths.
このメカニズムは、LDPシグナリングPWに適用できます。これは、冗長PWおよびマルチホームCEを備えたネットワークに関連しています。 MPLSアップストリームラベル割り当てとコンテキスト固有のラベルスイッチング[RFC5331]に基づいて設計されています。高速保護とは、数十ミリ秒のオーダーでトラフィックを復元する機能を指します。このメカニズムは、グローバルな修理とコントロールプレーンの収束と比較して、より迅速なサービス復元を提供できます。ただし、ネットワークは最終的にトラフィックを完全に機能する代替パスに移動するためにこれらに依存しているため、これらのメカニズムを置き換えるのではなく、これらのメカニズムを補完することを目的としています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document refers to the following topologies to describe egress endpoint failures and protection procedures.
このドキュメントでは、次のトポロジを参照して、出力エンドポイントの障害と保護手順について説明します。
|<-------------- PW1 --------------->|
- PE1 -------------- P1 ---------------- PE2 -
/ \
/ \
CE1 CE2
\ /
\ /
- PE3 -------------- P2 ---------------- PE4 -
|<-------------- PW2 --------------->|
Figure 1
図1
In Figure 1, the IP/MPLS network consists of PE and P routers. It provides a PW service between CE1 and CE2. Each CE is multihomed via two ACs to two PEs. This forms two divergent paths between the CEs. The first path uses PW1 between PE1 and PE2, and the second path uses PW2 between PE3 and PE4. For clarity, the transport tunnels of the PWs and other links between the routers are not shown in this figure.
図1では、IP / MPLSネットワークはPEおよびPルーターで構成されています。 CE1とCE2の間にPWサービスを提供します。各CEは、2つのACを介して2つのPEにマルチホーム化されています。これにより、CE間に2つの分岐パスが形成されます。最初のパスはPE1とPE2の間のPW1を使用し、2番目のパスはPE3とPE4の間のPW2を使用します。わかりやすくするために、PWのトランスポートトンネルとルーター間のその他のリンクはこの図には示されていません。
In general, a CE may operate the ACs in two modes when sending traffic to the remote CE, i.e., active-standby mode and active-active mode.
一般に、CEは、リモートCEにトラフィックを送信するときに、ACを2つのモード、つまりアクティブ/スタンバイモードとアクティブ/アクティブモードで動作させることができます。
o In the active-standby mode, the CE chooses one AC as the active AC and the corresponding path as the active path, and it uses the other AC as the standby AC and the corresponding path as the standby path. The CE only sends traffic on the active AC as long as the active path is operational. The CE will only send traffic on the standby AC after it detects a failure of the active path. Note that the CE may receive traffic on the active or standby AC, depending on whether the remote CE chooses the same active path for the traffic of the reverse direction. In this document, even if both CEs choose the same active path, each CE should still anticipate receiving traffic on a standby AC, because the traffic may be redirected to the standby path by the fast protection mechanism.
o アクティブスタンバイモードでは、CEは1つのACをアクティブACとして選択し、対応するパスをアクティブパスとして選択し、もう1つのACをスタンバイACとして使用し、対応するパスをスタンバイパスとして使用します。 CEは、アクティブパスが動作している限り、アクティブACでのみトラフィックを送信します。 CEは、アクティブパスの障害を検出した後でのみ、スタンバイACにトラフィックを送信します。リモートCEが逆方向のトラフィックに同じアクティブパスを選択するかどうかに応じて、CEはアクティブまたはスタンバイACでトラフィックを受信する場合があることに注意してください。このドキュメントでは、両方のCEが同じアクティブパスを選択しても、トラフィックは高速保護メカニズムによってスタンバイパスにリダイレクトされる可能性があるため、各CEはスタンバイACでのトラフィックの受信を予測する必要があります。
o In the active-active mode, the CE treats both ACs and their corresponding paths as active and sends traffic on both ACs in a load-balancing fashion. In the reverse direction, the CE may receive traffic on both ACs.
o アクティブ-アクティブモードでは、CEはACと対応するパスの両方をアクティブとして扱い、ロードバランシング方式で両方のACにトラフィックを送信します。逆方向では、CEは両方のACでトラフィックを受信できます。
The above modes assume the traffic to be data traffic, which is not bound to a specific AC. This does not include control-protocol traffic between the CEs, when the CE-CE control-protocol sessions or adjacencies established on the two ACs are considered as distinct rather than having a primary and backup relationship. In general, a dual-homed CE should not make any explicit or implicit assumptions regarding the specific AC from which it receives packets from the remote CE.
上記のモードでは、トラフィックはデータトラフィックであると想定されており、特定のACにバインドされていません。 2つのACで確立されたCE-CE制御プロトコルセッションまたは隣接関係がプライマリとバックアップの関係ではなく別個のものと見なされる場合、これにはCE間の制御プロトコルトラフィックは含まれません。一般に、デュアルホームCEは、リモートCEからパケットを受信する特定のACに関して、明示的または暗黙的な想定を行わないでください。
For either mode, when considering the traffic flowing in a given direction over an active path, this document views the ACs, PEs, and PWs as serving primary or backup roles. In particular, the ACs, PEs, and PWs along this active path have primary roles, while those along the other path have backup roles. Note that in the active-active mode, each AC, PE, and PW on an active path has a primary role and also a backup role protecting the other path, which is also active.
どちらのモードでも、アクティブパスを介して特定の方向に流れるトラフィックを検討する場合、このドキュメントでは、AC、PE、およびPWがプライマリまたはバックアップの役割を果たしていると見なします。特に、このアクティブパスに沿ったAC、PE、およびPWにはプライマリロールがあり、他のパスに沿ったものにはバックアップロールがあります。アクティブ-アクティブモードでは、アクティブパス上の各AC、PE、およびPWにはプライマリロールと、アクティブである他のパスを保護するバックアップロールがあることに注意してください。
For Figure 1, the following roles are assumed for the traffic going from CE1 to CE2 via PW1.
図1では、CE1からPW1を介してCE2に向かうトラフィックに対して、次の役割が想定されています。
Primary ingress AC: CE1-PE1
プライマリ入力AC：CE1-PE1
Primary ingress PE: PE1
プライマリ入力PE：PE1
Primary PW: PW1
プライマリPO：PO1
Primary egress PE: PE2
プライマリ出力PE：PE2
Primary egress AC: PE2-CE2
プライマリ出力AC：PE2-CE2
Backup ingress AC: CE1-PE3
バックアップ入力AC：CE1-PE3
Backup ingress PE: PE3
バックアップPE入力：PE3
Backup PW: PW2
ビショップΠΩ：ΠΩ2
Backup egress PE: PE4
バックアップ出力PE：PE4
Backup egress AC: PE4-CE2
バックアップ出力AC：PE4-CE2
Based on this schema, this document describes egress endpoint failures and the fast protection mechanism on the per-active-path and per-direction basis. In this case, an egress AC failure refers to the failure of the AC PE2-CE2, and an egress node failure refers to the failure of PE2. The ultimate goal is that when a failure occurs, the traffic should be locally repaired, so that it can eventually reach CE2 via the backup egress PE (PE4) and the backup egress AC (PE4-CE2).
このドキュメントでは、このスキーマに基づいて、出力エンドポイントの障害と、アクティブパスごとおよび方向ごとの高速保護メカニズムについて説明します。この場合、出力AC障害はAC PE2-CE2の障害を指し、出力ノード障害はPE2の障害を指します。最終的な目標は、障害が発生したときにトラフィックをローカルで修復し、最終的にバックアップ出力PE（PE4）とバックアップ出力AC（PE4-CE2）を介してCE2に到達できるようにすることです。
Subsequent to the local repair, either the current active path should heal after the control plane converges on the new topology or the ingress CE should switch traffic from the primary path to the backup path, depending on the failure scenario. In the latter case, the ingress CE may perform the path switchover triggered by end-to-end OAM (in-band or out-band), PW status notification, CE-PE control protocols (e.g., the Link Aggregation Control Protocol (LACP)), and others. In the active-standby mode, this will promote the standby path to a new active path. In the active-active mode, it will make the other active path carry all the traffic between the two CEs. In any case, this phase of restoration falls into the control-plane convergence and global repair category; hence, it is out of the scope of this document. The purpose of the fast protection mechanism in this document is to reduce traffic loss before this phase of restoration takes place.
ローカルの修復後、障害シナリオに応じて、コントロールプレーンが新しいトポロジに収束した後に現在のアクティブパスが回復するか、入力CEがトラフィックをプライマリパスからバックアップパスに切り替える必要があります。後者の場合、入口CEは、エンドツーエンドOAM（インバンドまたはアウトバンド）、PWステータス通知、CE-PE制御プロトコル（例：Link Aggregation Control Protocol（LACP ））、 その他。アクティブスタンバイモードでは、これによりスタンバイパスが新しいアクティブパスに昇格します。アクティブ-アクティブモードでは、他のアクティブパスに2つのCE間のすべてのトラフィックを伝送させます。いずれにしても、この復元フェーズは、コントロールプレーンの収束とグローバルな修復のカテゴリに分類されます。したがって、このドキュメントの範囲外です。このドキュメントの高速保護メカニズムの目的は、この復元フェーズが行われる前にトラフィックの損失を減らすことです。
Note that in Figure 1, if the traffic in the reverse direction (i.e., from CE2 to CE1) traverses the AC CE2-PE2 and PE2 as an active path, the failure of PE2 and the failure of the AC PE2-CE2 will be considered as ingress failures of the traffic. If CE2 can detect the failures, it may protect the traffic by switching it to the backup path via the AC CE2-PE4 and PE4. However, this is categorized as ingress endpoint failure protection; hence, it is not handled by the mechanism described in this document.
図1では、逆方向（つまり、CE2からCE1へ）のトラフィックがAC CE2-PE2およびPE2をアクティブパスとして通過する場合、PE2の障害とAC PE2-CE2の障害が考慮されることに注意してください。トラフィックの入力障害として。 CE2が障害を検出できる場合、AC CE2-PE4およびPE4を介してバックアップパスに切り替えることにより、トラフィックを保護できます。ただし、これは入力エンドポイント障害保護として分類されます。したがって、このドキュメントで説明されているメカニズムでは処理されません。
Figure 2 shows another possible scenario, where CE1 is single-homed to PE1, while CE2 remains multihomed to PE2 and PE4. From the perspective of egress endpoint protection for the traffic going from CE1 to CE2 over PW1, this scenario is the same as the scenario shown in Figure 1.
図2は、CE1がPE1にシングルホーム接続されている一方で、CE2がPE2とPE4にマルチホーム接続されている、別の可能なシナリオを示しています。 PW1を介してCE1からCE2に向かうトラフィックの出力エンドポイント保護の観点から、このシナリオは図1に示すシナリオと同じです。
|<-------------- PW1 --------------->|
------------- P1 ---------------- PE2 -
/ \
/ \
CE1 -- PE1 CE2
\ /
\ /
------------- P2 ---------------- PE4 -
|<-------------- PW2 --------------->|
Figure 2
図2
For clarity, primary egress AC, primary egress PE, backup egress AC, and backup egress PE may simply be referred to as primary AC, primary PE, backup AC, and backup PE, respectively, when the context of a discussion is egress endpoint.
明確にするために、議論のコンテキストが出力エンドポイントである場合、プライマリ出力AC、プライマリ出力PE、バックアップ出力AC、およびバックアップ出力PEは、それぞれ単にプライマリAC、プライマリPE、バックアップAC、およびバックアップPEと呼ばれることがあります。
|<--------------- PW1 --------------->|
|<----- SEG1 ----->|<----- SEG2 ----->|
- TPE1 -------------- SPE1 --------------- TPE2 -
/ \
/ \
CE1 CE2
\ /
\ /
- TPE3 -------------- SPE2 --------------- TPE4 -
|<----- SEG3 ----->|<----- SEG4 ----->|
|<--------------- PW2 --------------->|
Figure 3
図3
Figure 3 shows a topology that is similar to Figure 1 but in an MS-PW environment. PW1 and PW2 are both MS-PWs. PW1 is established between TPE1 and TPE2 and switched between segments SEG1 and SEG2 at SPE1. PW2 is established between TPE3 and TPE4 and switched between segments SEG3 and SEG4 at SPE2. CE1 is multihomed to TPE1 and TPE3. CE2 is multihomed to TPE2 and TPE4. For clarity, the transport tunnels of the PW segments are not shown in this figure.
図3は、図1と同様のトポロジを示していますが、MS-PW環境にあります。 PW1とPW2はどちらもMS-PWです。 PW1はTPE1とTPE2の間で確立され、SPE1でセグメントSEG1とSEG2の間で切り替えられます。 PW2はTPE3とTPE4の間で確立され、SPE2でセグメントSEG3とSEG4の間で切り替えられます。 CE1はTPE1およびTPE3にマルチホーム化されています。 CE2はTPE2およびTPE4にマルチホーム化されています。明確にするために、PWセグメントのトランスポートトンネルはこの図には示されていません。
In this document, the following primary and backup roles are assigned for the traffic going from CE1 to CE2:
このドキュメントでは、CE1からCE2に向かうトラフィックに次のプライマリロールとバックアップロールが割り当てられています。
Primary ingress AC: CE1-TPE1
プライマリ入力AC：CE1-TPE1
Primary ingress T-PE: TPE1
プライマリ入力T-PE：TPE1
Primary PW: PW1
プライマリPO：PO1
Primary S-PE: SPE1
プライマリS-PE：SPE1
Primary egress T-PE: TPE2
プライマリ出力T-PE：TPE2
Primary egress AC: TPE2-CE2
プライマリ出力AC：TPE2-CE2
Backup ingress AC: CE1-TPE3 Backup ingress T-PE: TPE3
バックアップ入力AC：CE1-TPE3バックアップ入力T-PE：TPE3
Backup PW: PW2
ΒασκοπΠΩ：ΠΩ2
Backup S-PE: SPE2
S-PEバックアップ：SPE2
Backup egress T-PE: TPE4
バックアップ出力T-PE：TPE4
Backup egress AC: TPE4-CE2
バックアップ出力AC：TPE4-CE2
In this case, an egress AC failure refers to the failure of the AC TPE2-CE2. An egress node failure refers to the failure of TPE2. An S-PE failure refers to the failure of SPE1.
この場合、出力AC障害とは、AC TPE2-CE2の障害を指します。出力ノードの障害とは、TPE2の障害を指します。 S-PE障害とは、SPE1の障害を指します。
For consistency with the SS-PW scenario, primary T-PEs and primary S-PEs may simply be referred to as primary PEs in this document, where specifics are not required. Similarly, backup T-PEs and backup S-PEs may be referred to as backup PEs.
SS-PWシナリオとの一貫性を保つため、このドキュメントでは、プライマリT-PEとプライマリS-PEを単にプライマリPEと呼ぶ場合がありますが、詳細は必要ありません。同様に、バックアップT-PEおよびバックアップS-PEは、バックアップPEと呼ばれることがあります。
The fast protection mechanism in this document provides three types of protection for PWs, corresponding to the three types of failures described in Section 1:
このドキュメントの高速保護メカニズムは、セクション1で説明した3種類の障害に対応する3種類のPWの保護を提供します。
a. Egress AC protection
a. 出力AC保護
b. Egress (T-)PE node protection
b. 出力（T-）PEノード保護
c. S-PE node protection
c. Ｓーぺ ので ｐろてｃちおん
The mechanism is applicable to LDP-signaled PWs in an environment where an egress CE is multihomed to a primary PE and a backup PE and there exists a backup PW, as described in Section 3. The procedure for S-PE node protection is applicable when there exists a backup S-PE on the backup PW.
このメカニズムは、セクション3で説明されているように、出力CEがプライマリPEとバックアップPEにマルチホーム化され、バックアップPWが存在する環境のLDPシグナリングPWに適用できます。S-PEノード保護の手順は、バックアップPWにバックアップS-PEが存在します。
The mechanism assumes IP/MPLS transport tunnels and is applicable to tunnels with single path and equal-cost multipaths (ECMPs). As an example of ECMPs, imagine a tunnel carrying one or multiple PWs and traversing a router with ECMPs to a primary PE. The ECMPs consist of at least one direct link to the PE and some multi-hop paths to the PE. Due to the direct link, the router is considered as a penultimate hop of the tunnel and can perform local detection and repair for an egress node failure. The router normally uses a hashing algorithm to distribute PW packets over the ECMPs, on a per-PW or per-flow basis. Upon a failure of the direct link, i.e., transit link failure, the router removes the link from the hashing algorithm, which automatically redistributes the traffic of the link to the other paths of the ECMPs, achieving local repair. This scenario is not the focus of this document. Upon a failure of the PE, i.e., egress node failure, the router SHOULD perform local repair by rerouting the entire traffic of the ECMPs, as the failure will affect every path. If the router does not have a fast or reliable mechanism to detect the egress node failure, it is RECOMMENDED that the router SHOULD treat the failure of the direct link as an egress node failure.
このメカニズムは、IP / MPLSトランスポートトンネルを想定しており、単一パスおよび等価コストマルチパス（ECMP）を使用するトンネルに適用できます。 ECMPの例として、1つまたは複数のPWを伝送し、ECMPを使用してプライマリPEまでルーターを通過するトンネルを想像してください。 ECMPは、PEへの少なくとも1つの直接リンクと、PEへのいくつかのマルチホップパスで構成されます。直接リンクにより、ルーターはトンネルの最後から2番目のホップと見なされ、出力ノードの障害に対してローカル検出と修復を実行できます。ルータは通常、ハッシュアルゴリズムを使用して、PWごとまたはフローごとに、ECMPを介してPWパケットを配信します。ダイレクトリンクの障害、つまりトランジットリンクの障害が発生すると、ルータはハッシュアルゴリズムからリンクを削除します。これにより、リンクのトラフィックがECMPの他のパスに自動的に再分散され、ローカルで修復されます。このシナリオは、このドキュメントの焦点ではありません。障害がすべてのパスに影響を与えるため、PEの障害、つまり出口ノードの障害時には、ルーターはECMPのトラフィック全体を再ルーティングすることによりローカル修復を実行する必要があります（SHOULD）。ルータに出力ノードの障害を検出するための高速または信頼性の高いメカニズムがない場合、ルータはダイレクトリンクの障害を出力ノードの障害として処理する必要があります（SHOULD）。
The mechanism is applicable to both best-effort and traffic engineering (TE) transport tunnels. For TE transport tunnels that require bandwidth protection, TE bypass tunnels with reserved bandwidth MAY be used to avoid congestion for rerouted traffic.
このメカニズムは、ベストエフォートとトラフィックエンジニアリング（TE）の両方のトランスポートトンネルに適用できます。帯域幅保護を必要とするTEトランスポートトンネルの場合、予約済みの帯域幅を持つTEバイパストンネルを使用して、再ルーティングされたトラフィックの輻輳を回避できます。
It is also RECOMMENDED that the mechanism SHOULD be used in conjunction with global repair and control-plane convergence, in such a manner that the mechanism temporarily repairs a failed path by using a bypass tunnel, and global repair and control-plane convergence eventually move traffic to a fully functional alternative path.
このメカニズムは、バイパストンネルを使用してメカニズムが一時的に障害のあるパスを修復し、グローバルな修復とコントロールプレーンの収束によって最終的にトラフィックが移動するように、グローバルな修復とコントロールプレーンの収束と組み合わせて使用する必要があります（SHOULD）。完全に機能する代替パスに。
The fast protection ability of the mechanism comes from local repair performed by routers upstream adjacent to failures. Each of these routers is referred to as a PLR. A PLR MUST be able to detect a failure by using a rapid mechanism, such as physical-layer failure detection, Bidirectional Forwarding Detection (BFD) [RFC5880], Seamless BFD (S-BFD) [RFC7880], and others. In anticipation of the failure, the PLR MUST also pre-establish a bypass tunnel to a "protector" and pre-install a bypass route for the bypass tunnel in the data plane. The protector is either a backup PE or a router that will forward traffic to a backup PE. The bypass tunnel MUST have the property that it will not be affected by the topology changes due to the failure. Specifically, it MUST NOT traverse the primary PE or the penultimate link of the protected transport tunnel or share any shared risk link groups (SRLGs) with the penultimate link. Upon detecting the failure, the PLR invokes the bypass route in the data plane and reroutes PW traffic to the protector through the bypass tunnel. The protector in turn sends the traffic to the target CE. This procedure is referred to as local repair.
このメカニズムの高速保護機能は、障害に隣接する上流のルーターによって実行されるローカル修復に起因しています。これらの各ルーターはPLRと呼ばれます。 PLRは、物理層障害検出、双方向転送検出（BFD）[RFC5880]、シームレスBFD（S-BFD）[RFC7880]などの迅速なメカニズムを使用して障害を検出できる必要があります。障害を見越して、PLRは「プロテクター」へのバイパストンネルを事前に確立し、データプレーンにバイパストンネル用のバイパスルートを事前にインストールする必要があります。プロテクターは、バックアップPE、またはトラフィックをバックアップPEに転送するルーターです。バイパストンネルには、障害によるトポロジ変更の影響を受けないという特性が必要です。具体的には、プライマリPEまたは保護されたトランスポートトンネルの最後から2番目のリンクを通過したり、共有リスクリンクグループ（SRLG）を最後から2番目のリンクと共有してはなりません。障害を検出すると、PLRはデータプレーンのバイパスルートを呼び出し、バイパストンネルを介してPWトラフィックをプロテクターに再ルーティングします。次に、プロテクターはトラフィックをターゲットCEに送信します。この手順は、ローカル修復と呼ばれます。
Different routers may serve as PLR and protector in different scenarios.
異なるルーターが異なるシナリオでPLRおよびプロテクターとして機能する場合があります。
o In egress AC protection, the PLR is the primary PE, and the protector is the backup PE (Figure 4).
o 出力AC保護では、PLRはプライマリPEであり、プロテクターはバックアップPEです（図4）。
|<-------------- PW1 --------------->|
- PE1 -------------- P1 ---------------- PE2 -
/ PLR \
/ | \
CE1 bypass| CE2
\ | /
\ | /
- PE3 -------------- P2 ---------------- PE4 -
protector
|<-------------- PW2 --------------->|
Figure 4
図4
o In egress PE node protection, the PLR is the penultimate hop router of the transport tunnel of the primary PW, and the protector is the backup PE (Figure 5).
o 出力PEノード保護では、PLRはプライマリPWのトランスポートトンネルの最後から2番目のホップルーターであり、プロテクターはバックアップPEです（図5）。
|<-------------- PW1 --------------->|
- PE1 -------------- P1 ------- P3 ----- PE2 -
/ PLR \ \
/ \ \
CE1 bypass\ CE2
\ \ /
\ \ /
- PE3 -------------- P2 ---------------- PE4 -
protector
|<-------------- PW2 --------------->|
Figure 5
図5
o In S-PE node protection, the PLR is the penultimate hop router of the transport tunnel of the primary PW segment, and the protector is the backup S-PE (Figure 6).
o S-PEノード保護では、PLRはプライマリPWセグメントのトランスポートトンネルの最後から2番目のホップルーターであり、プロテクターはバックアップS-PEです（図6）。
|<--------------- PW1 --------------->|
|<----- SEG1 ----->|<----- SEG2 ----->|
- TPE1 ----- P1 ----- SPE1 -------------- TPE2 -
/ PLR \ \
/ \ \
CE1 bypass\ CE2
\ \ /
\ \ /
- TPE3 --------------- SPE2 -------------- TPE4 -
protector
|<----- SEG3 ----->|<----- SEG4 ----->|
|<--------------- PW2 --------------->|
Figure 6
図6
In egress AC protection, a PLR realizes its role based on configuration of a "context identifier", which is introduced in this document (Section 4.3). The PLR establishes a bypass tunnel to the protector in the same fashion as a normal PSN tunnel.
出力AC保護では、PLRは、このドキュメント（セクション4.3）で紹介されている「コンテキスト識別子」の構成に基づいてその役割を実現します。 PLRは、通常のPSNトンネルと同じ方法でプロテクターへのバイパストンネルを確立します。
In egress PE and S-PE node protection, a PLR is a transit router on the transport tunnel, and it normally does not have knowledge of the PW(s) carried by the transport tunnel. In this document, the PLR simply computes and establishes a node-protection bypass tunnel in the same fashion as the normal IP/MPLS node protection, except that with the notion of the context identifier, the bypass tunnel will be established from the PLR to the protector (Section 4.6). Conversely, when the router is no longer a PLR for egress PE or S-PE node protection due to a change in network topology or the transport tunnel's path, the router should revert to the role of regular transit router, including PLR for transit link and node protection.
出力PEおよびS-PEノード保護では、PLRはトランスポートトンネル上の中継ルーターであり、通常、トランスポートトンネルによって伝送されるPWを認識していません。このドキュメントでは、PLRは通常のIP / MPLSノード保護と同じ方法でノード保護バイパストンネルを単純に計算して確立します。ただし、コンテキスト識別子の概念では、PLRからプロテクター（セクション4.6）。逆に、ネットワークトポロジまたはトランスポートトンネルのパスの変更により、ルーターが出力PEまたはS-PEノード保護のPLRでなくなった場合、ルーターは通常のトランジットルーターの役割に戻ります。ノード保護。
In local repair, a PLR simply switches all the traffic received on the transport tunnel to the bypass tunnel. This requires that the protector given by the bypass tunnel MUST be intended for all the PWs carried by the transport tunnel. This is achieved by the ingress PE using a context identifier to associate a PW with the specific pair of {primary PE, protector} and map the PW to a transport tunnel destined for the same {primary PE, protector}. The ingress PE MAY map multiple PWs to the transport tunnel, if they share the {primary PE, protector} in common.
ローカル修復では、PLRはトランスポートトンネルで受信したすべてのトラフィックをバイパストンネルに切り替えるだけです。これには、バイパストンネルによって提供されるプロテクターが、トランスポートトンネルによって運ばれるすべてのPWを対象としている必要があります。これは、コンテキストIDを使用してPWを{プライマリPE、プロテクター}の特定のペアに関連付け、同じ{プライマリPE、プロテクター}を宛先とするトランスポートトンネルにPWをマッピングする入力PEによって実現されます。入力PEは、{プライマリPE、プロテクター}を共通で共有している場合、複数のPWをトランスポートトンネルにマップしてもよい（MAY）。
In local repair, the PLR keeps the PW label intact in packets. This obviates the need for the PLR to maintain bypass routes on a per-PW basis and allows bypass tunnel sharing between PWs. On the other hand, this imposes a requirement on the protector that it MUST be able to forward the packets based on a PW label that is assigned by the primary PE and ensure that the traffic MUST reach the target CE via a backup path. From the protector's perspective, this PW label is an upstream assigned label [RFC5331]. To achieve this, the protector MUST learn the PW label from the primary PE prior to the failure and install a proper forwarding state for the PW label in a dedicated label space associated with the primary PE. During local repair, the protector MUST perform PW label lookup in this label space.
ローカル修復では、PLRはPWラベルをパケットにそのまま保持します。これにより、PLRがPWごとにバイパスルートを維持する必要がなくなり、PW間のバイパストンネル共有が可能になります。一方、プライマリPEによって割り当てられたPWラベルに基づいてパケットを転送し、トラフィックがバックアップパスを介してターゲットCEに到達することを保証する必要があることをプロテクターに要求します。保護者の観点から見ると、このPWラベルは上流に割り当てられたラベル[RFC5331]です。これを達成するには、プロテクターは障害の前にプライマリPEからPWラベルを学習し、プライマリPEに関連付けられた専用ラベルスペースにPWラベルの適切な転送状態をインストールする必要があります。ローカル修復中、プロテクターはこのラベルスペースでPWラベルルックアップを実行する必要があります。
The previous examples have shown the scenarios where the protectors are backup (T-/S-)PEs. It is also possible that a protector is a dedicated router to serve such a role, separate from the backup (T-/S-)PE. During local repair, the PLR still reroutes traffic to the protector through a bypass tunnel. The protector then forwards the traffic to the backup (T-/S-)PE, which further forwards the traffic to the target CE via a backup AC or a backup PW segment. More detail is included in Section 4.4.
前の例では、プロテクターがバックアップ（T- / S-）PEであるシナリオを示しました。プロテクターがバックアップ（T- / S-）PEとは別に、そのような役割を果たす専用ルーターである可能性もあります。ローカル修復中、PLRはバイパストンネルを介してトラフィックをプロテクターに再ルーティングします。次に、プロテクターはトラフィックをバックアップ（T- / S-）PEに転送し、さらにバックアップACまたはバックアップPWセグメントを介してトラフィックをターゲットCEに転送します。詳細はセクション4.4に記載されています。
A protector may protect multiple primary PEs. The protector MUST maintain a separate label space for each primary PE. Likewise, the PWs terminated on a primary PE may be protected by multiple protectors, each for a subset of the PWs. In any case, a given PW MUST be associated with one and only one pair of {primary PE, protector}.
プロテクターは複数のプライマリPEを保護できます。プロテクターは、各プライマリPEの個別のラベルスペースを維持する必要があります。同様に、プライマリPEで終端されたPWは、それぞれがPWのサブセットに対して複数のプロテクターによって保護される場合があります。いずれの場合も、特定のPWは、{プライマリPE、プロテクター}の1つのペアのみと関連付けられている必要があります。
This document introduces the notion of a context identifier to facilitate protection establishment. A context identifier is an IPv4/v6 address assigned to each ordered pair of {primary PE, protector}. The address MUST be globally unique or unique in the address space of the network where the primary PE and the protector reside.
このドキュメントでは、保護の確立を容易にするためのコンテキスト識別子の概念を紹介します。コンテキスト識別子は、{プライマリPE、プロテクター}の順序付けられた各ペアに割り当てられるIPv4 / v6アドレスです。アドレスは、グローバルに一意であるか、プライマリPEおよびプロテクターが存在するネットワークのアドレス空間で一意である必要があります。
The semantics of a context identifier is twofold:
コンテキスト識別子のセマンティクスは2つあります。
o A context identifier identifies a primary PE and an associated protector. It represents the primary PE as the PW destination on a per-protector basis. A given primary PE may be protected by multiple protectors, each for a subset of the PWs terminated on the primary PE. A distinct context identifier MUST be assigned to each {primary PE, protector} pair.
o コンテキスト識別子は、プライマリPEおよび関連するプロテクターを識別します。プロテクターごとにPW宛先としてのプライマリPEを表します。特定のプライマリPEは、複数のプロテクターで保護できます。各プロテクターは、プライマリPEで終端されたPWのサブセット用です。各{プライマリPE、プロテクター}ペアには、個別のコンテキスト識別子を割り当てる必要があります。
The ingress PE of a PW learns the context identifier of the PW's {primary PE, protector} from the primary PE via the Interface_ID TLV [RFC3471] [RFC3472] in the LDP Label Mapping message of the PW. The ingress PE then sets up or resolves a transport tunnel with the context identifier, rather than a private IP address of the primary PE, as the destination. This destination not only makes the transport tunnel reach the primary PE but also conveys the identity of the protector to the PLR, which MUST use the context identifier as the destination for the bypass tunnel to the protector. The ingress PE MUST map only the PWs terminated by the exact primary PE and protected by the exact protector to the transport tunnel.
PWの入力PEは、PWのLDPラベルマッピングメッセージのInterface_ID TLV [RFC3471] [RFC3472]を介して、プライマリPEからPWの{プライマリPE、プロテクター}のコンテキスト識別子を学習します。次に、入力PEは、プライマリPEのプライベートIPアドレスではなく、コンテキスト識別子を宛先としてトランスポートトンネルをセットアップまたは解決します。この宛先は、トランスポートトンネルをプライマリPEに到達させるだけでなく、プロテクターのIDをPLRに伝達します。PLRは、コンテキスト識別子をプロテクターへのバイパストンネルの宛先として使用する必要があります。入力PEは、正確なプライマリPEによって終了し、正確なプロテクターによって保護されたPWのみをトランスポートトンネルにマップする必要があります。
o A context identifier indicates the primary PE's label space on the protector. The protector may protect PWs for multiple primary PEs. For each primary PE, it MUST maintain a separate label space to store the PW labels assigned by that primary PE. It associates a PW label with a label space via the context identifier of the {primary PE, protector}, as below.
o コンテキスト識別子は、プロテクター上のプライマリPEのラベルスペースを示します。プロテクターは、複数のプライマリPEのPWを保護できます。プライマリPEごとに、そのプライマリPEによって割り当てられたPWラベルを格納するための個別のラベルスペースを維持する必要があります。以下のように、{プライマリPE、プロテクター}のコンテキスト識別子を介して、PWラベルをラベルスペースに関連付けます。
In addition to the normal LDP PW signaling, the primary PE MUST have a targeted LDP session with the protector and advertise PW labels to the protector via LDP Label Mapping messages (Section 6). The primary PE MUST attach the context identifier to each message. Upon receiving the message, the protector MUST install the advertised PW label in the label space identified by the context identifier.
通常のLDP PWシグナリングに加えて、プライマリPEはプロテクターとのターゲットLDPセッションを持ち、LDPラベルマッピングメッセージを介してPWラベルをプロテクターにアドバタイズしなければなりません（セクション6）。プライマリPEは、各メッセージにコンテキスト識別子を添付する必要があります。メッセージを受信すると、プロテクターは、コンテキスト識別子で識別されるラベルスペースにアドバタイズされたPWラベルをインストールする必要があります。
When a PLR sets up or resolves a bypass tunnel to the protector, it MUST use the context identifier rather than a private IP address of the protector as the destination. The protector MUST use the bypass tunnel, either the MPLS tunnel label or the IP tunnel destination address, as the pointer to the corresponding label space. The protector MUST forward PW packets received on the bypass tunnel based on label lookup in that label space.
PLRがプロテクターへのバイパストンネルをセットアップまたは解決するとき、宛先として、プロテクターのプライベートIPアドレスではなく、コンテキスト識別子を使用する必要があります。プロテクターは、対応するラベルスペースへのポインターとして、MPLSトンネルラベルまたはIPトンネル宛先アドレスのいずれかのバイパストンネルを使用する必要があります。プロテクターは、そのラベルスペースでのラベルルックアップに基づいて、バイパストンネルで受信したPWパケットを転送する必要があります。
In an MPLS network, a context identifier represents a Forwarding Equivalence Class (FEC) for transport tunnels and bypass tunnels destined for it. For example, it may be encoded in an LDP Prefix FEC Element or in the "tunnel endpoint address" of an RSVP Session object. The FEC is associated with a unique forwarding state on PLRs and the protector, which cannot be shared with other FECs. Some MPLS protocols (e.g., LDP) support FEC aggregation [RFC3031]. In this case, FEC aggregation MUST NOT be applied to a context identifier's FEC, and every router MUST assign a unique label to the FEC.
MPLSネットワークでは、コンテキスト識別子は、トランスポートトンネルとそれを宛先とするバイパストンネルの転送等価クラス（FEC）を表します。たとえば、LDPプレフィックスFEC要素またはRSVPセッションオブジェクトの「トンネルエンドポイントアドレス」にエンコードされる場合があります。 FECは、他のFECと共有できないPLRおよびプロテクターの一意の転送状態に関連付けられています。一部のMPLSプロトコル（LDPなど）はFEC集約をサポートしています[RFC3031]。この場合、FEC集約はコンテキスト識別子のFECに適用してはならず（MUST NOT）、すべてのルーターはFECに一意のラベルを割り当てなければなりません（MUST）。
Using a context identifier as the destination for both the transport tunnel and bypass tunnel requires coordination between the primary PE and the protector in IGP advertisement of the context identifier in the routing domain and TE domain. The context identifier should be advertised in such a way that all the routers on the tunnels MUST be able to independently reach the following common view of paths:
トランスポートトンネルとバイパストンネルの両方の宛先としてコンテキスト識別子を使用するには、ルーティングドメインとTEドメインのコンテキスト識別子のIGPアドバタイズメントでプライマリPEとプロテクターの間の調整が必要です。コンテキスト識別子は、トンネル上のすべてのルーターが次のパスの共通ビューに個別に到達できなければならないような方法でアドバタイズされる必要があります。
o The transport tunnel MUST have the primary PE as the path endpoint.
o トランスポートトンネルは、パスエンドポイントとしてプライマリPEを持つ必要があります。
o The bypass tunnel MUST have the protector as the path endpoint. In egress PE and S-PE node protection, the path MUST avoid the primary PE.
o バイパストンネルには、パスエンドポイントとしてプロテクターが必要です。出力PEおよびS-PEノード保護では、パスはプライマリPEを回避する必要があります。
There are generally two categories of approaches to achieve the above:
上記を達成するためのアプローチには、一般に2つのカテゴリがあります。
o The first category does not require an ingress PE or a PLR to have knowledge of the PW egress endpoint protection schema. It does not require any IGP extension for context identifier advertisement. A context identifier is advertised by the primary PE and the protector as an address reachable via both routers. The ingress PE and the PLR can compute paths by using a normal method, such as Dijkstra, constrained shortest path first (CSPF), Loop-Free Alternate (LFA) [RFC5286], and Maximally Redundant Tree (MRT) [RFC7812]. One example is to advertise a context identifier as a virtual proxy node connected to the primary PE and the protector, with the link between the proxy node and the primary PE having a more preferable IGP and TE metric than the link between the proxy node and the protector. The transport tunnel will follow the shortest path or a TE path to the primary PE and be terminated by the primary PE. The PLR will no longer view itself as a penultimate hop of the transport tunnel, but rather two hops away from the proxy node, via the primary PE. Hence, a node- protection bypass tunnel will be available via the protector to the proxy node, but it will actually be terminated by the protector.
o最初のカテゴリでは、入力PEまたはPLRがPW出力エンドポイント保護スキーマの知識を持つ必要はありません。コンテキスト識別子の通知にIGP拡張機能は必要ありません。コンテキスト識別子は、両方のルーターを介して到達可能なアドレスとして、プライマリPEおよびプロテクターによってアドバタイズされます。入力PEとPLRは、ダイクストラ、制約付き最短パス優先（CSPF）、ループフリー代替（LFA）[RFC5286]、最大冗長ツリー（MRT）[RFC7812]などの通常の方法を使用してパスを計算できます。 1つの例は、プライマリPEとプロテクターに接続された仮想プロキシノードとしてコンテキストIDをアドバタイズすることです。プロキシノードとプライマリPE間のリンクは、プロキシノードとリンク間のリンクよりもIGPおよびTEメトリックが好ましいプロテクター。トランスポートトンネルは、プライマリPEへの最短パスまたはTEパスをたどり、プライマリPEによって終端されます。 PLRは、自身をトランスポートトンネルの最後から2番目のホップと見なすのではなく、プライマリPEを介してプロキシノードから2ホップ離れたところと見なします。したがって、ノード保護バイパストンネルは、プロテクターを介してプロキシノードにアクセスできますが、実際にはプロテクターによって終了されます。
o The second category requires a PLR to have knowledge of the PW egress endpoint protection schema. The primary PE advertises the context identifier as a regular IP address, while the protector advertises it by using an explicit "context identifier object", which MUST be understood by the PLR. The context identifier object requires an IGP extension. In both the routing domain and the TE domain, the context identifier is only reachable via the primary PE. This ensures that the transport tunnel is terminated by the primary PE. The PLR views itself as the penultimate hop of the transport tunnel, and based on the IGP context identifier object, it establishes or resolves a bypass tunnel to the advertiser (i.e., the protector), while avoiding the primary PE.
o 2番目のカテゴリでは、PLRがPW出力エンドポイント保護スキーマの知識を持っている必要があります。プライマリPEはコンテキスト識別子を通常のIPアドレスとしてアドバタイズしますが、プロテクターは明示的な「コンテキスト識別子オブジェクト」を使用してアドバタイズしますが、PLRはこれを理解する必要があります。コンテキスト識別子オブジェクトにはIGP拡張が必要です。ルーティングドメインとTEドメインの両方で、コンテキスト識別子はプライマリPE経由でのみ到達可能です。これにより、トランスポートトンネルがプライマリPEによって確実に終了されます。 PLRは、それ自体をトランスポートトンネルの最後から2番目のホップと見なし、IGPコンテキスト識別子オブジェクトに基づいて、プライマリPEを回避しながら、バイパストンネルを確立または解決して、広告主（つまり、プロテクター）を確立します。
The mechanism in this document intends to be flexible on the approach used by a network, as long as it satisfies the above requirements for the transport tunnel path and bypass tunnel path. In theory, the network can use one approach for context ID X and another approach for context ID Y. For a given context ID, all relevant routers, including primary PE, protector, and PLR, must support and agree on the chosen approach. The coordination between the routers can be achieved by configuration.
このドキュメントのメカニズムは、トランスポートトンネルパスとバイパストンネルパスに関する上記の要件を満たしている限り、ネットワークで使用されるアプローチに柔軟に対応することを目的としています。理論的には、ネットワークはコンテキストID Xの1つのアプローチとコンテキストID Yの別のアプローチを使用できます。特定のコンテキストIDについて、プライマリPE、プロテクター、PLRを含むすべての関連ルーターは、選択されたアプローチをサポートし、合意する必要があります。ルーター間の調整は、構成によって実現できます。
There are two protection models based on the location of a protector: the co-located protector model and the centralized protector model. A network MAY use either model or both.
プロテクターの場所に基づいて2つの保護モデルがあります。同じ場所に配置されたプロテクターモデルと集中型プロテクターモデルです。ネットワークはどちらか一方または両方のモデルを使用できます。
In this model, the protector is a backup PE that is directly connected to the target CE via a backup AC, or it is a backup S-PE on a backup PW. That is, the protector is co-located with the backup (S-)PE. Examples of this model are shown in Figures 4, 5, and 6 in Section 4.2.
このモデルでは、プロテクターは、バックアップACを介してターゲットCEに直接接続されているバックアップPEであるか、またはバックアップPW上のバックアップS-PEです。つまり、プロテクターはバックアップ（S-）PEと同じ場所に配置されます。このモデルの例は、セクション4.2の図4、5、および6に示されています。
In egress AC protection and egress PE node protection, when a protector receives traffic from the PLR, it forwards the traffic to the CE via the backup AC. This is shown in Figure 7, where PE2 is the PLR for egress AC failure, P3 is the PLR for PE2 failure, and PE4 (backup PE) is the protector.
出力AC保護と出力PEノード保護では、プロテクターがPLRからトラフィックを受信すると、バックアップACを介してCEにトラフィックを転送します。これを図7に示します。PE2は出力AC障害のPLR、P3はPE2障害のPLR、PE4（バックアップPE）はプロテクターです。
|<-------------- PW1 --------------->|
- PE1 -------------- P1 ------- P3 ----- PE2 ----
/ PLR \ PLR \
/ \ | \
CE1 bypass\ |bypass CE2
\ \ | /
\ \ | /
- PE3 -------------- P2 ---------------- PE4 ----
protector
|<-------------- PW2 --------------->|
Figure 7
図7
In S-PE node protection, when a protector receives traffic from the PLR, it forwards the traffic over the next segment of the backup PW. The T-PE of the backup PW in turn forwards the traffic to the CE via a backup AC. This is shown in Figure 8, where P1 is the PLR for SPE1 failure, and SPE2 (backup S-PE) is the protector for SPE1. SPE2 receives traffic from P1, swaps SEG1's label to SEG4's label, and forwards the traffic over a transport tunnel to TPE4.
S-PEノード保護では、プロテクターがPLRからトラフィックを受信すると、バックアップPWの次のセグメントを介してトラフィックを転送します。バックアップPWのT-PEは、バックアップACを介してトラフィックをCEに転送します。これを図8に示します。ここで、P1はSPE1障害のPLRであり、SPE2（バックアップS-PE）はSPE1のプロテクターです。 SPE2はP1からトラフィックを受信し、SEG1のラベルをSEG4のラベルに交換し、トランスポートトンネルを介してTPE4にトラフィックを転送します。
|<--------------- PW1 --------------->|
|<----- SEG1 ----->|<----- SEG2 ----->|
- TPE1 ----- P1 ----- SPE1 -------------- TPE2 -
/ PLR \ \
/ \ \
CE1 bypass\ CE2
\ \ /
\ \ /
- TPE3 --------------- SPE2 -------------- TPE4 -
protector
|<----- SEG3 ----->|<----- SEG4 ----->|
|<--------------- PW2 --------------->|
Figure 8
図8
In the co-located protector model, the number of context identifiers needed by a network is the number of distinct {primary PE, backup PE} pairs. From the perspective of scalability, the model is suitable for networks where the number of primary PEs and the average number of backup PEs per primary PE are both relatively low.
同じ場所に配置されたプロテクターモデルでは、ネットワークに必要なコンテキスト識別子の数は、異なる{プライマリPE、バックアップPE}ペアの数です。スケーラビリティの観点から、このモデルは、プライマリPEの数とプライマリPEあたりのバックアップPEの平均数がどちらも比較的少ないネットワークに適しています。
In this model, the protector is a dedicated P router or PE router that serves the role. In egress AC protection and egress PE node protection, the protector may or may not be a backup PE directly connected to the target CE. In S-PE node protection, the protector may or may not be a backup S-PE on the backup PW.
このモデルでは、プロテクターは、役割を担う専用のPルーターまたはPEルーターです。出力AC保護と出力PEノード保護では、プロテクターはターゲットCEに直接接続されたバックアップPEである場合とそうでない場合があります。 S-PEノード保護では、プロテクターはバックアップPW上のバックアップS-PEである場合とそうでない場合があります。
In egress AC protection and egress PE node protection, if the protector is not directly connected to the CE, it forwards the traffic to a backup PE, which in turn forwards the traffic to the CE via a backup AC. This is shown in Figure 9, where the protector receives traffic from P3 (PLR for egress PE failure) or PE2 (PLR for egress AC failure), swaps PW1's label to PW2's label, and forwards the traffic via a transport tunnel to PE4 (backup PE). The protector may be protecting other PWs and other primary PEs as well; for clarity, this is not shown in the figure.
出力AC保護と出力PEノード保護では、プロテクターがCEに直接接続されていない場合、トラフィックをバックアップPEに転送し、バックアップPEはバックアップACを介してCEにトラフィックを転送します。これは図9に示されています。ここで、プロテクターはP3（出力PE障害の場合はPLR）またはPE2（出力AC障害の場合はPLR）からトラフィックを受信し、PW1のラベルをPW2のラベルにスワップし、トランスポートトンネルを介してトラフィックをPE4（バックアップ）に転送します。 PE）。プロテクターは他のPWおよび他のプライマリPEも保護している可能性があります。明確にするために、これは図には示されていません。
|<------------- PW1 --------------->|
- PE1 ------------- P1 ------- P3 ----- PE2 --
/ PLR \ PLR \
/ \ / \
/ bypass\ /bypass \
/ \ / \
CE1 protector CE2
\ \ /
\ transport\ /
\ tunnel \ /
\ \ /
- PE3 ------------- P2 -----------------PE4 --
|<------------- PW2 --------------->|
Figure 9
図9
In S-PE node protection, if the protector is not a backup S-PE, it forwards the traffic to the backup S-PE, which in turn forwards the traffic over the next segment of the backup PW. Finally, the T-PE of the backup PW forwards the traffic to the CE via the backup AC. This is shown in Figure 10, where the protector receives traffic from P1 (PLR), swaps SEG1's label to SEG3's label, and forwards the traffic via a transport tunnel to SPE2 (backup S-PE). SPE2 in turn performs MS-PW switching from SEG3's label to SEG4's label and forwards the traffic over a transport tunnel to TPE4 (backup T-PE). The protector may be protecting other PW segments and other primary S-PEs as well; for clarity, this is not shown in the figure.
S-PEノード保護では、プロテクターがバックアップS-PEでない場合、トラフィックをバックアップS-PEに転送します。バックアップS-PEは、トラフィックをバックアップPWの次のセグメントに転送します。最後に、バックアップPWのT-PEは、バックアップACを介してトラフィックをCEに転送します。これを図10に示します。ここで、プロテクターはP1（PLR）からトラフィックを受信し、SEG1のラベルをSEG3のラベルにスワップし、トランスポートトンネルを介してSPE2（バックアップS-PE）にトラフィックを転送します。 SPE2は、次にSEG3のラベルからSEG4のラベルへのMS-PWスイッチングを実行し、トランスポートトンネルを介してトラフィックをTPE4（バックアップT-PE）に転送します。プロテクターは、他のPWセグメントと他のプライマリS-PEも保護している可能性があります。明確にするために、これは図には示されていません。
|<--------------- PW1 --------------->|
|<----- SEG1 ----->|<----- SEG2 ----->|
- TPE1 ----- P1 ----- SPE1 -------------- TPE2 -
/ PLR \ \
/ \ \
/ bypass\ \
/ \ \
CE1 protector CE2
\ \ /
\ transport\ /
\ tunnel \ /
\ \ /
- TPE3 --------------- SPE2 -------------- TPE4 -
|<----- SEG3 ----->|<----- SEG4 ----->|
|<--------------- PW2 --------------->|
Figure 10
図10
The centralized protector model allows multiple primary PEs to share one protector. Each primary PE may need only one protector. Therefore, the number of context identifiers needed by a network may be bound to the number of primary PEs.
集中型プロテクターモデルでは、複数のプライマリPEが1つのプロテクターを共有できます。各プライマリPEに必要なプロテクターは1つだけです。したがって、ネットワークに必要なコンテキスト識別子の数は、プライマリPEの数にバインドされる場合があります。
A PW is associated with a pair of {primary PE, protector}, which is represented by a unique context identifier. The ingress PE of the PW sets up or resolves a transport tunnel by using the context identifier rather than a private IP address of the primary PE as the destination. This not only ensures that the PW is transported to the primary PE but also facilitates bypass tunnel establishment at PLR, because the context identifier contains the identity of the protector as well. This is also the case for a multi-segment PW, where the ingress PE and egress PE are T-/S-PEs.
PWは、一意のコンテキスト識別子で表される{プライマリPE、プロテクター}のペアに関連付けられています。 PWの入力PEは、プライマリPEのプライベートIPアドレスではなく、コンテキスト識別子を宛先として使用して、トランスポートトンネルをセットアップまたは解決します。これにより、PWがプライマリPEに確実に転送されるだけでなく、PLRでのバイパストンネルの確立も容易になります。これは、コンテキスト識別子にプロテクターのIDも含まれているためです。これは、入力PEと出力PEがT- / S-PEであるマルチセグメントPWの場合にも当てはまります。
An ingress PE learns the association between a PW and a context identifier from the primary PE, which MUST advertise the context identifier as a "third-party next hop" via the IPv4/v6 Interface_ID TLV [RFC3471] [RFC3472] in the LDP Label Mapping message of the PW.
入力PEは、PWとコンテキスト識別子の間の関連付けをプライマリPEから学習します。プライマリPEは、LDPラベルのIPv4 / v6 Interface_ID TLV [RFC3471] [RFC3472]を介して、コンテキスト識別子を「サードパーティのネクストホップ」としてアドバタイズする必要があります。 PWのマッピングメッセージ。
In an ECMP scenario, a transport tunnel may have multiple penultimate hop routers. Each of them SHOULD act as a PLR independently. Also in an ECMP scenario, a penultimate hop router may have ECMPs to the primary PE. At least one path of the ECMPs must be a direct link to the primary PE, qualifying the router as a penultimate hop. The other paths of the ECMPs may be direct links or indirect paths to the primary PE. In egress PE node protection and S-PE node protection, when a node failure is detected, or a link failure is detected on a direct link and treated as a node failure, the penultimate hop router SHOULD act as a PLR and reroute the entire traffic of the ECMPs to the protector.
ECMPシナリオでは、トランスポートトンネルに複数の最後から2番目のホップルーターがある場合があります。それらのそれぞれは独立してPLRとして振る舞うべきです（SHOULD）。また、ECMPシナリオでは、最後から2番目のホップルーターがプライマリPEへのECMPを持つ場合があります。 ECMPの少なくとも1つのパスは、プライマリPEへの直接リンクである必要があり、ルーターを最後から2番目のホップとして認定します。 ECMPの他のパスは、プライマリPEへの直接リンクまたは間接パスです。出力PEノード保護とS-PEノード保護では、ノード障害が検出された場合、またはリンク障害が直接リンクで検出され、ノード障害として処理された場合、最後から2番目のホップのルーターはPLRとして機能し、トラフィック全体を再ルーティングする必要があります（SHOULD） ECMPの保護者への。
A PLR may protect multiple PWs associated with one or multiple pairs of {primary PE, protector}. The PLR MUST establish a bypass tunnel to each protector for each context identifier associated with that protector. The destination of the bypass tunnel MUST be the context identifier (Section 4.3.1). Since the PLR is a transit router of the transport tunnel, it SHOULD derive the context identifier from the destination of the transport tunnel.
PLRは、{プライマリPE、プロテクター}の1つまたは複数のペアに関連付けられた複数のPWを保護できます。 PLRは、そのプロテクターに関連付けられた各コンテキスト識別子に対して、各プロテクターへのバイパストンネルを確立する必要があります。バイパストンネルの宛先は、コンテキスト識別子でなければなりません（セクション4.3.1）。 PLRはトランスポートトンネルの中継ルーターであるため、トランスポートトンネルの宛先からコンテキスト識別子を導出する必要があります（SHOULD）。
For example, in Figures 7 and 9, a bypass tunnel is established from PE2 (PLR for egress AC failure) to the protector, and another bypass tunnel is established from P3 (PLR for egress node failure) to the protector. In Figures 8 and 10, a bypass tunnel is established from P1 (PLR for S-PE failure) to the protector.
たとえば、図7および9では、PE2（出力AC障害のPLR）からプロテクターへのバイパストンネルが確立され、P3（出力ノードの障害のPLR）からプロテクターへの別のバイパストンネルが確立されます。図8および10では、P1（S-PE障害のPLR）からプロテクターへのバイパストンネルが確立されています。
In local repair, a PLR reroutes traffic to the protector through a bypass tunnel, with the PW label intact in the packets. This normally involves pushing a label to the label stack, if the bypass tunnel is an MPLS tunnel, or pushing an IP header to the packets, if the bypass tunnel is an IP tunnel. Upon receipt of the packets, the protector forwards them based on the PW label. Specifically, the protector uses the bypass tunnel as a context to determine the primary PE's label space. If the bypass tunnel is an MPLS tunnel, the protector should have assigned a non-reserved label to the bypass tunnel; hence, this label can serve as the context. This label is also called a "context label", as it is actually bound to the context identifier. If the bypass tunnel is an IP tunnel, the context identifier should be the destination address of the IP header.
ローカル修復では、PLRはバイパストンネルを介してトラフィックをプロテクターに再ルーティングし、パケット内のPWラベルはそのままにします。これには通常、バイパストンネルがMPLSトンネルの場合はラベルスタックにラベルをプッシュするか、バイパストンネルがIPトンネルの場合はIPヘッダーをパケットにプッシュする必要があります。パケットを受信すると、プロテクターはPWラベルに基づいてパケットを転送します。具体的には、プロテクターはバイパストンネルをコンテキストとして使用して、プライマリPEのラベルスペースを決定します。バイパストンネルがMPLSトンネルである場合、プロテクターは予約されていないラベルをバイパストンネルに割り当てているはずです。したがって、このラベルはコンテキストとして機能します。このラベルは実際にコンテキスト識別子にバインドされているため、「コンテキストラベル」とも呼ばれます。バイパストンネルがIPトンネルの場合、コンテキスト識別子はIPヘッダーの宛先アドレスにする必要があります。
To be useful for local repair, a bypass tunnel MUST have the property that it is not affected by any topology changes caused by the failure. It MUST NOT traverse the primary PE or the penultimate link of the transport tunnel, or share any SRLG with the penultimate link. A bypass tunnel may be a TE tunnel with reserved bandwidth to avoid traffic congestion for rerouted traffic. A bypass tunnel should remain effective during local repair, until the traffic is moved to an alternative path, i.e., either the same PW over a fully functional transport tunnel or another fully functional PW.
ローカルの修復に役立つように、バイパストンネルには、障害によって引き起こされるトポロジの変更の影響を受けないという特性が必要です。プライマリPEまたはトランスポートトンネルの最後から2番目のリンクを通過したり、SRLGを最後から2番目のリンクと共有してはなりません。バイパストンネルは、再ルーティングされたトラフィックのトラフィックの輻輳を回避するために予約された帯域幅を持つTEトンネルである場合があります。バイパストンネルは、トラフィックが代替パス、つまり、完全に機能するトランスポートトンネル上の同じPWまたは別の完全に機能するPWに移動するまで、ローカルの修復中も有効なままである必要があります。
There is little or no benefit to protect a bypass tunnel. Therefore, a bypass tunnel SHOULD NOT be protected against a transit link failure, transit node failure, or egress node failure.
バイパストンネルを保護するメリットはほとんどありません。したがって、バイパストンネルは、トランジットリンクの障害、トランジットノードの障害、または出口ノードの障害から保護してはなりません（SHOULD NOT）。
This section provides some detailed examples of forwarding state on the PLR, protector, and other relevant routers.
このセクションでは、PLR、プロテクター、およびその他の関連ルーターの転送状態のいくつかの詳細な例を示します。
A protector learns PW labels from all the primary PEs that it protects (Section 6.2) and maintains the PW labels in separate label spaces on a per-primary-PE basis. In the control plane, each label space is identified by the context identifier of the corresponding {primary PE, protector}. In the forwarding plane, the label space is indicated by the bypass tunnel(s) destined for the context identifier.
プロテクターは、保護するすべてのプライマリPEからPWラベルを学習し（セクション6.2）、PWラベルをプライマリPEごとに個別のラベルスペースに維持します。コントロールプレーンでは、各ラベルスペースは、対応する{プライマリPE、プロテクター}のコンテキスト識別子によって識別されます。フォワーディングプレーンでは、ラベルスペースは、コンテキスト識別子を宛先とするバイパストンネルによって示されます。
In Figure 11, PE4 is a co-located protector that protects PW1 against egress AC failure and egress node failure. It maintains a label space for PE2, which is identified by the context identifier of {PE2, PE4}. It learns PW1's label from PE2 and installs a forwarding entry for the label in that label space. The next hop of the forwarding entry indicates a label pop with an outgoing interface pointing to the backup AC PE4-CE2.
図11では、PE4は、出力AC障害および出力ノード障害からPW1を保護する同じ場所に配置されたプロテクターです。これは、{PE2、PE4}のコンテキスト識別子によって識別されるPE2のラベルスペースを維持します。 PE2からPW1のラベルを学習し、そのラベルスペースにラベルの転送エントリをインストールします。転送エントリのネクストホップは、バックアップAC PE4-CE2を指す発信インターフェイスを持つラベルポップを示します。
|<-------------- PW1 --------------->|
- PE1 -------------- P1 ------- P3 ----- PE2 ------
/ PLR \ PLR \
/ \ | \
/ \ | \
CE1 bypass P4 P5 bypass CE2
\ \ | /
\ \ | /
\ \ | /
- PE3 -------------- P2 ---------------- PE4 ------
protector
|<-------------- PW2 --------------->|
PW1's label assigned by PE2: 100
PW2's label assigned by PE4: 200
On P3: </t>
Incoming label of transport tunnel to PE2: 1000
Outgoing label of transport tunnel to PE2: implicit null
Outgoing label of bypass tunnel to PE4: 2000
On PE2:
Outgoing label of bypass tunnel to PE4: 3000
On PE4:
Context label (incoming label of bypass tunnels): 999
Forwarding state on P3: label 1000 -- primary next hop: pop, to PE2 backup next hop: swap 2000, to P4
P3の転送状態：ラベル1000-プライマリネクストホップ：ポップ、PE2バックアップネクストホップ：スワップ2000、P4へ
Forwarding state on PE2: label 100 -- primary next hop: pop, to CE2 backup next hop: push 3000, to P5
PE2の転送状態：ラベル100-プライマリネクストホップ：ポップ、CE2バックアップネクストホップ：プッシュ3000、P5へ
Forwarding state on P4: label 2000 -- next hop: swap 999, to PE4
P4の転送状態：ラベル2000-ネクストホップ：999をスワップし、PE4に
Forwarding state on P5: label 3000 -- next hop: swap 999, to PE4
P5の転送状態：ラベル3000-ネクストホップ：999をスワップし、PE4に
Forwarding state on PE4:
label 200 -- next hop: pop, to CE2
label 999 -- next hop: label table of PE2's label space
Label table of PE2's label space on PE4: label 100 -- next hop: pop, to CE2
PE4のPE2のラベルスペースのラベルテーブル：ラベル100-次のホップ：CE2へのポップ
Figure 11
図11
In Figure 12, SPE2 is a co-located protector that protects PW1 against S-PE failure. It maintains a label space for SPE1, which is identified by the context identifier of {SPE1, SPE2}. It learns SEG1's label from SPE1 and installs a forwarding entry in the label space. The next hop of the forwarding entry indicates a label swap to SEG4's label and a label push with the label of a transport tunnel to TPE4.
図12で、SPE2はPW1をS-PEの障害から保護する同じ場所に配置されたプロテクターです。これは、{SPE1、SPE2}のコンテキスト識別子によって識別されるSPE1のラベルスペースを維持します。 SPE1からSEG1のラベルを学習し、ラベルスペースに転送エントリをインストールします。転送エントリのネクストホップは、SEG4のラベルへのラベルスワップと、TPE4へのトランスポートトンネルのラベルを含むラベルプッシュを示します。
|<--------------- PW1 --------------->|
|<----- SEG1 ----->|<----- SEG2 ----->|
- TPE1 ----- P1 ----- SPE1 --- P3 ------- TPE2 -
/ PLR \ \
/ \ \
CE1 bypass P2 CE2
\ \ /
\ \ /
- TPE3 --------------- SPE2 --- P4 ------- TPE4 -
protector
|<----- SEG3 ----->|<----- SEG4 ----->|
|<--------------- PW2 --------------->|
SEG1's label assigned by SPE1: 100 SEG2's label assigned by TPE2: 200 SEG3's label assigned by SPE2: 300 SEG4's label assigned by TPE4: 400 On P1: Incoming label of transport tunnel to SPE1: 1000 Outgoing label of transport tunnel to SPE1: implicit null Outgoing label of bypass tunnel to SPE2: 2000 On SPE1: Outgoing label of transport tunnel to TPE2: 3000 On SPE2: Outgoing label of transport tunnel to TPE4: 4000 Context label (incoming label of bypass tunnel): 999
SPE1によって割り当てられたSEG1のラベル：100 TPE2によって割り当てられたSEG2のラベル：SPE2によって割り当てられたSEG3のラベル：300 TPE4によって割り当てられたSEG4のラベル：400オンP1：SPE1へのトランスポートトンネルの受信ラベル：1000 SPE1：へのトランスポートトンネルの送信ラベルSPE2へのバイパストンネルの発信ラベル：2000 SPE1：TPE2へのトランスポートトンネルの発信ラベル：3000 SPE2：TPE4へのトランスポートトンネルの発信ラベル：4000コンテキストラベル（バイパストンネルの着信ラベル）：999
Forwarding state on P1: label 1000 -- primary next hop: pop, to SPE1 backup next hop: swap 2000, to P2
P1の転送状態：ラベル1000-プライマリネクストホップ：ポップ、SPE1バックアップネクストホップ：スワップ2000、P2へ
Forwarding state on SPE1: label 100 -- next hop: swap 200, push 3000, to P3
SPE1の転送状態：ラベル100-ネクストホップ：スワップ200、プッシュ3000、P3へ
Forwarding state on P2: label 2000 -- next hop: swap 999, to SPE2
P2の転送状態：ラベル2000-次のホップ：スワップ999、SPE2へ
Forwarding state on SPE2:
label 300 -- next hop: swap 400, push 4000, to P4
label 999 -- next hop: label table of SPE1's label space
Label table of SPE1's label space on SPE2: label 100 -- next hop: swap 400, push 4000, to P4
SPE2上のSPE1のラベルスペースのラベルテーブル：ラベル100-ネクストホップ：スワップ400、プッシュ4000、P4へ
Figure 12
図12
In the centralized protector model, for each primary PW of which the protector is not a backup (S-)PE, the protector MUST also learn the label of the backup PW from the backup (S-)PE (Section 6.3). This is the backup (S-)PE that the protector will forward traffic to. The protector MUST install a forwarding entry with a label swap from the primary PW's label to the backup PW's label and a label push with the label of a transport tunnel to the backup (S-)PE.
集中型プロテクターモデルでは、プロテクターがバックアップ（S-）PEではない各プライマリPWについて、プロテクターはバックアップ（S-）PEからバックアップPWのラベルも学習する必要があります（セクション6.3）。これは、プロテクターがトラフィックを転送するバックアップ（S-）PEです。プロテクターは、プライマリPWのラベルからバックアップPWのラベルへのラベルスワップと、転送（S-）PEへのトランスポートトンネルのラベル付きのラベルプッシュを使用して、転送エントリをインストールする必要があります。
In Figure 13, the protector is a centralized protector that protects PW1 against egress AC failure and egress node failure. It maintains a label space for PE2, which is identified by the context identifier of {PE2, protector}. It learns PW1's label from PE2 and PW2's label from PE4. It installs a forwarding entry for PW1's label in the label space. The next hop of the forwarding entry indicates a label swap to PW2's label and a label push with the label of a transport tunnel to PE4.
図13のプロテクターは、出力AC障害および出力ノード障害からPW1を保護する集中型プロテクターです。これは、{PE2、protector}のコンテキスト識別子によって識別されるPE2のラベルスペースを維持します。 PE2からPW1のラベルを学習し、PE4からPW2のラベルを学習します。 PW1のラベルの転送エントリをラベルスペースにインストールします。転送エントリの次のホップは、PW2のラベルへのラベルスワップと、PE4へのトランスポートトンネルのラベルを使用したラベルプッシュを示します。
|<-------------- PW1 --------------->|
- PE1 ------------- P1 ------- P3 ------ PE2 ----
/ PLR \ PLR \
/ \ / \
/ bypass P5 P6 bypass \
/ \ / \
/ \/ \
CE1 protector CE2
\ \ /
\ transport \ /
\ tunnel P7 /
\ \ /
\ \ /
- PE3 ------------- P2 ----------------- PE4 ----
|<-------------- PW2 --------------->|
PW1's label assigned by PE2: 100 PW2's label assigned by PE4: 200 On P3: Incoming label of transport tunnel to PE2: 1000 Outgoing label of transport tunnel to PE2: implicit null Outgoing label of bypass tunnel to protector: 2000 On PE2: Outgoing label of bypass tunnel to protector: 3000 On protector: Context label (incoming label of bypass tunnels): 999 Outgoing label of transport tunnel to PE4: 4000
PE2によって割り当てられたPW1のラベル：100 PE4によって割り当てられたPW2のラベル：200 On P3：PE2へのトランスポートトンネルの受信ラベル：1000 PE2へのトランスポートトンネルの送信ラベル：暗黙的なnullプロテクターへのバイパストンネルの送信ラベル：2000 On PE2：送信ラベルバイパストンネルからプロテクターへ：3000オンプロテクター：コンテキストラベル（バイパストンネルの受信ラベル）：999 PE4へのトランスポートトンネルの発信ラベル：4000
Forwarding state on P3: label 1000 -- primary next hop: pop, to PE2 backup next hop: swap 2000, to P5
P3の転送状態：ラベル1000-プライマリネクストホップ：ポップ、PE2バックアップネクストホップ：スワップ2000、P5へ
Forwarding state on PE2: label 100 -- primary next hop: pop, to CE2 backup next hop: push 3000, to P6
PE2の転送状態：ラベル100-プライマリネクストホップ：ポップ、CE2バックアップネクストホップ：プッシュ3000、P6
Forwarding state on P5: label 2000 -- next hop: swap 999, to protector
P5の転送状態：ラベル2000-ネクストホップ：999を交換、プロテクターへ
Forwarding state on P6: label 3000 -- next hop: swap 999, to protector
P6の転送状態：ラベル3000-ネクストホップ：交換999、プロテクターへ
Forwarding state on P7: label 4000 -- next hop: pop, to PE4
P7の転送状態：ラベル4000-ネクストホップ：ポップ、PE4へ
Forwarding state on PE4: label 200 -- next hop: pop, to CE2
PE4の転送状態：ラベル200-ネクストホップ：pop、CE2へ
Forwarding state on protector: label 999 -- next hop: label table of PE2's label space
プロテクターの転送状態：ラベル999-ネクストホップ：PE2のラベルスペースのラベルテーブル
Label table of PE2's label space on protector: label 100 -- next hop: swap 200, push 4000, to P7
プロテクター上のPE2のラベルスペースのラベルテーブル：ラベル100-次のホップ：200をスワップし、4000をP7にプッシュ
Figure 13
図13
In Figure 14, the protector is a centralized protector that protects the PW segment SEG1 of PW1 against the node failure of SPE1. It maintains a label space for SPE1, which is identified by the context identifier of {SPE1, protector}. It learns SEG1's label from SPE1 and SEG3's label from SPE2. It installs a forwarding entry for SEG1's label in the label space. The next hop of the forwarding entry indicates a label swap to SEG3's label and a label push with the label of a transport tunnel to TPE4.
図14では、プロテクターは集中型プロテクターであり、PW1のPWセグメントSEG1をSPE1のノード障害から保護します。これは、{SPE1、プロテクター}のコンテキスト識別子によって識別されるSPE1のラベルスペースを維持します。 SPE1からSEG1のラベルを学習し、SPE2からSEG3のラベルを学習します。ラベルスペースにSEG1のラベルの転送エントリをインストールします。転送エントリの次のホップは、SEG3のラベルへのラベルスワップと、TPE4へのトランスポートトンネルのラベルを含むラベルプッシュを示します。
|<--------------- PW1 --------------->|
|<----- SEG1 ----->|<----- SEG2 ----->|
- TPE1 ----- P1 ----- SPE1 --- P2 -------- TPE2 -
/ PLR \ \
/ \ \
/ bypass P4 \
/ \ \
/ \ \
CE1 protector CE2
\ \ /
\ \ /
\ transport P5 /
\ tunnel \ /
\ \ /
- TPE3 -------------- SPE2 --- P3 -------- TPE4 -
|<----- SEG3 ----->|<----- SEG4 ----->|
|<--------------- PW2 --------------->|
SEG1's label assigned by SPE1: 100 SEG2's label assigned by TPE2: 200 SEG3's label assigned by SPE2: 300 SEG4's label assigned by TPE4: 400 On P1: Incoming label of transport tunnel to SPE1: 1000 Outgoing label of transport tunnel to SPE1: implicit null Outgoing label of bypass tunnel to protector: 2000 On SPE1: Outgoing label of transport tunnel to TPE2: 3000 On SPE2: Outgoing label of transport tunnel to TPE4: 4000 On protector: Context label (incoming label of bypass tunnel): 999 Outgoing label of transport tunnel to SPE2: 5000
SPE1によって割り当てられたSEG1のラベル：100 TPE2によって割り当てられたSEG2のラベル：200 SPE2によって割り当てられたSEG3のラベル：TPE4によって割り当てられたSEG4のラベル：400 On P1：SPE1へのトランスポートトンネルの受信ラベル：1000 SPE1へのトランスポートトンネルの送信ラベル：暗黙のnullプロテクターへのバイパストンネルの発信ラベル：2000 SPE1：TPE2へのトランスポートトンネルの発信ラベル：3000 SPE2：TPE4へのトランスポートトンネルの発信ラベル：4000プロテクター：コンテキストラベル（バイパストンネルの着信ラベル）：999の発信ラベルSPE2へのトランスポートトンネル：5000
Forwarding state on P1: label 1000 -- primary next hop: pop, to SPE1 backup next hop: swap 2000, to P4
P1の転送状態：ラベル1000-プライマリネクストホップ：ポップ、SPE1バックアップネクストホップ：スワップ2000、P4
Forwarding state on SPE1: label 100 -- next hop: swap 200, push 3000, to P2
SPE1の転送状態：ラベル100-ネクストホップ：スワップ200、プッシュ3000、P2へ
Forwarding state on P4: label 2000 -- next hop: swap 999, to protector
P4の転送状態：ラベル2000-ネクストホップ：999を交換、プロテクターへ
Forwarding state on P5: label 5000 -- next hop: pop, to SPE2 Forwarding state on SPE2: label 300 -- next hop: swap 400, push 4000, to P3
P5の転送状態：ラベル5000-ネクストホップ：ポップ、SPE2へSPE2の転送状態：ラベル300-ネクストホップ：スワップ400、プッシュ4000、P3へ
Forwarding state on protector: label 999 -- next hop: label table of SPE1's label space
プロテクターの転送状態：ラベル999-ネクストホップ：SPE1のラベルスペースのラベルテーブル
Label table of SPE1's label space on protector: label 100 -- next hop: swap 300, push 5000, to P5
プロテクター上のSPE1のラベルスペースのラベルテーブル：ラベル100-ネクストホップ：スワップ300、プッシュ5000、P5へ
Figure 14
図14
Subsequent to local repair, there are three strategies for a network to restore traffic to a fully functional alternative path:
ローカル修復に続いて、ネットワークが完全に機能する代替パスにトラフィックを復元するための3つの戦略があります。
o Global repair
o グローバルな修理
If the ingress CE is multihomed (Figure 1), it MAY switch the traffic to the backup AC, which is bound to the backup PW. Alternatively, if the ingress PE hosts a backup PW (Figure 2), the ingress PE MAY switch the traffic to the backup PW. These procedures are referred to as global repair. Possible triggers of global repair include PW status notification, Virtual Circuit Connectivity Verification (VCCV) [RFC5085] [RFC5885], BFD, end-to-end OAM between CEs, and others.
入力CEがマルチホーム化されている場合（図1）、バックアップPWにバインドされているバックアップACにトラフィックを切り替えることができます（MAY）。あるいは、入力PEがバックアップPWをホストしている場合（図2）、入力PEはトラフィックをバックアップPWに切り替えることができます（MAY）。これらの手順は、グローバル修復と呼ばれます。グローバル修復の可能なトリガーには、PWステータス通知、仮想回路接続検証（VCCV）[RFC5085] [RFC5885]、BFD、CE間のエンドツーエンドOAMなどがあります。
o Control-plane convergence
o コントロールプレーンコンバージェンス
In egress PE node protection and S-PE node protection, it is possible that the failure is limited to the link between the PLR and the primary PE, whereas the primary PE is still operational. In this case, the PLR or an upstream router on the transport tunnel MAY reroute the tunnel around the link via an alternative path to the primary PE. Thus, the transport tunnel can heal and continue to carry the PW to the primary PE. This procedure is driven by control-plane convergence on the new topology.
出力PEノード保護およびS-PEノード保護では、障害がPLRとプライマリPEの間のリンクに限定され、プライマリPEは引き続き動作している可能性があります。この場合、トランスポートトンネルのPLRまたはアップストリームルーターは、プライマリPEへの代替パスを介してリンクの周囲にトンネルを再ルーティングできます。したがって、トランスポートトンネルはPWを回復してプライマリPEに転送し続けることができます。この手順は、新しいトポロジでのコントロールプレーンの収束によって駆動されます。
o Local reversion
o ローカル復帰
The PLR MAY move traffic back to the primary PW, after the failure is resolved. In egress AC protection, upon detecting that the primary AC is restored, the PLR MAY start forwarding traffic over the AC again. Likewise, in egress PE node protection and S-PE node protection, upon detecting that the primary PE is restored, the PLR MAY re-establish the transport tunnel to the primary PE and move the traffic from the bypass tunnel back to the transport tunnel. These procedures are referred to as local reversion.
PLRは、障害が解決された後、トラフィックをプライマリPWに戻すことができます（MAY）。出力AC保護では、プライマリACが復元されたことを検出すると、PLRはACを介してトラフィックの転送を再開できます（MAY）。同様に、出力PEノード保護とS-PEノード保護では、プライマリPEが復元されたことを検出すると、PLRはトランスポートトンネルをプライマリPEに再確立して、トラフィックをバイパストンネルからトランスポートトンネルに戻してもよい（MAY）。これらの手順は、ローカル復帰と呼ばれます。
It is RECOMMENDED that the fast protection mechanism SHOULD be used in conjunction with global repair. Particularly in the case of egress PE and S-PE node failures, if the ingress PE or the protector loses communication with the egress PE or S-PE for an extensive period of time, the LDP session may go down. Consequently, the ingress PE may bring down the primary PW completely, or the protector may remove the forwarding entry of the primary PW label. In either case, the service will be disrupted. In other words, although the mechanism can temporarily repair traffic, control-plane state may eventually expire if the failure persists. Therefore, global repair SHOULD take place in a timely manner to move traffic to a fully functional alternative path.
高速保護メカニズムは、グローバル修復と組み合わせて使用する必要があります（SHOULD）。特に、出力PEおよびS-PEノードに障害が発生した場合、入力PEまたはプロテクターが長期間にわたって出力PEまたはS-PEとの通信を失うと、LDPセッションがダウンする可能性があります。その結果、入力PEがプライマリPWを完全にダウンさせるか、プロテクターがプライマリPWラベルの転送エントリを削除する場合があります。どちらの場合も、サービスが中断されます。つまり、メカニズムは一時的にトラフィックを修復できますが、障害が続く場合、コントロールプレーンの状態が最終的に期限切れになる可能性があります。したがって、グローバルな修復は、トラフィックを完全に機能する代替パスに移動するために適時に行われる必要があります（SHOULD）。
Control-plane convergence may automatically happen as control-plane protocols react to the new topology. However, it is only applicable to the specific link failure scenario described above.
コントロールプレーンプロトコルは、新しいトポロジに反応するため、コントロールプレーンの収束が自動的に行われる場合があります。ただし、これは上記の特定のリンク障害シナリオにのみ適用されます。
Local reversion is optional. In the circumstances where the failure is caused by resource flapping, local reversion MAY be dampened to limit potential disruption. Local reversion MAY be disabled completely by configuration.
ローカル復帰はオプションです。リソースのフラッピングが原因で障害が発生している状況では、ローカルでの復帰を抑制して、発生する可能性のある中断を制限することができます。ローカル復帰は、設定によって完全に無効化される場合があります。
As described in previous sections, a targeted LDP session MUST be established between each pair of primary PE and protector. The primary PE sends a Label Mapping message over this session to advertise primary PW labels to the protector. In the centralized protector model, a targeted LDP session MUST also be established between a backup (S-)PE and the protector. The backup PE sends a Label Mapping message over this session to advertise backup PW labels to the protector.
前のセクションで説明したように、ターゲットのLDPセッションは、プライマリPEとプロテクターの各ペア間に確立する必要があります。プライマリPEは、このセッションでラベルマッピングメッセージを送信して、プライマリPWラベルをプロテクターにアドバタイズします。集中型プロテクターモデルでは、バックアップ（S-）PEとプロテクターの間でターゲットLDPセッションも確立する必要があります。バックアップPEは、このセッションでラベルマッピングメッセージを送信して、バックアップPWラベルをプロテクターにアドバタイズします。
To support the procedures, this document defines a new "Protection FEC Element" TLV. The Label Mapping messages of both the LDP sessions above MUST carry this TLV to identify a primary PW. Specifically, in the centralized protector model, the Protection FEC Element TLV advertised by a backup (S-)PE MUST match the one advertised by the primary PE, so that the protector can associate the primary PW's label with the backup PW's label and perform a label swap. The backup (S-)PE builds such a Protection FEC Element TLV based on local configuration.
手順をサポートするために、このドキュメントでは新しい「保護FEC要素」TLVを定義しています。上記の両方のLDPセッションのラベルマッピングメッセージは、プライマリPWを識別するためにこのTLVを運ぶ必要があります。具体的には、集中型プロテクターモデルでは、バックアップ（S-）PEによってアドバタイズされた保護FECエレメントTLVは、プライマリPEによってアドバタイズされたものと一致する必要があるため、プロテクターはプライマリPWのラベルをバックアップPWのラベルに関連付けて、ラベルの交換。バックアップ（S-）PEは、ローカル構成に基づいて、このような保護FECエレメントTLVを構築します。
This document also defines a new "Egress Protection Capability" TLV as a new type of Capability Parameter TLV [RFC5561], to allow a protector to announce its capability of processing the above Protection FEC Element TLV and performing context-specific label switching for PW labels.
このドキュメントでは、新しい「出力保護機能」TLVを新しいタイプの機能パラメータTLV [RFC5561]として定義し、保護者が上記の保護FECエレメントTLVを処理し、PWラベルのコンテキスト固有のラベルスイッチングを実行する機能を発表できるようにしています。 。
The procedures in this section are only applicable if the protector advertises the Egress Protection Capability TLV, the primary PE supports the advertisement of the Protection FEC Element TLV, and in the centralized protector model, the backup PE also supports the advertisement of the Protection FEC Element TLV.
このセクションの手順は、プロテクターが出力保護機能TLVをアドバタイズし、プライマリPEが保護FECエレメントTLVのアドバタイズをサポートし、集中プロテクターモデルでは、バックアップPEが保護FECエレメントのアドバタイズもサポートする場合にのみ適用されます。 TLV。
A protector MUST advertise the Egress Protection Capability TLV in its Initialization message and Capability message over the LDP session with a primary PE. In the centralized protector model, the protector MUST also advertise the TLV over the LDP session with a backup PE. The TLV carries one or multiple context identifiers. To the primary PE, the TLV MUST carry the context identifier of the {primary PE, protector}. In the centralized protector model, the TLV MUST carry multiple context identifiers to the backup PE, one for each {primary PE, protector} where the backup PE serves as a backup for the primary PE. This TLV MUST NOT be advertised by the primary PE or the backup PE to the protector.
プロテクターは、プライマリPEとのLDPセッションを介して、初期化メッセージと機能メッセージで出力保護機能TLVを通知する必要があります。集中型プロテクターモデルでは、プロテクターはバックアップPEとのLDPセッションを介してTLVも通知する必要があります。 TLVは1つまたは複数のコンテキスト識別子を伝達します。プライマリPEに対して、TLVは{プライマリPE、プロテクター}のコンテキスト識別子を伝達する必要があります。集中型プロテクターモデルでは、TLVは複数のコンテキスト識別子をバックアップPEに運ぶ必要があります。{プライマリPE、プロテクター}ごとに1つ、バックアップPEがプライマリPEのバックアップとして機能します。このTLVは、プライマリPEまたはバックアップPEによってプロテクターにアドバタイズされてはなりません。
The processing of the Egress Protection Capability TLV by a receiving router MUST follow the procedures defined in [RFC5561]. In particular, the router MUST advertise PW information to the protector by using the Protection FEC Element TLV, only after it has received the Egress Protection Capability TLV from the protector. It MUST validate each context identifier included in the TLV and advertise the information of only the PWs that are associated with the context identifier. It MUST withdraw previously advertised Protection FEC TLVs, when the protector has withdrawn a previously advertised context identifier or the entire Egress Protection Capability TLV via a Capability message.
受信ルータによる出力保護機能TLVの処理は、[RFC5561]で定義された手順に従う必要があります。特に、ルーターは、プロテクターから出力保護機能TLVを受信した後でのみ、保護FECエレメントTLVを使用してPW情報をプロテクターに通知する必要があります。 TLVに含まれる各コンテキスト識別子を検証し、コンテキスト識別子に関連付けられているPWのみの情報を通知する必要があります。機能メッセージを介してプロテクターが以前にアドバタイズされたコンテキスト識別子または出力保護機能TLV全体を取り下げた場合、以前にアドバタイズされた保護FEC TLVを取り消す必要があります。
The encoding of the Egress Protection Capability TLV is defined below. It conforms to the format of Capability Parameter TLV specified in [RFC5561].
Egress Protection Capability TLVのエンコーディングは以下に定義されています。これは、[RFC5561]で指定されている機能パラメータTLVの形式に準拠しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Egress Protection (0x0974)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |
+-+-+-+-+-+-+-+-+ |
| |
~ Capability Data = context identifier(s) ~
| |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15
図15
The U-bit MUST be set to 1, so that a receiver MUST silently ignore this TLV if unknown to it and continue processing the rest of the message.
Uビットを1に設定する必要があるため、受信者は、このTLVが不明な場合は黙って無視し、メッセージの残りの処理を続行する必要があります。
The F-bit MUST be set to 0 since this TLV is sent only in Initialization and Capability messages, which are not forwarded.
このTLVは初期化メッセージと機能メッセージでのみ送信され、転送されないため、Fビットは0に設定する必要があります。
The TLV code point is 0x0974.
TLVコードポイントは0x0974です。
The S-bit indicates whether the sender is advertising (S=1) or withdrawing (S=0) the capability.
Sビットは、送信側が機能をアドバタイズしているか（S = 1）、撤回しているか（S = 0）を示します。
The Capability Data field is encoded with the context identifiers of the {primary PE, protector} pairs for which the advertiser is the protector.
Capability Dataフィールドは、広告主がプロテクターである{プライマリPE、プロテクター}ペアのコンテキスト識別子でエンコードされます。
A primary PE MUST advertise a primary PW's label to a protector by sending a Label Mapping message. The message includes a Protection FEC Element TLV (see Section 6.4 for encoding) and an Upstream-Assigned Label TLV [RFC6389] encoded with the PW's label. The combination of the Protection FEC Element TLV and the PW label represents the primary PE's forwarding state for the PW. The Label Mapping message MUST also carry an IPv4/v6 Interface_ID TLV [RFC3471] [RFC6389] encoded with the context identifier of the {primary PE, protector}.
プライマリPEは、ラベルマッピングメッセージを送信して、プライマリPWのラベルをプロテクターに通知しなければなりません（MUST）。メッセージには、保護FECエレメントTLV（エンコードについてはセクション6.4を参照）と、PWのラベルでエンコードされたアップストリーム割り当てラベルTLV [RFC6389]が含まれます。保護FECエレメントTLVとPWラベルの組み合わせは、PWのプライマリPEの転送状態を表します。ラベルマッピングメッセージは、{プライマリPE、プロテクター}のコンテキスト識別子でエンコードされたIPv4 / v6 Interface_ID TLV [RFC3471] [RFC6389]も運ぶ必要があります。
The protector that receives this Label Mapping message MUST install a forwarding entry for the PW label in the label space identified by the context identifier. The next hop of the forwarding entry MUST ensure that packets are sent towards the target CE via a backup AC or a backup (S-)PE, depending on the protection scenario. The protector MUST silently discard a Label Mapping message if the included context identifier is unknown to it.
このラベルマッピングメッセージを受信したプロテクターは、コンテキスト識別子で識別されるラベルスペースにPWラベルの転送エントリをインストールする必要があります。転送エントリのネクストホップは、保護シナリオに応じて、パケットがバックアップACまたはバックアップ（S-）PEを介してターゲットCEに送信されるようにする必要があります。含まれるコンテキスト識別子が不明な場合、プロテクターはラベルマッピングメッセージを黙って破棄する必要があります。
In the centralized protector model, a backup PE MUST advertise a backup PW's label to the protector by sending a Label Mapping message. The message includes a Protection FEC Element TLV and a Generic Label TLV encoded with the backup PW's label. This Protection FEC Element MUST be identical to the Protection FEC Element TLV that the primary PE advertises to the protector (Section 6.2). This is achieved through configuration on the backup PE. The context identifier MUST NOT be encoded in an Interface_ID TLV in this message.
集中型プロテクターモデルでは、バックアップPEはラベルマッピングメッセージを送信して、バックアップPWのラベルをプロテクターに通知する必要があります。メッセージには、保護PEC要素TLVと、バックアップPWのラベルでエンコードされたジェネリックラベルTLVが含まれます。この保護FEC要素は、プライマリPEがプロテクターに通知する保護FEC要素TLVと同一である必要があります（セクション6.2）。これは、バックアップPEでの構成によって実現されます。コンテキスト識別子は、このメッセージのInterface_ID TLVにエンコードしてはなりません（MUST NOT）。
The protector that receives this Label Mapping message MUST associate the backup PW with the primary PW, based on the common Protection FEC Element TLV. It MUST distinguish between the Label Mapping message from the primary PE and the Label Mapping message from the backup PE based on the respective presence and absence of a context identifier in the Interface_ID TLV. It MUST install a forwarding entry for the primary PW's label in the label space identified by the context identifier. The next hop of the forwarding entry MUST indicate a label swap to the backup PW's label, followed by a label push or IP header push for a transport tunnel to the backup PE.
このラベルマッピングメッセージを受信するプロテクターは、共通の保護FECエレメントTLVに基づいて、バックアップPWをプライマリPWに関連付ける必要があります。 Interface_ID TLVのコンテキスト識別子の有無に基づいて、プライマリPEからのラベルマッピングメッセージとバックアップPEからのラベルマッピングメッセージを区別する必要があります。コンテキスト識別子で識別されるラベルスペースにプライマリPWのラベルの転送エントリをインストールする必要があります。転送エントリの次のホップは、バックアップPWのラベルへのラベルスワップを示し、その後に、バックアップPEへのトランスポートトンネルのラベルプッシュまたはIPヘッダープッシュが続く必要があります。
The Protection FEC Element TLV has type 0x83. Its format is defined below:
保護FECエレメントTLVのタイプは0x83です。そのフォーマットは以下に定義されています：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(0x83) | Reserved | Encoding Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
~ PW Information ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16
図16
- Encoding Type
- エンコーディングタイプ
Type of encoding format of the PW Information field. The following types are defined, corresponding to the PWid FEC Element and Generalized PWid FEC Element defined in [RFC8077].
PW情報フィールドのエンコード形式のタイプ。 [RFC8077]で定義されているPWid FEC要素と一般化されたPWid FEC要素に対応して、次のタイプが定義されています。
1 - PWid FEC Element with IPv4 PE addresses (Section 6.4.1).
1-IPv4 PEアドレスを持つPWid FEC要素（セクション6.4.1）。
2 - Generalized PWid FEC Element with IPv4 PE addresses (Section 6.4.2).
2-IPv4 PEアドレスを持つ一般化されたPWid FEC要素（セクション6.4.2）。
3 - PWid FEC Element with IPv6 PE addresses (Section 6.4.3).
3-IPv6 PEアドレスを持つPWid FEC要素（セクション6.4.3）。
4 - Generalized PWid FEC Element with IPv6 PE addresses (Section 6.4.4).
4-IPv6 PEアドレスを持つ一般化されたPWid FEC要素（セクション6.4.4）。
- Length
- 長さ
Length of the PW Information field in octets.
オクテット単位のPW情報フィールドの長さ。
- PW Information
- ΠΩΙνφορματιον
Field of variable length that specifies a PW.
PWを指定する可変長のフィールド。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(0x83) | Reserved | Enc Type(1) | Length(20) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| PW Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17
図17
- Ingress PE IPv4 Address
- 入力PE IPv4アドレス
IPv4 address of the ingress PE of PW.
PWの入力PEのIPv4アドレス。
- Egress PE IPv4 Address
- 出力PE IPv4アドレス
IPv4 address of the egress PE of PW.
PWの出力PEのIPv4アドレス。
- Group ID
- グループID
An arbitrary 32-bit value that represents a group of PWs and that is used to create groups in the PW space.
PWのグループを表し、PWスペースでグループを作成するために使用される任意の32ビット値。
- PW ID
- PW ID
A non-zero 32-bit connection ID that, together with the PW Type field, identifies a particular PW.
PWタイプフィールドと共に特定のPWを識別するゼロ以外の32ビット接続ID。
- Control word bit (C)
- 制御ワードビット（C）
A bit that flags the presence of a control word on this PW. If C = 1, control word is present; if C = 0, control word is not present.
このPW上の制御ワードの存在にフラグを立てるビット。 C = 1の場合、制御ワードが存在します。 C = 0の場合、制御ワードは存在しません。
- PW Type
- PWタイプ
A 15-bit quantity that represents the type of PW.
PWのタイプを表す15ビットの数量。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(0x83) | Reserved | Enc Type(2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| PW Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18
図18
- Ingress PE IPv4 Address
- 入力PE IPv4アドレス
IPv4 address of the ingress PE of PW.
PWの入力PEのIPv4アドレス。
- Egress PE IPv4 Address
- 出力PE IPv4アドレス
IPv4 address of the egress PE of PW.
PWの出力PEのIPv4アドレス。
- Control word bit (C)
- コントロールワードビット（C）
A bit that flags the presence of a control word on this PW. If C = 1, control word is present; if C = 0, control word is not present.
このPW上の制御ワードの存在にフラグを立てるビット。 C = 1の場合、制御ワードが存在します。 C = 0の場合、制御ワードは存在しません。
- PW Type
- PWタイプ
A 15-bit quantity that represents the type of PW.
PWのタイプを表す15ビットの数量。
- AGI Type, Length, AGI Value
- AGIタイプ、長さ、AGI値
Attachment Group Identifier of PW.
PWの添付ファイルグループ識別子。
- AII Type, Length, SAII Value
- AIIタイプ、長さ、SAII値
Source Attachment Individual Identifier of PW.
PWのソースアタッチメント個別識別子。
- AII Type, Length, TAII Value
- AIIタイプ、長さ、TAII値
Target Attachment Individual Identifier of PW.
PWのターゲット添付ファイル個別ID。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(0x83) | Reserved | Enc Type(3) | Length(44) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Ingress PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Egress PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| PW Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19
図19
- Ingress PE IPv6 Address
- 入力PE IPv6アドレス
IPv6 address of the ingress PE of PW; 16 octets.
PWの入力PEのIPv6アドレス。 16オクテット。
- Egress PE IPv6 Address
- 出力PE IPv6アドレス
IPv6 address of the egress PE of PW; 16 octets.
PWの出力PEのIPv6アドレス。 16オクテット。
- Group ID
- グループID
An arbitrary 32-bit value that represents a group of PWs and that is used to create groups in the PW space.
PWのグループを表し、PWスペースでグループを作成するために使用される任意の32ビット値。
- PW ID
- PW ID
A non-zero 32-bit connection ID that, together with the PW Type field, identifies a particular PW.
PWタイプフィールドと共に特定のPWを識別するゼロ以外の32ビット接続ID。
- Control word bit (C)
- 制御ワードビット（C）
A bit that flags the presence of a control word on this PW. If C = 1, control word is present; if C = 0, control word is not present.
このPW上の制御ワードの存在にフラグを立てるビット。 C = 1の場合、制御ワードが存在します。 C = 0の場合、制御ワードは存在しません。
- PW Type
- PWタイプ
A 15-bit quantity that represents the type of PW.
PWのタイプを表す15ビットの数量。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(0x83) | Reserved | Enc Type(4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Ingress PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Egress PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| PW Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20
図20
- Ingress PE IPv6 Address
- 入力PE IPv6アドレス
IPv6 address of the ingress PE of PW; 16 octets.
PWの入力PEのIPv6アドレス。 16オクテット。
- Egress PE IPv6 Address
- 出力PE IPv6アドレス
IPv6 address of the egress PE of PW; 16 octets.
PWの出力PEのIPv6アドレス。 16オクテット。
- Control word bit (C)
- 制御ワードビット（C）
A bit that flags the presence of a control word on this PW. If C = 1, control word is present; if C = 0, control word is not present.
このPW上の制御ワードの存在にフラグを立てるビット。 C = 1の場合、制御ワードが存在します。 C = 0の場合、制御ワードは存在しません。
- PW Type
- PWタイプ
A 15-bit quantity that represents the type of PW.
PWのタイプを表す15ビットの数量。
- AGI Type, Length, AGI Value
- AGIタイプ、長さ、AGI値
Attachment Group Identifier of PW.
PWの添付ファイルグループ識別子。
- AII Type, Length, SAII Value
- AIIタイプ、長さ、SAII値
Source Attachment Individual Identifier of PW.
PWのソースアタッチメント個別識別子。
- AII Type, Length, TAII Value
- AIIタイプ、長さ、TAII値
Target Attachment Individual Identifier of PW.
PWのターゲット添付ファイル個別ID。
This document defines a new Egress Protection Capability TLV in Section 6. IANA has assigned value 0x0974 for it in the "TLV Type Name Space" registry.
このドキュメントでは、セクション6で新しいEgress Protection Capability TLVを定義しています。IANAは、「TLV Type Name Space」レジストリで値0x0974を割り当てています。
This document defines a new Protection FEC Element TLV in Section 6. IANA assigned value 0x83 for it in the "Forwarding Equivalence Class (FEC) Type Name Space" registry per RFC 7358. IANA has updated the registry to also reference this document.
このドキュメントでは、セクション6で新しい保護FECエレメントTLVを定義しています。RFC7358に基づく「転送等価クラス（FEC）タイプ名前空間」レジストリでIANAが値0x83を割り当てました。IANAは、このドキュメントを参照するようにレジストリを更新しました。
In this document, PW traffic can be temporarily rerouted by a PLR to a protector. In the centralized protector scenario, the traffic can be further rerouted to a backup PE. In the control plane, there is a targeted LDP session between a primary PE and a protector. In the centralized protector scenario, there is also a targeted LDP session between a backup PE and a protector. In all scenarios, traffic rerouting via PLRs, protectors, and backup PEs is planned and anticipated, and backup PEs can be used anyway to host PWs and LDP sessions. Hence, the rerouted traffic and the LDP sessions introduced in this document should not be viewed as a new security threat.
このドキュメントでは、PWトラフィックはPLRによって一時的にプロテクターに再ルーティングされます。一元化されたプロテクターのシナリオでは、トラフィックをさらにバックアップPEに再ルーティングできます。コントロールプレーンでは、プライマリPEとプロテクターの間にターゲットLDPセッションがあります。一元化されたプロテクターのシナリオでは、バックアップPEとプロテクターの間に対象を絞ったLDPセッションもあります。すべてのシナリオで、PLR、プロテクター、およびバックアップPEを介したトラフィックの再ルーティングが計画および予測されており、バックアップPEを使用してPWおよびLDPセッションをホストできます。したがって、このドキュメントで紹介されている再ルーティングされたトラフィックとLDPセッションは、新しいセキュリティの脅威と見なすべきではありません。
In general, [RFC5920] describes the security framework for MPLS networks. [RFC3209] describes the security considerations for RSVP Label Switched Paths (LSPs). [RFC5036] describes the security considerations for the base LDP specification. [RFC5561] describes the security considerations that apply when using the LDP capability mechanism. All these security frameworks and considerations apply to this document as well.
一般に、[RFC5920]はMPLSネットワークのセキュリティフレームワークについて説明しています。 [RFC3209]では、RSVPラベルスイッチドパス（LSP）のセキュリティに関する考慮事項について説明しています。 [RFC5036]は、基本LDP仕様のセキュリティに関する考慮事項を説明しています。 [RFC5561]では、LDP機能メカニズムを使用するときに適用されるセキュリティの考慮事項について説明しています。これらすべてのセキュリティフレームワークと考慮事項は、このドキュメントにも適用されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, <http://www.rfc-editor.org/info/rfc8077>.
[RFC8077]マティーニ、L。、エド。 and G. Heron、Ed。、 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol（LDP）"、STD 84、RFC 8077、DOI 10.17487 / RFC8077、February 2017、<http://www.rfc-editor.org/ info / rfc8077>。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <http://www.rfc-editor.org/info/rfc5331>.
[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLSアップストリームラベル割り当ておよびコンテキスト固有のラベルスペース」、RFC 5331、DOI 10.17487 / RFC5331、2008年8月、<http：//www.rfc -editor.org/info/rfc5331>。
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, DOI 10.17487/RFC5561, July 2009, <http://www.rfc-editor.org/info/rfc5561>.
[RFC5561]トーマス、B。、ラザ、K。、アガーワル、S。、アガーワル、R。、およびJL。 Le Roux、「LDP Capabilities」、RFC 5561、DOI 10.17487 / RFC5561、2009年7月、<http://www.rfc-editor.org/info/rfc5561>。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, <http://www.rfc-editor.org/info/rfc3471>.
[RFC3471] Berger、L.、Ed。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Functional Description」、RFC 3471、DOI 10.17487 / RFC3471、2003年1月、<http://www.rfc-editor.org/ info / rfc3471>。
[RFC3472] Ashwood-Smith, P., Ed. and L. Berger, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, DOI 10.17487/RFC3472, January 2003, <http://www.rfc-editor.org/info/rfc3472>.
[RFC3472] Ashwood-Smith、P.、Ed。およびL. Berger編、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Constraint-based Routed Label Distribution Protocol（CR-LDP）Extensions」、RFC 3472、DOI 10.17487 / RFC3472、2003年1月、<http：// www.rfc-editor.org/info/rfc3472>。
[RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, DOI 10.17487/RFC6389, November 2011, <http://www.rfc-editor.org/info/rfc6389>.
[RFC6389] Aggarwal、R.、JL。 Le Roux、「LDPのMPLSアップストリームラベル割り当て」、RFC 6389、DOI 10.17487 / RFC6389、2011年11月、<http://www.rfc-editor.org/info/rfc6389>。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, <http://www.rfc-editor.org/info/rfc4090>.
[RFC4090] Pan、P。、編、Swallow、G、編、A。Atlas、編、「LSPトンネル用のRSVP-TEへの高速リルート拡張」、RFC 4090、DOI 10.17487 / RFC4090、2005年5月、<http://www.rfc-editor.org/info/rfc4090>。
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, <http://www.rfc-editor.org/info/rfc5286>.
[RFC5286]アトラス、A。、エド。およびA. Zinin、編、「IP高速リルートの基本仕様：ループフリー代替」、RFC 5286、DOI 10.17487 / RFC5286、2008年9月、<http://www.rfc-editor.org/info/rfc5286> 。
[RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, <http://www.rfc-editor.org/info/rfc7812>.
[RFC7812] Atlas、A.、Bowers、C。、およびG. Enyedi、「最大冗長ツリー（MRT-FRR）を使用したIP / LDP高速リルートのアーキテクチャ」、RFC 7812、DOI 10.17487 / RFC7812、2016年6月、< http://www.rfc-editor.org/info/rfc7812>。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <http://www.rfc-editor.org/info/rfc3031>.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<http://www.rfc-editor.org/info / rfc3031>。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<http://www.rfc-editor.org/info/rfc5920>。
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <http://www.rfc-editor.org/info/rfc3985>.
[RFC3985]ブライアント、S。、エド。およびP. Pate、編、「疑似ワイヤーエミュレーションエッジツーエッジ（PWE3）アーキテクチャ」、RFC 3985、DOI 10.17487 / RFC3985、2005年3月、<http://www.rfc-editor.org/info/rfc3985 >。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<http://www.rfc-editor.org/info/rfc3209>。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、DOI 10.17487 / RFC5036、October 2007、<http：// www。 rfc-editor.org/info/rfc5036>。
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, DOI 10.17487/RFC5659, October 2009, <http://www.rfc-editor.org/info/rfc5659>.
[RFC5659] Bocci、M。、およびS. Bryant、「An-Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge」、RFC 5659、DOI 10.17487 / RFC5659、2009年10月、<http：//www.rfc-editor。 org / info / rfc5659>。
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, January 2010, <http://www.rfc-editor.org/info/rfc5714>.
[RFC5714] Shand、M。およびS. Bryant、「IP Fast Reroute Framework」、RFC 5714、DOI 10.17487 / RFC5714、2010年1月、<http://www.rfc-editor.org/info/rfc5714>。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <http://www.rfc-editor.org/info/rfc5880>.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、DOI 10.17487 / RFC5880、2010年6月、<http://www.rfc-editor.org/info/rfc5880>。
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5085]ナドー、T。、エド。およびC. Pignataro、編、「Pseudowire Virtual Circuit Connectivity Verification（VCCV）：A Control Channel for Pseudowires」、RFC 5085、DOI 10.17487 / RFC5085、2007年12月、<http://www.rfc-editor.org/info / rfc5085>。
[RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, DOI 10.17487/RFC5885, June 2010, <http://www.rfc-editor.org/info/rfc5885>.
[RFC5885]ナドー、T。、エド。およびC. Pignataro、Ed。、「Pseudowire Virtual Circuit Connectivity Verification（VCCV）のBidirectional Forwarding Detection（BFD）」、RFC 5885、DOI 10.17487 / RFC5885、2010年6月、<http://www.rfc-editor.org / info / rfc5885>。
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. Pallagatti, "Seamless Bidirectional Forwarding Detection (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, <http://www.rfc-editor.org/info/rfc7880>.
[RFC7880] Pignataro、C.、Ward、D.、Akiya、N.、Bhatia、M。、およびS. Pallagatti、「Seamless Bidirectional Forwarding Detection（S-BFD）」、RFC 7880、DOI 10.17487 / RFC7880、2016年7月、<http://www.rfc-editor.org/info/rfc7880>。
Acknowledgements
謝辞
This document leverages work done by Hannes Gredler, Yakov Rekhter, Minto Jeyananth, Kevin Wang, and several others on MPLS edge protection. Thanks to Nischal Sheth and Bhupesh Kothari for their contributions. Thanks to John E. Drake, Andrew G. Malis, Alexander Vainshtein, Stewart Bryant, and Mach(Guoyi) Chen for valuable comments that helped shape this document and improve its clarity.
このドキュメントは、MPLSエッジ保護に関して、Hannes Gredler、Yakov Rekhter、Minto Jeyananth、Kevin Wang、その他数人が行った作業を活用しています。 Nischal ShethとBhupesh Kothariの貢献に感謝します。このドキュメントを構成し、その明快さを改善するのに役立つ貴重なコメントを提供してくれたJohn E. Drake、Andrew G. Malis、Alexander Vainshtein、Stewart Bryant、およびMach（Guoyi）Chenに感謝します。
Authors' Addresses
著者のアドレス
Yimin Shen Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States of America
Yimin Shen Juniper Networks 10 Technology Park Drive Westford、MA 01886アメリカ合衆国
Phone: +1 9785890722
Email: yshen@juniper.net
Rahul Aggarwal Arktan, Inc.
Rahul Aggarwal Arktan、Inc.
Email: raggarwa_1@yahoo.com
Wim Henderickx Nokia Copernicuslaan 50 2018 Antwerp Belgium
Wim Henderickx Nokia Copernicuslaan 50 2018アントワープベルギー
Email: wim.henderickx@nokia.com
Yuanlong Jiang Huawei Technologies Co., Ltd. Bantian, Longgang district Shenzhen 518129 China
Yuanlong Jiang hu Aはテクノロジー株式会社の禁止日であり、長いギャング地区は非常に現実的です518129中国
Email: jiangyuanlong@huawei.com