[要約] RFC 8679は、MPLSネットワークにおける出口保護のためのフレームワークを提供しています。その目的は、ネットワークの冗長性を向上させ、トラフィックのロードバランシングと高い可用性を実現することです。
Internet Engineering Task Force (IETF) Y. Shen
Request for Comments: 8679 M. Jeyananth
Category: Standards Track Juniper Networks
ISSN: 2070-1721 B. Decraene
Orange
H. Gredler
RtBrick Inc.
C. Michel
Deutsche Telekom
H. Chen
Futurewei
December 2019
MPLS Egress Protection Framework
MPLS出力保護フレームワーク
Abstract
概要
This document specifies a fast reroute framework for protecting IP/ MPLS services and MPLS transport tunnels against egress node and egress link failures. For each type of egress failure, it defines the roles of Point of Local Repair (PLR), protector, and backup egress router and the procedures of establishing a bypass tunnel from a PLR to a protector. It describes the behaviors of these routers in handling an egress failure, including local repair on the PLR and context-based forwarding on the protector. The framework can be used to develop egress protection mechanisms to reduce traffic loss before global repair reacts to an egress failure and control-plane protocols converge on the topology changes due to the egress failure.
このドキュメントでは、出力ノードと出力リンクの障害からIP / MPLSサービスとMPLSトランスポートトンネルを保護するための高速再ルーティングフレームワークについて説明します。出力障害のタイプごとに、Point of Local Repair（PLR）、プロテクター、およびバックアップ出力ルーターの役割と、PLRからプロテクターへのバイパストンネルを確立する手順を定義します。 PLRのローカル修復やプロテクターのコンテキストベースの転送など、出力障害の処理におけるこれらのルーターの動作について説明します。このフレームワークを使用して、グローバルな修復が出力の失敗に反応し、コントロールプレーンプロトコルが出力の失敗によるトポロジの変更に収束する前に、トラフィックの損失を減らす出力保護メカニズムを開発できます。
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 https://www.rfc-editor.org/info/rfc8679.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8679で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Specification of Requirements
3. Terminology
4. Requirements
5. Egress Node Protection
5.1. Reference Topology
5.2. Egress Node Failure and Detection
5.3. Protector and PLR
5.4. Protected Egress
5.5. Egress-Protected Tunnel and Service
5.6. Egress-Protection Bypass Tunnel
5.7. Context ID, Context Label, and Context-Based Forwarding
5.8. Advertisement and Path Resolution for Context ID
5.9. Egress-Protection Bypass Tunnel Establishment
5.10. Local Repair on PLR
5.11. Service Label Distribution from Egress Router to Protector
5.12. Centralized Protector Mode
6. Egress Link Protection
7. Global Repair
8. Operational Considerations
9. General Context-Based Forwarding
10. Example: Layer 3 VPN Egress Protection
10.1. Egress Node Protection
10.2. Egress Link Protection
10.3. Global Repair
10.4. Other Modes of VPN Label Allocation
11. IANA Considerations
12. Security Considerations
13. References
13.1. Normative References
13.2. Informative References
Acknowledgements
Authors' Addresses
In MPLS networks, Label Switched Paths (LSPs) are widely used as transport tunnels to carry IP and MPLS services across MPLS domains. Examples of MPLS services are Layer 2 VPNs, Layer 3 VPNs, hierarchical LSPs, and others. In general, a tunnel may carry multiple services of one or multiple types, if the tunnel satisfies both individual and aggregate requirements (e.g., Class of Service (CoS) and QoS) of these services. The egress router of the tunnel hosts the service instances of the services. An MPLS service instance forwards service packets via an egress link to the service destination, based on a service label. An IP service instance does the same, based on an IP service address. The egress link is often called a Provider Edge - Customer Edge (PE-CE) link or Attachment Circuit (AC).
MPLSネットワークでは、ラベルスイッチドパス（LSP）は、MPLSドメイン間でIPおよびMPLSサービスを伝送するトランスポートトンネルとして広く使用されています。 MPLSサービスの例には、レイヤー2 VPN、レイヤー3 VPN、階層型LSPなどがあります。一般的に、トンネルは、これらのサービスの個々の要件とサービス要件（CoS）やQoSなどの要件の両方を満たす場合、1つまたは複数のタイプの複数のサービスを伝送します。トンネルの出口ルーターは、サービスのサービスインスタンスをホストします。 MPLSサービスインスタンスは、サービスラベルに基づいて、出力リンクを介してサービスの宛先にサービスパケットを転送します。 IPサービスインスタンスは、IPサービスアドレスに基づいて同じことを行います。出力リンクは、プロバイダーエッジ-カスタマーエッジ（PE-CE）リンクまたは接続回線（AC）と呼ばれることがよくあります。
Today, local-repair-based fast reroute mechanisms (see [RFC4090], [RFC5286], [RFC7490], and [RFC7812]) have been widely deployed to protect MPLS tunnels against transit link/node failures, with traffic restoration time in the order of tens of milliseconds. Local repair refers to the scenario where the router upstream to an anticipated failure, a.k.a., PLR, pre-establishes a bypass tunnel to the router downstream of the failure, a.k.a., Merge Point (MP), pre-installs the forwarding state of the bypass tunnel in the data plane, and uses a rapid mechanism (e.g., link-layer Operations, Administration, and Maintenance (OAM), Bidirectional Forwarding Detection (BFD), and others) to locally detect the failure in the data plane. When the failure occurs, the PLR reroutes traffic through the bypass tunnel to the MP, allowing the traffic to continue to flow to the tunnel's egress router.
今日、ローカル修復ベースの高速リルートメカニズム（[RFC4090]、[RFC5286]、[RFC7490]、および[RFC7812]を参照）が広く導入されており、トランジットリンク/ノードの障害からMPLSトンネルを保護し、数十ミリ秒のオーダー。ローカル修復とは、予想される障害の上流にあるルーター（別名、PLR）が、障害の下流のルーター（別名、マージポイント（MP））へのバイパストンネルを事前に確立し、バイパスの転送状態を事前にインストールするシナリオを指します。データプレーン内のトンネル。迅速なメカニズム（リンク層の運用、管理、保守（OAM）、双方向転送検出（BFD）など）を使用して、データプレーンの障害をローカルで検出します。障害が発生すると、PLRはバイパストンネルを介してトラフィックをMPに再ルーティングし、トラフィックがトンネルの出力ルーターに流れ続けるようにします。
This document specifies a fast reroute framework for egress node and egress link protection. Similar to transit link/node protection, this framework also relies on a PLR to perform local failure detection and local repair. In egress node protection, the PLR is the penultimate hop router of a tunnel. In egress link protection, the PLR is the egress router of the tunnel. The framework further uses a so-called "protector" to serve as the tail end of a bypass tunnel. The protector is a router that hosts "protection service instances" and has its own connectivity or paths to service destinations. When a PLR does local repair, the protector performs "context label switching" for rerouted MPLS service packets and "context IP forwarding" for rerouted IP service packets, to allow the service packets to continue to reach the service destinations.
このドキュメントでは、出力ノードと出力リンクの保護のための高速リルートフレームワークについて説明します。中継リンク/ノード保護と同様に、このフレームワークもPLRに依存してローカルの障害検出とローカルの修復を実行します。出力ノード保護では、PLRはトンネルの最後から2番目のホップルーターです。出力リンク保護では、PLRはトンネルの出力ルーターです。フレームワークはさらに、いわゆる「プロテクター」を使用して、バイパストンネルのテールエンドとして機能します。プロテクターは、「保護サービスインスタンス」をホストするルーターであり、サービスの宛先への独自の接続またはパスを持っています。 PLRがローカル修復を行う場合、プロテクターは、再ルーティングされたMPLSサービスパケットに対して「コンテキストラベルスイッチング」を実行し、再ルーティングされたIPサービスパケットに対して「コンテキストIP転送」を実行して、サービスパケットがサービス宛先に到達し続けることを許可します。
This framework considers an egress node failure as a failure of a tunnel and a failure of all the services carried by the tunnel as service packets that can no longer reach the service instances on the egress router. Therefore, the framework addresses egress node protection at both the tunnel level and service level, simultaneously. Likewise, the framework considers an egress link failure as a failure of all the services traversing the link and addresses egress link protection at the service level.
このフレームワークは、出力ノードの障害をトンネルの障害と見なし、トンネルによって運ばれるすべてのサービスの障害を、出力ルーターのサービスインスタンスに到達できなくなったサービスパケットと見なします。したがって、フレームワークは、トンネルレベルとサービスレベルの両方で同時に出口ノード保護に対処します。同様に、フレームワークは、出力リンクの障害を、リンクを通過するすべてのサービスの障害と見なし、サービスレベルで出力リンク保護に対処します。
This framework requires that the destination (a CE or site) of a service MUST be dual-homed or have dual paths to an MPLS network, via two MPLS edge routers. One of the routers is the egress router of the service's transport tunnel, and the other is a backup egress router that hosts a "backup service instance". In the "co-located" protector mode in this document, the backup egress router serves as the protector; hence, the backup service instance acts as the protection service instance. In the "centralized" protector mode (Section 5.12), the protector and the backup egress router are decoupled, and the protection service instance and the backup service instance are hosted separately by the two routers.
このフレームワークでは、サービスの宛先（CEまたはサイト）がデュアルホームであるか、2つのMPLSエッジルーター経由でMPLSネットワークへのデュアルパスを持っている必要があります。ルーターの1つはサービスのトランスポートトンネルの出力ルーターで、もう1つは「バックアップサービスインスタンス」をホストするバックアップ出力ルーターです。このドキュメントの「共存」プロテクターモードでは、バックアップ出力ルーターがプロテクターとして機能します。したがって、バックアップサービスインスタンスは保護サービスインスタンスとして機能します。 「集中型」プロテクターモード（セクション5.12）では、プロテクターとバックアップ出力ルーターは分離され、保護サービスインスタンスとバックアップサービスインスタンスは2つのルーターによって別々にホストされます。
The framework is described by mainly referring to point-to-point (P2P) tunnels. However, it is equally applicable to point-to-multipoint (P2MP), multipoint-to-point (MP2P), and multipoint-to-multipoint (MP2MP) tunnels, as the sub-LSPs of these tunnels can be viewed as P2P tunnels.
フレームワークは、主にポイントツーポイント（P2P）トンネルを参照して説明されています。ただし、ポイントツーマルチポイント（P2MP）、マルチポイントツーポイント（MP2P）、およびマルチポイントツーマルチポイント（MP2MP）トンネルにも同様に適用できます。これらのトンネルのサブLSPはP2Pトンネルとして表示できるためです。 。
The framework is a multi-service and multi-transport framework. It assumes a generic model where each service is comprised of a common set of components, including a service instance, a service label, a service label distribution protocol, and an MPLS transport tunnel. The framework also assumes that the service label is downstream assigned, i.e., assigned by an egress router. Therefore, the framework is generally applicable to most existing and future services. However, there are services with certain modes, where a protector is unable to pre-establish the forwarding state for egress protection, or a PLR is not allowed to reroute traffic to other routers in order to avoid traffic duplication, e.g., the broadcast, multicast, and unknown unicast traffic in Virtual Private LAN Service (VPLS) and Ethernet VPN (EVPN). These cases are left for future study. Services that use upstream-assigned service labels are also out of scope of this document and left for future study.
フレームワークは、マルチサービスとマルチトランスポートのフレームワークです。各サービスは、サービスインスタンス、サービスラベル、サービスラベル配布プロトコル、MPLSトランスポートトンネルなどの共通のコンポーネントセットで構成される一般的なモデルを想定しています。フレームワークは、サービスラベルがダウンストリームに割り当てられている、つまり、出口ルーターによって割り当てられていることも前提としています。したがって、フレームワークは一般に、ほとんどの既存および将来のサービスに適用できます。ただし、特定のモードのサービスがあり、プロテクターが出力保護のために転送状態を事前に確立できない、またはトラフィックの重複を回避するためにPLRがトラフィックを他のルーターに再ルーティングできない（ブロードキャスト、マルチキャストなど）。 、および仮想プライベートLANサービス（VPLS）とイーサネットVPN（EVPN）の不明なユニキャストトラフィック。これらのケースは将来の研究に残されています。アップストリームに割り当てられたサービスラベルを使用するサービスも、このドキュメントの範囲外であり、今後の調査に残します。
The framework does not require extensions for the existing signaling and label distribution protocols (e.g., RSVP, LDP, BGP, etc.) of MPLS tunnels. It assumes that transport tunnels and bypass tunnels are to be established by using the generic procedures provided by the protocols. On the other hand, it does not preclude extensions to the protocols that may facilitate the procedures. One example of such extension is [RFC8400]. The framework does see the need for extensions of IGPs and service label distribution protocols in some procedures, particularly for supporting protection establishment and context label switching. This document provides guidelines for these extensions, but it leaves the specific details to separate documents.
フレームワークは、MPLSトンネルの既存のシグナリングおよびラベル配布プロトコル（RSVP、LDP、BGPなど）の拡張を必要としません。プロトコルで提供される一般的な手順を使用して、トランスポートトンネルとバイパストンネルが確立されることを前提としています。一方、手順を容易にするプロトコルへの拡張を排除するものではありません。そのような拡張の一例は[RFC8400]です。フレームワークでは、特に保護の確立とコンテキストラベルの切り替えをサポートするために、一部の手順でIGPとサービスラベル配布プロトコルの拡張の必要性を認識しています。このドキュメントでは、これらの拡張機能のガイドラインを提供しますが、具体的な詳細は別のドキュメントに残します。
The framework is intended to complement control-plane convergence and global repair. Control-plane convergence relies on control protocols to react on the topology changes due to a failure. Global repair relies on an ingress router to remotely detect a failure and switch traffic to an alternative path. An example of global repair is the BGP prefix independent convergence mechanism [BGP-PIC] for BGP-established services. Compared with these mechanisms, this framework is considered faster in traffic restoration, due to the nature of local failure detection and local repair. It is RECOMMENDED that the framework be used in conjunction with control-plane convergence or global repair, in order to take the advantages of both approaches. That is, the framework provides fast and temporary repair, while control-plane convergence or global repair provides ultimate and permanent repair.
このフレームワークは、コントロールプレーンの収束とグローバルな修復を補完することを目的としています。コントロールプレーンコンバージェンスは、障害によるトポロジーの変化に対応するために、制御プロトコルに依存しています。グローバルな修復は、入力ルーターを使用してリモートで障害を検出し、トラフィックを代替パスに切り替えます。グローバルな修復の例は、BGPが確立したサービスのBGPプレフィックスに依存しない収束メカニズム[BGP-PIC]です。これらのメカニズムと比較して、このフレームワークはローカルの障害検出とローカルの修復の性質により、トラフィックの復元においてより高速であると見なされています。両方のアプローチの利点を活用するために、フレームワークをコントロールプレーンの収束またはグローバルな修復と組み合わせて使用することをお勧めします。つまり、フレームワークは高速で一時的な修復を提供し、コントロールプレーンの収束またはグローバルな修復は最終的な永続的な修復を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Egress router: A router at the egress endpoint of a tunnel. It hosts service instances for all the services carried by the tunnel and has connectivity with the destinations of the services.
出口ルーター：トンネルの出口エンドポイントにあるルーター。トンネルによって運ばれるすべてのサービスのサービスインスタンスをホストし、サービスの宛先と接続します。
Egress node failure: A failure of an egress router.
出力ノードの障害：出力ルーターの障害。
Egress link failure: A failure of the egress link (e.g., PE-CE link, attachment circuit) of a service.
出力リンク障害：サービスの出力リンク（PE-CEリンク、接続回線など）の障害。
Egress failure: An egress node failure or an egress link failure.
出力障害：出力ノード障害または出力リンク障害。
Egress-protected tunnel: A tunnel whose egress router is protected by a mechanism according to this framework. The egress router is hence called a protected egress router.
出力保護されたトンネル：このフレームワークによるメカニズムによって出力ルーターが保護されているトンネル。したがって、出力ルーターは、保護された出力ルーターと呼ばれます。
Egress-protected service: An IP or MPLS service that is carried by an egress-protected tunnel and hence protected by a mechanism according to this framework.
出力保護サービス：出力保護トンネルによって運ばれ、このフレームワークによるメカニズムによって保護されるIPまたはMPLSサービス。
Backup egress router: Given an egress-protected tunnel and its egress router, this is another router that has connectivity with all or a subset of the destinations of the egress-protected services carried by the egress-protected tunnel.
バックアップ出力ルーター：出力保護されたトンネルとその出力ルーターが与えられた場合、これは、出力保護されたトンネルによって運ばれる出力保護されたサービスの宛先のすべてまたはサブセットと接続する別のルーターです。
Backup service instance: A service instance that is hosted by a backup egress router and corresponds to an egress-protected service on a protected egress router.
バックアップサービスインスタンス：バックアップ出力ルーターによってホストされ、保護された出力ルーター上の出力保護されたサービスに対応するサービスインスタンス。
Protector: A role acted by a router as an alternate of a protected egress router, to handle service packets in the event of an egress failure. A protector may be physically co-located with or decoupled from a backup egress router, depending on the co-located or centralized protector mode.
プロテクター：出力障害が発生した場合にサービスパケットを処理するために、保護された出力ルーターの代替としてルーターによって機能する役割。プロテクターは、同じ場所に配置されているか集中型のプロテクターモードに応じて、バックアップ出力ルーターと物理的に同じ場所に配置されているか、または分離されている場合があります。
Protection service instance: A service instance hosted by a protector that corresponds to the service instance of an egress-protected service on a protected egress router. A protection service instance is a backup service instance, if the protector is co-located with a backup egress router.
保護サービスインスタンス：保護された出力ルーター上の出力保護サービスのサービスインスタンスに対応するプロテクターによってホストされるサービスインスタンス。プロテクターがバックアップ出力ルーターと同じ場所に配置されている場合、保護サービスインスタンスはバックアップサービスインスタンスです。
PLR: A router at the point of local repair. In egress node protection, it is the penultimate hop router on an egress-protected tunnel. In egress link protection, it is the egress router of the egress-protected tunnel.
PLR：ローカル修理の時点でのルーター。出力ノード保護では、これは出力保護トンネル上の最後から2番目のホップルーターです。出力リンク保護では、これは出力保護トンネルの出力ルーターです。
Protected egress {E, P}: A virtual node consisting of an ordered pair of egress router E and protector P. It serves as the virtual destination of an egress-protected tunnel and as the virtual location of the egress-protected services carried by the tunnel.
保護された出力{E、P}：順序付けられたペアの出力ルーターEとプロテクターPで構成される仮想ノード。これは、出力保護されたトンネルの仮想宛先として、また、トンネル。
Context identifier (ID): A globally unique IP address assigned to a protected egress {E, P}.
コンテキスト識別子（ID）：保護された出口{E、P}に割り当てられたグローバルに一意のIPアドレス。
Context label: A non-reserved label assigned to a context ID by a protector.
コンテキストラベル：プロテクターによってコンテキストIDに割り当てられる予約されていないラベル。
Egress-protection bypass tunnel: A tunnel used to reroute service packets around an egress failure.
出力保護バイパストンネル：出力障害を回避してサービスパケットを再ルーティングするために使用されるトンネル。
Co-located protector mode: The scenario where a protector and a backup egress router are co-located as one router; hence, each backup service instance serves as a protection service instance.
同じ場所に配置されたプロテクターモード：プロテクターとバックアップ出力ルーターが1つのルーターとして同じ場所に配置されるシナリオ。したがって、各バックアップサービスインスタンスは、保護サービスインスタンスとして機能します。
Centralized protector mode: The scenario where a protector is a dedicated router and is decoupled from backup egress routers.
集中プロテクターモード：プロテクターが専用ルーターであり、バックアップ出力ルーターから切り離されているシナリオ。
Context label switching: Label switching performed by a protector in the label space of an egress router indicated by a context label.
コンテキストラベルスイッチング：コンテキストラベルによって示される出力ルーターのラベルスペースでプロテクターによって実行されるラベルスイッチング。
Context IP forwarding: IP forwarding performed by a protector in the IP address space of an egress router indicated by a context label.
コンテキストIP転送：コンテキストラベルで示される出力ルーターのIPアドレス空間でプロテクターによって実行されるIP転送。
This document considers the following as the design requirements of this egress protection framework.
このドキュメントでは、この出力保護フレームワークの設計要件として次のことを考慮しています。
* The framework must support P2P tunnels. It should equally support P2MP, MP2P, and MP2MP tunnels, by treating each sub-LSP as a P2P tunnel.
* フレームワークはP2Pトンネルをサポートする必要があります。各サブLSPをP2Pトンネルとして扱うことにより、P2MP、MP2P、およびMP2MPトンネルを等しくサポートする必要があります。
* The framework must support multi-service and multi-transport networks. It must accommodate existing and future signaling and label-distribution protocols of tunnels and bypass tunnels, including RSVP, LDP, BGP, IGP, Segment Routing, and others. It must also accommodate existing and future IP/MPLS services, including Layer 2 VPNs, Layer 3 VPNs, hierarchical LSP, and others. It MUST provide a general solution for networks where different types of services and tunnels co-exist.
* フレームワークは、マルチサービスおよびマルチトランスポートネットワークをサポートする必要があります。 RSVP、LDP、BGP、IGP、セグメントルーティングなどを含む、トンネルおよびバイパストンネルの既存および将来のシグナリングおよびラベル配布プロトコルに対応する必要があります。また、レイヤ2 VPN、レイヤ3 VPN、階層型LSPなど、既存および将来のIP / MPLSサービスに対応する必要があります。異なるタイプのサービスとトンネルが共存するネットワークに一般的なソリューションを提供する必要があります。
* The framework must consider minimizing disruption during deployment. It should only involve routers close to the egress and be transparent to ingress routers and other transit routers.
* フレームワークは、展開中の混乱を最小限に抑えることを検討する必要があります。これは、出力に近いルーターのみを含み、入力ルーターと他の中継ルーターに対して透過的である必要があります。
* In egress node protection, for scalability and performance reasons, a PLR must be agnostic to services and service labels. It must maintain bypass tunnels and bypass forwarding state on a per-transport-tunnel basis rather than on a per-service-destination or per-service-label basis. It should also support bypass tunnel sharing between transport tunnels.
* 出力ノード保護では、スケーラビリティとパフォーマンスの理由から、PLRはサービスとサービスラベルに依存しない必要があります。バイパストンネルおよびバイパスフォワーディングステートを、サービス宛先ごとまたはサービスラベルごとではなく、トランスポートトンネルごとに維持する必要があります。また、トランスポートトンネル間のバイパストンネル共有もサポートする必要があります。
* A PLR must be able to use its local visibility or information of routing or TE topology to compute or resolve a path for a bypass tunnel.
* PLRは、バイパストンネルのパスを計算または解決するために、ローカルの可視性またはルーティングまたはTEトポロジの情報を使用できる必要があります。
* A protector must be able to perform context label switching for rerouted MPLS service packets, based on a service label(s) assigned by an egress router. It must be able to perform context IP forwarding for rerouted IP service packets, in the public or private IP address space used by an egress router.
* プロテクターは、出力ルーターによって割り当てられたサービスラベルに基づいて、再ルーティングされたMPLSサービスパケットのコンテキストラベルスイッチングを実行できる必要があります。出力ルーターが使用するパブリックまたはプライベートIPアドレス空間で、再ルーティングされたIPサービスパケットのコンテキストIP転送を実行できる必要があります。
* The framework must be able to work seamlessly with transit link/ node protection mechanisms to achieve end-to-end coverage.
* フレームワークは、トランジットリンク/ノード保護メカニズムとシームレスに連携して、エンドツーエンドのカバレッジを実現できる必要があります。
* The framework must be able to work in conjunction with global repair and control-plane convergence.
* フレームワークは、グローバルな修復とコントロールプレーンのコンバージェンスと連携して機能する必要があります。
This document refers to the following topology when describing the procedures of egress node protection.
このドキュメントでは、出力ノード保護の手順を説明するときに、次のトポロジを参照しています。
services 1, ..., N
=====================================> tunnel
I ------ R1 ------- PLR --------------- E ----
ingress penultimate hop egress \
| . (primary \
| . service \
| . instances ) \
| . \
| . \ service
| . destinations
| . / (CEs, sites)
| . /
| . bypass /
| . tunnel /
| . /
| ............... /
R2 --------------- P ----
protector
(protection
service
instances)
Figure 1
図1
An egress node failure refers to the failure of an MPLS tunnel's egress router. At the service level, it is also a service instance failure for each IP/MPLS service carried by the tunnel.
出力ノードの障害とは、MPLSトンネルの出力ルーターの障害を指します。サービスレベルでは、トンネルによって伝送される各IP / MPLSサービスのサービスインスタンス障害でもあります。
An egress node failure can be detected by an adjacent router (i.e., PLR in this framework) through a node liveness detection mechanism or a mechanism based on a collective failure of all the links to that node. The mechanisms MUST be reasonably fast, i.e., faster than control-plane failure detection and remote failure detection. Otherwise, local repair will not be able to provide much benefit compared to control-plane convergence or global repair. In general, the speed, accuracy, and reliability of a failure detection mechanism are the key factors to decide its applicability in egress node protection. This document provides the following guidelines for network operators to choose a proper type of protection on a PLR.
出口ノードの障害は、ノードの活性検出メカニズムまたはそのノードへのすべてのリンクの集合的な障害に基づくメカニズムを通じて、隣接するルーター（つまり、このフレームワークのPLR）によって検出できます。メカニズムはかなり高速でなければなりません。つまり、コントロールプレーンの障害検出やリモートの障害検出よりも高速でなければなりません。そうしないと、ローカルでの修理は、コントロールプレーンの収束やグローバルな修理に比べて大きなメリットを提供できません。一般に、障害検出メカニズムの速度、精度、および信頼性は、出力ノード保護での適用性を決定するための重要な要素です。このドキュメントは、ネットワークオペレーターがPLRで適切なタイプの保護を選択するための次のガイドラインを提供します。
* If the PLR has a mechanism to detect and differentiate a link failure (of the link between the PLR and the egress node) and an egress node failure, it SHOULD set up both link protection and egress node protection and trigger one and only one protection upon a corresponding failure.
* PLRに（PLRと出力ノード間のリンクの）リンク障害と出力ノード障害を検出して区別するメカニズムがある場合、リンク保護と出力ノード保護の両方をセットアップし、次の場合に1つだけの保護をトリガーする必要があります（SHOULD）。対応する障害。
* If the PLR has a fast mechanism to detect a link failure and an egress node failure, but it cannot distinguish them, or if the PLR has a fast mechanism to detect a link failure only, but not an egress node failure, the PLR has two options:
* PLRにリンク障害と出力ノード障害を検出するための高速メカニズムがあるが、それらを区別できない場合、またはPLRにリンク障害のみを検出するための高速メカニズムがあり、出力ノード障害はない場合、PLRには2つのオプション：
1. It MAY set up link protection only and leave the egress node failure to be handled by global repair and control-plane convergence.
1. リンク保護のみをセットアップして、グローバルな修復とコントロールプレーンコンバージェンスによって処理される出力ノード障害を残す場合があります。
2. It MAY set up egress node protection only and treat a link failure as a trigger for the egress node protection. The assumption is that treating a link failure as an egress node failure MUST NOT have a negative impact on services. Otherwise, it SHOULD adopt the previous option.
2. 出口ノード保護のみをセットアップして、リンク障害を出口ノード保護のトリガーとして扱う場合があります。リンク障害を出口ノード障害として扱うことは、サービスに悪影響を及ぼしてはならないという前提があります。それ以外の場合は、以前のオプションを採用する必要があります。
A router is assigned to the "protector" role to protect a tunnel and the services carried by the tunnel against an egress node failure. The protector is responsible for hosting a protection service instance for each protected service, serving as the tail end of a bypass tunnel, and performing context label switching and/or context IP forwarding for rerouted service packets.
ルーターは、トンネルとトンネルによって運ばれるサービスを出口ノードの障害から保護するための「プロテクター」の役割に割り当てられます。プロテクターは、保護された各サービスの保護サービスインスタンスをホストし、バイパストンネルのテールエンドとして機能し、再ルーティングされたサービスパケットのコンテキストラベルスイッチングやコンテキストIP転送を実行します。
A tunnel is protected by only one protector. Multiple tunnels to a given egress router may be protected by a common protector or different protectors. A protector may protect multiple tunnels with a common egress router or different egress routers.
トンネルは1つのプロテクターのみによって保護されます。特定の出力ルーターへの複数のトンネルは、共通のプロテクターまたは異なるプロテクターによって保護される場合があります。プロテクターは、共通の出口ルーターまたは異なる出口ルーターを使用して複数のトンネルを保護できます。
For each tunnel, its penultimate hop router acts as a PLR. The PLR pre-establishes a bypass tunnel to the protector and pre-installs bypass forwarding state in the data plane. Upon detection of an egress node failure, the PLR reroutes all the service packets received on the tunnel through the bypass tunnel to the protector. For MPLS service packets, the PLR keeps service labels intact in the packets. In turn, the protector forwards the service packets towards the ultimate service destinations. Specifically, it performs context label switching for MPLS service packets, based on the service labels assigned by the protected egress router; it performs context IP forwarding for IP service packets, based on their destination addresses.
各トンネルでは、最後から2番目のホップルーターがPLRとして機能します。 PLRは、プロテクターへのバイパストンネルを事前に確立し、データプレーンにバイパス転送状態を事前にインストールします。出力ノードの障害が検出されると、PLRは、バイパストンネルを介してトンネルで受信したすべてのサービスパケットをプロテクターに再ルーティングします。 MPLSサービスパケットの場合、PLRはパケット内のサービスラベルをそのまま保持します。次に、プロテクターはサービスパケットを最終的なサービス宛先に転送します。具体的には、保護された出力ルータによって割り当てられたサービスラベルに基づいて、MPLSサービスパケットのコンテキストラベルスイッチングを実行します。宛先アドレスに基づいて、IPサービスパケットのコンテキストIP転送を実行します。
The protector MUST have its own connectivity with each service destination, via a direct link or a multi-hop path, which MUST NOT traverse the protected egress router or be affected by the egress node failure. This also means that each service destination MUST be dual-homed or have dual paths to the egress router and a backup egress router that may serve as the protector. Each protection service instance on the protector relies on such connectivity to set up forwarding state for context label switching and context IP forwarding.
プロテクターは、直接リンクまたはマルチホップパスを介して、各サービス宛先との独自の接続を持っている必要があり、保護された出力ルーターを通過したり、出力ノードの障害の影響を受けてはなりません。これは、各サービスの宛先がデュアルホーム化されているか、保護機能として機能する出力ルーターとバックアップ出力ルーターへのデュアルパスを持つ必要があることも意味します。プロテクターの各保護サービスインスタンスは、このような接続に依存して、コンテキストラベルスイッチングとコンテキストIP転送の転送状態を設定します。
This document introduces the notion of "protected egress" as a virtual node consisting of the egress router E of a tunnel and a protector P. It is denoted by an ordered pair of {E, P}, indicating the primary-and-protector relationship between the two routers. It serves as the virtual destination of the tunnel and the virtual location of service instances for the services carried by the tunnel. The tunnel and services are considered as being "associated" with the protected egress {E, P}.
このドキュメントでは、トンネルの出口ルーターEとプロテクターPで構成される仮想ノードとしての「保護された出口」の概念を紹介します。これは、{E、P}の順序付きペアで示され、プライマリとプロテクターの関係を示します。 2つのルーター間。これは、トンネルの仮想宛先、およびトンネルによって伝送されるサービスのサービスインスタンスの仮想ロケーションとして機能します。トンネルとサービスは、保護された出口{E、P}に「関連付けられている」と見なされます。
A given egress router E may be the tail end of multiple tunnels. In general, the tunnels may be protected by multiple protectors, e.g., P1, P2, and so on, with each Pi protecting a subset of the tunnels. Thus, these routers form multiple protected egresses, i.e., {E, P1}, {E, P2}, and so on. Each tunnel is associated with one and only one protected egress {E, Pi}. All the services carried by the tunnel are then automatically associated with the protected egress {E, Pi}. Conversely, a service associated with a protected egress {E, Pi} MUST be carried by a tunnel associated with the protected egress {E, Pi}. This mapping MUST be ensured by the ingress router of the tunnel and the service (Section 5.5).
所定の出口ルーターEは、複数のトンネルの最後尾である場合があります。一般に、トンネルは複数のプロテクター（P1、P2など）によって保護され、各Piはトンネルのサブセットを保護します。したがって、これらのルーターは複数の保護された出口、つまり{E、P1}、{E、P2}などを形成します。各トンネルは、唯一の保護された出口{E、Pi}に関連付けられています。トンネルによって運ばれるすべてのサービスは、保護された出口{E、Pi}に自動的に関連付けられます。逆に、保護された出口{E、Pi}に関連付けられたサービスは、保護された出口{E、Pi}に関連付けられたトンネルによって伝送される必要があります。このマッピングは、トンネルの入口ルーターとサービスによって保証される必要があります（セクション5.5）。
The two routers X and Y may be protectors for each other. In this case, they form two distinct protected egresses: {X, Y} and {Y, X}.
2つのルーターXとYは、お互いを保護することができます。この場合、それらは2つの異なる保護された出口を形成します：{X、Y}および{Y、X}。
A tunnel, which is associated with a protected egress {E, P}, is called an egress-protected tunnel. It is associated with one and only one protected egress {E, P}. Multiple egress-protected tunnels may be associated with a given protected egress {E, P}. In this case, they share the common egress router and protector, but they may or may not share a common ingress router or a common PLR (i.e., penultimate hop router).
保護された出力{E、P}に関連付けられているトンネルは、出力保護されたトンネルと呼ばれます。 1つの保護された出口{E、P}に関連付けられています。複数の出力保護されたトンネルが、特定の保護された出力{E、P}に関連付けられている場合があります。この場合、それらは共通の出口ルーターとプロテクターを共有しますが、共通の入口ルーターまたは共通のPLR（つまり、最後から2番目のホップルーター）を共有する場合と共有しない場合があります。
An egress-protected tunnel is considered as logically "destined" for its protected egress {E, P}. Its path MUST be resolved and established with E as the physical tail end.
出力保護されたトンネルは、保護された出力{E、P}に対して論理的に「宛先」と見なされます。そのパスはEを物理的な末尾として解決し、確立する必要があります。
A service, which is associated with a protected egress {E, P}, is called an egress-protected service. Egress router E hosts the primary instance of the service, and protector P hosts the protection instance of the service.
保護された出力{E、P}に関連付けられているサービスは、出力保護サービスと呼ばれます。出力ルーターEはサービスのプライマリインスタンスをホストし、プロテクターPはサービスの保護インスタンスをホストします。
An egress-protected service is associated with one and only one protected egress {E, P}. Multiple egress-protected services may be associated with a given protected egress {E, P}. In this case, these services share the common egress router and protector, but they may or may not be carried by a common egress-protected tunnel or a common ingress router.
出力保護されたサービスは、唯一の保護された出力{E、P}に関連付けられています。複数の出力保護サービスが、特定の保護された出力{E、P}に関連付けられている場合があります。この場合、これらのサービスは共通の出口ルーターとプロテクターを共有しますが、それらは共通の出口保護トンネルまたは共通の入口ルーターによって運ばれる場合と運ばれない場合があります。
An egress-protected service MUST be mapped to an egress-protected tunnel by its ingress router, based on the common protected egress {E, P} of the service and the tunnel. This is achieved by introducing the notion of a "context ID" for a protected egress {E, P}, as described in Section 5.7.
出口で保護されたサービスは、サービスとトンネルの共通の保護された出口{E、P}に基づいて、その入口ルーターによって出口で保護されたトンネルにマップされる必要があります。これは、セクション5.7で説明されているように、保護された出口{E、P}の「コンテキストID」の概念を導入することで実現されます。
An egress-protected tunnel destined for a protected egress {E, P} MUST have a bypass tunnel from its PLR to protector P. This bypass tunnel is called an egress-protection bypass tunnel. The bypass tunnel is considered as logically "destined" for the protected egress {E, P}. Due to its bypass nature, it MUST be established with P as the physical tail end and E as the node to avoid. The bypass tunnel MUST NOT be affected by the topology change caused by an egress node failure; thus, it MUST contain a property that protects it from this scenario.
保護された出力{E、P}を宛先とする出力保護されたトンネルには、そのPLRからプロテクターPへのバイパストンネルが必要です。このバイパストンネルは、出力保護バイパストンネルと呼ばれます。バイパストンネルは、保護された出力{E、P}に対して論理的に「宛先」と見なされます。バイパスの性質上、物理的なテールエンドとしてP、回避するノードとしてEを使用して確立する必要があります。バイパストンネルは、出力ノードの障害によるトポロジーの変更の影響を受けてはなりません（MUST NOT）。したがって、このシナリオから保護するプロパティを含める必要があります。
An egress-protection bypass tunnel is associated with one and only one protected egress {E, P}. A PLR may share an egress-protection bypass tunnel for multiple egress-protected tunnels associated with a common protected egress {E, P}.
出力保護バイパストンネルは、1つの保護された出力{E、P}にのみ関連付けられます。 PLRは、共通の保護された出力{E、P}に関連付けられた複数の出力保護されたトンネルの出力保護バイパストンネルを共有できます。
In this framework, a globally unique IPv4 or IPv6 address is assigned as the identifier of the protected egress {E, P}. It is called a "context ID" due to its specific usage in context label switching and context IP forwarding on the protector. It is an IP address that is logically owned by both the egress router and the protector. For the egress router, it indicates the protector. For the protector, it indicates the egress router, particularly the egress router's forwarding context. For other routers in the network, it is an address reachable via both the egress router and the protector (Section 5.8), similar to an anycast address.
このフレームワークでは、グローバルに一意のIPv4またはIPv6アドレスが、保護された出口{E、P}の識別子として割り当てられます。プロテクターでのコンテキストラベルスイッチングとコンテキストIP転送での特定の使用法のため、「コンテキストID」と呼ばれます。これは、出力ルーターとプロテクターの両方が論理的に所有するIPアドレスです。出力ルーターの場合は、プロテクターを示します。プロテクターの場合、これは出力ルーター、特に出力ルーターの転送コンテキストを示します。ネットワーク内の他のルーターの場合、これは、エニーキャストアドレスと同様に、出力ルーターとプロテクターの両方を介して到達可能なアドレスです（セクション5.8）。
The main purpose of a context ID is to coordinate the ingress router, egress router, PLR, and protector to establish egress protection. The procedures are described below, given an egress-protected service associated with a protected egress {E, P} with a context ID.
コンテキストIDの主な目的は、入力ルーター、出力ルーター、PLR、およびプロテクターを調整して、出力保護を確立することです。コンテキストID付きの保護された出口{E、P}に関連付けられた出口保護サービスが与えられた場合の手順を以下に説明します。
* If the service is an MPLS service, when E distributes a service label binding message to the ingress router, E attaches the context ID to the message. If the service is an IP service, when E advertises the service destination address to the ingress router, E attaches the context ID to the advertisement message. The service protocol chooses how the context ID is encoded in the messages. A protocol extension of a "context ID" object may be needed, if there is no existing mechanism for this purpose.
* サービスがMPLSサービスである場合、Eがサービスラベルバインディングメッセージを入力ルータに配信すると、EはメッセージにコンテキストIDを添付します。サービスがIPサービスの場合、Eがサービスの宛先アドレスを入力ルーターにアドバタイズすると、EはコンテキストIDをアドバタイズメッセージに添付します。サービスプロトコルは、コンテキストIDをメッセージにエンコードする方法を選択します。この目的のための既存のメカニズムがない場合は、「コンテキストID」オブジェクトのプロトコル拡張が必要になる場合があります。
* The ingress router uses the service's context ID as the destination to establish or resolve an egress-protected tunnel. The ingress router then maps the service to the tunnel for transportation. The semantics of the context ID is transparent to the ingress router. The ingress router only treats the context ID as an IP address of E, in the same manner as establishing or resolving a regular transport tunnel.
* 入力ルーターは、サービスのコンテキストIDを宛先として使用して、出力保護されたトンネルを確立または解決します。次に、入口ルーターは、サービスを転送用のトンネルにマップします。コンテキストIDのセマンティクスは、入力ルーターに対して透過的です。入力ルーターは、通常のトランスポートトンネルの確立または解決と同じ方法で、コンテキストIDをEのIPアドレスとしてのみ扱います。
* The context ID is conveyed to the PLR by the signaling protocol of the egress-protected tunnel or learned by the PLR via an IGP (i.e., OSPF or IS-IS) or a topology-driven label distribution protocol (e.g., LDP). The PLR uses the context ID as the destination to establish or resolve an egress-protection bypass tunnel to P while avoiding E.
* コンテキストIDは、出力保護されたトンネルのシグナリングプロトコルによってPLRに伝達されるか、IGP（つまり、OSPFまたはIS-IS）またはトポロジー駆動型のラベル配布プロトコル（たとえば、LDP）を介してPLRによって学習されます。 PLRは、コンテキストIDを宛先として使用して、Eを回避しながら、Pへの出力保護バイパストンネルを確立または解決します。
* P maintains a dedicated label space and a dedicated IP address space for E. They are referred to as "E's label space" and "E's IP address space", respectively. P uses the context ID to identify the label space and IP address space.
* Pは、Eの専用ラベルスペースと専用IPアドレススペースを維持します。これらは、それぞれ「Eのラベルスペース」と「EのIPアドレススペース」と呼ばれます。 PはコンテキストIDを使用して、ラベルスペースとIPアドレススペースを識別します。
* If the service is an MPLS service, E also distributes the service label binding message to P. This is the same label binding message that E advertises to the ingress router, which includes the context ID. Based on the context ID, P installs the service label in an MPLS forwarding table corresponding to E's label space. If the service is an IP service, P installs an IP route in an IP forwarding table corresponding to E's IP address space. In either case, the protection service instance on P constructs the forwarding state for the label route or IP route based on P's own connectivity with the service's destination.
* サービスがMPLSサービスの場合、EはサービスラベルバインディングメッセージもPに配信します。これは、Eが入力ルータにアドバタイズするのと同じラベルバインディングメッセージで、コンテキストIDが含まれます。 PはコンテキストIDに基づいて、Eのラベルスペースに対応するMPLS転送テーブルにサービスラベルをインストールします。サービスがIPサービスの場合、PはEのIPアドレス空間に対応するIP転送テーブルにIPルートをインストールします。どちらの場合でも、P上の保護サービスインスタンスは、サービスの宛先とのP自身の接続に基づいて、ラベルルートまたはIPルートの転送状態を構築します。
* P assigns a non-reserved label to the context ID. In the data plane, this label represents the context ID and indicates E's label space and IP address space. Therefore, it is called a "context label".
* Pは、予約されていないラベルをコンテキストIDに割り当てます。データプレーンでは、このラベルはコンテキストIDを表し、EのラベルスペースとIPアドレススペースを示します。そのため、「コンテキストラベル」と呼ばれます。
* The PLR may establish the egress-protection bypass tunnel to P in several manners. If the bypass tunnel is established by RSVP, the PLR signals the bypass tunnel with the context ID as the destination, and P binds the context label to the bypass tunnel. If the bypass tunnel is established by LDP, P advertises the context label for the context ID as an IP prefix Forwarding Equivalence Class (FEC). If the bypass tunnel is established by the PLR in a hierarchical manner, the PLR treats the context label as a one-hop LSP over a regular bypass tunnel to P (e.g., a bypass tunnel to P's loopback IP address). If the bypass tunnel is constructed by using Segment Routing, the bypass tunnel is represented by a stack of Segment Identifier (SID) labels with the context label as the inner-most SID label (Section 5.9). In any case, the bypass tunnel is an ultimate hop-popping (UHP) tunnel whose incoming label on P is the context label.
* PLRは、いくつかの方法でPへの出口保護バイパストンネルを確立できます。 RSVPによってバイパストンネルが確立された場合、PLRは宛先としてコンテキストIDを使用してバイパストンネルに信号を送り、Pはコンテキストラベルをバイパストンネルにバインドします。 LDPによってバイパストンネルが確立されている場合、PはコンテキストIDのコンテキストラベルをIPプレフィックスの転送等価クラス（FEC）として通知します。バイパストンネルがPLRによって階層的に確立されている場合、PLRは、コンテキストラベルをPへの通常のバイパストンネル（たとえば、PのループバックIPアドレスへのバイパストンネル）を介した1ホップLSPとして扱います。バイパストンネルがセグメントルーティングを使用して構築されている場合、バイパストンネルは、最も内側のSIDラベルとしてコンテキストラベルを持つセグメント識別子（SID）ラベルのスタックによって表されます（セクション5.9）。いずれの場合も、バイパストンネルは、Pの着信ラベルがコンテキストラベルである究極のホップポップ（UHP）トンネルです。
* During local repair, all the service packets received by P on the bypass tunnel have the context label as the top label. P first pops the context label. For an MPLS service packet, P looks up the service label in E's label space indicated by the context label. Such kind of forwarding is called context label switching. For an IP service packet, P looks up the IP destination address in E's IP address space indicated by the context label. Such kind of forwarding is called context IP forwarding.
* ローカル修復中、バイパストンネルでPが受信したすべてのサービスパケットには、トップラベルとしてコンテキストラベルがあります。 Pは最初にコンテキストラベルをポップします。 MPLSサービスパケットの場合、Pはコンテキストラベルで示されるEのラベルスペースでサービスラベルを検索します。この種の転送は、コンテキストラベルスイッチングと呼ばれます。 IPサービスパケットの場合、Pはコンテキストラベルで示されるEのIPアドレス空間でIP宛先アドレスを検索します。この種の転送は、コンテキストIP転送と呼ばれます。
Path resolution and computation for a context ID are done on ingress routers for egress-protected tunnels and on PLRs for egress-protection bypass tunnels. Given a protected egress {E, P} and its context ID, E and P MUST coordinate on the reachability of the context ID in the routing domain and the TE domain. The context ID MUST be advertised in such a manner that all egress-protected tunnels MUST have E as the tail end, and all egress-protection bypass tunnels MUST have P as the tail end while avoiding E.
コンテキストIDのパス解決と計算は、出力保護トンネルの場合は入力ルーターで、出力保護バイパストンネルの場合はPLRで行われます。保護された出口{E、P}とそのコンテキストIDが与えられた場合、EとPはルーティングドメインとTEドメインのコンテキストIDの到達可能性を調整しなければなりません（MUST）。コンテキストIDは、すべての出口保護トンネルがEをテールエンドとして持つ必要があり、すべての出口保護バイパストンネルがEを回避しながらテールエンドとしてPを持たなければならないような方法でアドバタイズされる必要があります。
This document suggests three approaches:
このドキュメントでは、3つのアプローチを提案しています。
1. The first approach is called "proxy mode". It requires E and P, but not the PLR, to have the knowledge of the egress protection schema. E and P advertise the context ID as a virtual proxy node (i.e., a logical node) connected to the two routers, with the link between the proxy node and E having more preferable IGP and TE metrics than the link between the proxy node and P. Therefore, all egress-protected tunnels destined for the context ID will automatically follow the IGP or TE paths to E. Each PLR will no longer view itself as a penultimate hop but rather as two hops away from the proxy node, via E. The PLR will be able to find a bypass path via P to the proxy node, while the bypass tunnel is actually terminated by P.
1. 最初のアプローチは「プロキシモード」と呼ばれます。出力保護スキーマの知識を持つためには、PLRではなくEとPが必要です。 EとPは、2つのルーターに接続された仮想プロキシノード（つまり、論理ノード）としてコンテキストIDをアドバタイズします。プロキシノードとEの間のリンクは、プロキシノードとPの間のリンクよりもIGPおよびTEメトリックの方が望ましいです。 。したがって、コンテキストID宛てのすべての出口保護トンネルは、自動的にIGPまたはTEへのEパスをたどります。各PLRは、最後から2番目のホップとしてではなく、Eを介してプロキシノードから2ホップ離れた場所として表示されます。 PLRはPを経由してプロキシノードへのバイパスパスを見つけることができますが、バイパストンネルは実際にはPによって終端されます。
2. The second approach is called "alias mode". It requires P and the PLR, but not E, to have the knowledge of the egress protection schema. E simply advertises the context ID as an IP address. P advertises the context ID and the context label by using a "context ID label binding" advertisement. In both the routing domain and TE domain, the context ID is only reachable via E. Therefore, all egress-protected tunnels destined for the context ID will have E as the tail end. Based on the "context ID label binding" advertisement, the PLR can establish an egress-protection bypass tunnel in several manners (Section 5.9). The "context ID label binding" advertisement is defined as the IGP Mirroring Context segment in [RFC8402] and [RFC8667]. These IGP extensions are generic in nature and hence can be used for egress protection purposes. It is RECOMMENDED that a similar advertisement be defined for OSPF as well.
2. 2番目の方法は「エイリアスモード」と呼ばれます。出力保護スキーマの知識を持つためには、PとPLRが必要ですが、Eは必要ありません。 Eは単にコンテキストIDをIPアドレスとしてアドバタイズします。 Pは、「コンテキストIDラベルバインディング」通知を使用して、コンテキストIDとコンテキストラベルを通知します。ルーティングドメインとTEドメインの両方で、コンテキストIDはE経由でのみ到達可能です。したがって、コンテキストID宛てのすべての出力保護トンネルには、末尾がEになります。 「コンテキストIDラベルバインディング」通知に基づいて、PLRはいくつかの方法で出口保護バイパストンネルを確立できます（セクション5.9）。 「コンテキストIDラベルバインディング」アドバタイズメントは、[RFC8402]および[RFC8667]でIGPミラーリングコンテキストセグメントとして定義されています。これらのIGP拡張機能は本質的に汎用であるため、出力保護の目的で使用できます。 OSPFにも同様のアドバタイズを定義することをお勧めします。
3. The third approach is called "stub link mode". In this mode, both E and P advertise the context ID as a link to a stub network, essentially modeling the context ID as an anycast IP address owned by the two routers. E, P, and the PLR do not need to have the knowledge of the egress protection schema. The correctness of the egress-protected tunnels and the bypass tunnels relies on the path computations for the anycast IP address performed by the ingress routers and PLR. Therefore, care MUST be taken for the applicability of this approach to a network.
3. 3番目の方法は「スタブリンクモード」と呼ばれます。このモードでは、EとPの両方がコンテキストIDをスタブネットワークへのリンクとしてアドバタイズし、基本的に2つのルーターが所有するエニーキャストIPアドレスとしてコンテキストIDをモデル化します。 E、P、およびPLRは、出力保護スキーマの知識を持つ必要はありません。出力保護されたトンネルとバイパストンネルの正確さは、入力ルーターとPLRによって実行されるエニーキャストIPアドレスのパス計算に依存します。したがって、このアプローチのネットワークへの適用性には注意が必要です。
This framework considers the above approaches as technically equal and the feasibility of each approach in a given network as dependent on the topology, manageability, and available protocols of the network. For a given context ID, all relevant routers, including the primary PE, protector, and PLR, MUST support and agree on the chosen approach. The coordination between these routers can be achieved by configuration.
このフレームワークは、上記のアプローチを技術的に同等であると見なし、特定のネットワークにおける各アプローチの実現可能性は、ネットワークのトポロジ、管理性、および使用可能なプロトコルに依存すると見なします。与えられたコンテキストIDに対して、プライマリPE、プロテクター、PLRを含むすべての関連ルーターは、選択されたアプローチをサポートし、合意しなければなりません（MUST）。これらのルーター間の調整は、構成によって実現できます。
In a scenario where an egress-protected tunnel is an inter-area or inter-Autonomous-System (inter-AS) tunnel, its associated context ID MUST be propagated by IGP or BGP from the original area or AS to the area or AS of the ingress router. The propagation process of the context ID SHOULD be the same as that of an IP address in an inter-area or inter-AS environment.
出力保護されたトンネルがエリア間または自律システム間（AS間）トンネルであるシナリオでは、それに関連付けられたコンテキストIDは、IGPまたはBGPによって元のエリアまたはASからエリアまたはASに伝播する必要があります。入力ルーター。コンテキストIDの伝播プロセスは、エリア間またはAS間環境のIPアドレスのそれと同じである必要があります（SHOULD）。
A PLR MUST know the context ID of a protected egress {E, P} in order to establish an egress-protection bypass tunnel. The information is obtained from the signaling or label distribution protocol of the egress-protected tunnel. The PLR may or may not need to have the knowledge of the egress-protection schema. All it does is set up a bypass tunnel to a context ID while avoiding the next-hop router (i.e., egress router). This is achievable by using a constraint-based computation algorithm similar to those commonly used for traffic engineering paths and Loop-Free Alternate (LFA) paths. Since the context ID is advertised in the routing domain and in the TE domain by IGP according to Section 5.8, the PLR is able to resolve or establish such a bypass path with the protector as the tail end. In the case of proxy mode, the PLR may do so in the same manner as transit node protection.
PLRは、出力保護バイパストンネルを確立するために、保護された出力{E、P}のコンテキストIDを知っている必要があります。この情報は、出力保護されたトンネルのシグナリングまたはラベル配布プロトコルから取得されます。 PLRは、出力保護スキーマの知識を持つ必要がある場合とない場合があります。ネクストホップルーター（つまり、出力ルーター）を回避しながら、コンテキストIDへのバイパストンネルを設定するだけです。これは、トラフィックエンジニアリングパスおよびループフリー代替（LFA）パスに一般的に使用されるものと同様の制約ベースの計算アルゴリズムを使用することで実現できます。コンテキストIDはセクション5.8に従ってIGPによってルーティングドメインとTEドメインでアドバタイズされるため、PLRはプロテクターをテールエンドとするこのようなバイパスパスを解決または確立できます。プロキシモードの場合、PLRはトランジットノード保護と同じ方法でこれを行うことができます。
An egress-protection bypass tunnel may be established via several methods:
出力保護バイパストンネルは、いくつかの方法で確立できます。
1. It may be established by a signaling protocol (e.g., RSVP), with the context ID as the destination. The protector binds the context label to the bypass tunnel.
1. これは、宛先としてコンテキストIDを使用して、シグナリングプロトコル（RSVPなど）によって確立されます。プロテクターは、コンテキストラベルをバイパストンネルにバインドします。
2. It may be formed by a topology-driven protocol (e.g., LDP with various LFA mechanisms). The protector advertises the context ID as an IP prefix FEC, with the context label bound to it.
2. これは、トポロジー駆動型プロトコル（たとえば、さまざまなLFAメカニズムを備えたLDP）によって形成されます。プロテクターは、バインドされたコンテキストラベルを使用して、コンテキストIDをIPプレフィックスFECとして通知します。
3. It may be constructed as a hierarchical tunnel. When the protector uses the alias mode (Section 5.8), the PLR will have the knowledge of the context ID, context label, and protector (i.e., the advertiser). The PLR can then establish the bypass tunnel in a hierarchical manner, with the context label as a one-hop LSP over a regular bypass tunnel to the protector's IP address (e.g., loopback address). This regular bypass tunnel may be established by RSVP, LDP, Segment Routing, or another protocol.
3. 階層的なトンネルとして構築することができます。プロテクターがエイリアスモードを使用する場合（セクション5.8）、PLRはコンテキストID、コンテキストラベル、およびプロテクター（つまり、広告主）の知識を持ちます。次に、PLRは階層的な方法でバイパストンネルを確立できます。コンテキストラベルは、プロテクターのIPアドレス（ループバックアドレスなど）への通常のバイパストンネルを介したワンホップLSPです。この通常のバイパストンネルは、RSVP、LDP、セグメントルーティング、または別のプロトコルによって確立されます。
In this framework, a PLR is agnostic to services and service labels. This obviates the need to maintain bypass forwarding state on a per-service basis and allows bypass tunnel sharing between egress-protected tunnels. The PLR may share an egress-protection bypass tunnel for multiple egress-protected tunnels associated with a common protected egress {E, P}. During local repair, the PLR reroutes all service packets received on the egress-protected tunnels to the egress-protection bypass tunnel. Service labels remain intact in MPLS service packets.
このフレームワークでは、PLRはサービスとサービスラベルに依存しません。これにより、サービスごとにバイパス転送状態を維持する必要がなくなり、出力保護されたトンネル間でのバイパストンネル共有が可能になります。 PLRは、共通の保護された出力{E、P}に関連付けられた複数の出力保護されたトンネルの出力保護バイパストンネルを共有できます。ローカル修復中に、PLRは、出力保護されたトンネルで受信されたすべてのサービスパケットを出力保護バイパストンネルに再ルーティングします。 MPLSサービスパケットのサービスラベルはそのまま残ります。
Label operation performed by the PLR depends on the bypass tunnel's characteristics. If the bypass tunnel is a single level tunnel, the rerouting will involve swapping the incoming label of an egress-protected tunnel to the outgoing label of the bypass tunnel. If the bypass tunnel is a hierarchical tunnel, the rerouting will involve swapping the incoming label of an egress-protected tunnel to a context label and pushing the outgoing label of a regular bypass tunnel. If the bypass tunnel is constructed by Segment Routing, the rerouting will involve swapping the incoming label of an egress-protected tunnel to a context label and pushing the stack of SID labels of the bypass tunnel.
PLRによって実行されるラベル操作は、バイパストンネルの特性によって異なります。バイパストンネルが単一レベルトンネルの場合、再ルーティングには、出力保護されたトンネルの着信ラベルをバイパストンネルの発信ラベルに交換する必要があります。バイパストンネルが階層トンネルである場合、再ルーティングには、出力保護されたトンネルの着信ラベルをコンテキストラベルにスワップし、通常のバイパストンネルの発信ラベルをプッシュすることが含まれます。バイパストンネルがセグメントルーティングによって構築されている場合、再ルーティングには、出力保護されたトンネルの着信ラベルをコンテキストラベルにスワップし、バイパストンネルのSIDラベルのスタックをプッシュすることが含まれます。
When a protector receives a rerouted MPLS service packet, it performs context label switching based on the packet's service label, which is assigned by the corresponding egress router. In order to achieve this, the protector MUST maintain the labels of egress-protected services in dedicated label spaces on a per-protected-egress {E, P} basis, i.e., one label space for each egress router that it protects.
プロテクターは、再ルーティングされたMPLSサービスパケットを受信すると、対応する出力ルーターによって割り当てられたパケットのサービスラベルに基づいて、コンテキストラベルスイッチングを実行します。これを達成するために、プロテクターは、保護された出力{E、P}に基づいて、専用のラベルスペースで出力保護されたサービスのラベルを維持する必要があります。つまり、保護する各出力ルーターごとに1つのラベルスペースを維持する必要があります。
Also, there MUST be a service label distribution protocol session between each egress router and the protector. Through this protocol, the protector learns the label binding of each egress-protected service. This is the same label binding that the egress router advertises to the service's ingress router, which includes a context ID. The corresponding protection service instance on the protector recognizes the service and resolves forwarding state based on its own connectivity with the service's destination. It then installs the service label with the forwarding state in the label space of the egress router, which is indicated by the context ID (i.e., context label).
また、各出口ルータとプロテクタの間には、サービスラベル配布プロトコルセッションが必要です。このプロトコルを通じて、プロテクターは各出力保護サービスのラベルバインディングを学習します。これは、コンテキストIDを含む、出力ルーターがサービスの入力ルーターにアドバタイズするのと同じラベルバインディングです。プロテクターの対応する保護サービスインスタンスはサービスを認識し、サービスの宛先との独自の接続に基づいて転送状態を解決します。次に、コンテキストID（つまり、コンテキストラベル）で示される、出力ルーターのラベルスペースに転送状態のサービスラベルをインストールします。
Different service protocols may use different mechanisms for such kind of label distribution. Specific extensions may be needed on a per-protocol or per-service-type basis. The details of the extensions should be specified in separate documents. As an example, the LDP extensions for pseudowire services are specified in [RFC8104].
異なるサービスプロトコルは、そのような種類のラベル配布に異なるメカニズムを使用する場合があります。プロトコルごとまたはサービスタイプごとに特定の拡張が必要になる場合があります。拡張機能の詳細は、別のドキュメントで指定する必要があります。例として、疑似配線サービスのLDP拡張は[RFC8104]で指定されています。
In this framework, it is assumed that the service destination of an egress-protected service MUST be dual-homed to two edge routers of an MPLS network. One of them is the protected egress router, and the other is a backup egress router. So far in this document, the focus of discussion has been on the scenario where a protector and a backup egress router are co-located as one router. Therefore, the number of protectors in a network is equal to the number of backup egress routers. As another scenario, a network may assign a small number of routers to serve as dedicated protectors, each protecting a subset of egress routers. These protectors are called centralized protectors.
このフレームワークでは、出口で保護されたサービスのサービス宛先は、MPLSネットワークの2つのエッジルーターにデュアルホーム接続されている必要があります。 1つは保護された出力ルーターで、もう1つはバックアップ出力ルーターです。これまでのところ、このドキュメントでは、プロテクターとバックアップ出力ルーターが1つのルーターとして同じ場所に配置されるシナリオを中心に説明しました。したがって、ネットワーク内のプロテクターの数は、バックアップ出力ルーターの数と同じです。別のシナリオとして、ネットワークは少数のルーターを割り当てて専用のプロテクターとして機能し、それぞれが出口ルーターのサブセットを保護する場合があります。これらのプロテクターは集中プロテクターと呼ばれます。
Topologically, a centralized protector may be decoupled from all backup egress routers, or it may be co-located with one backup egress router while decoupled from the other backup egress routers. The procedures in this section assume that a protector and a backup egress router are decoupled.
トポロジ的には、集中型プロテクターをすべてのバックアップ出力ルーターから切り離すか、1つのバックアップ出力ルーターと同じ場所に配置し、他のバックアップ出力ルーターから切り離すことができます。このセクションの手順では、プロテクターとバックアップ出力ルーターが分離されていることを前提としています。
services 1, ..., N
=====================================> tunnel
I ------ R1 ------- PLR --------------- E ----
ingress penultimate hop egress \
| . (primary \
| . service \
| . instances) \
| . \
| . bypass \ service
R2 . tunnel destinations
| . / (CEs, sites)
| . /
| . /
| . /
| . tunnel /
| =============> /
P ---------------- E' ---
protector backup egress
(protection (backup
service service
instances) instances)
Figure 2
図2
Like a co-located protector, a centralized protector hosts protection service instances, receives rerouted service packets from PLRs, and performs context label switching and/or context IP forwarding. For each service, instead of sending service packets directly to the service destination, the protector MUST send them via another transport tunnel to the corresponding backup service instance on a backup egress router. The backup service instance in turn forwards the service packets to the service destination. Specifically, if the service is an MPLS service, the protector MUST swap the service label in each received service packet to the label of the backup service advertised by the backup egress router, and then push the label (or label stack) of the transport tunnel.
中央に配置されたプロテクターは、同じ場所に配置されたプロテクターと同様に、保護サービスインスタンスをホストし、PLRから再ルーティングされたサービスパケットを受信し、コンテキストラベルスイッチングやコンテキストIP転送を実行します。サービスごとに、サービスパケットをサービスの宛先に直接送信する代わりに、プロテクターは、別のトランスポートトンネルを介して、バックアップ出力ルーター上の対応するバックアップサービスインスタンスにパケットを送信する必要があります。バックアップサービスインスタンスは、サービスパケットをサービスの宛先に転送します。具体的には、サービスがMPLSサービスの場合、プロテクターは、受信した各サービスパケットのサービスラベルを、バックアップ出力ルーターによってアドバタイズされたバックアップサービスのラベルに交換し、トランスポートトンネルのラベル（またはラベルスタック）をプッシュする必要があります。 。
In order for a centralized protector to map an egress-protected MPLS service to a service hosted on a backup egress router, there MUST be a service label distribution protocol session between the backup egress router and the protector. Through this session, the backup egress router advertises the service label of the backup service, attached with the FEC of the egress-protected service and the context ID of the protected egress {E, P}. Based on this information, the protector associates the egress-protected service with the backup service, resolves or establishes a transport tunnel to the backup egress router, and sets up forwarding state for the label of the egress-protected service in the label space of the egress router.
集中型プロテクターが出力保護されたMPLSサービスをバックアップ出力ルーターでホストされているサービスにマッピングするには、バックアップ出力ルーターとプロテクターの間にサービスラベル配布プロトコルセッションが存在する必要があります。このセッションを通じて、バックアップ出力ルーターは、出力サービスで保護されたサービスのFECと保護された出力{E、P}のコンテキストIDが添付されたバックアップサービスのサービスラベルをアドバタイズします。この情報に基づいて、プロテクターは出力保護されたサービスをバックアップサービスに関連付け、バックアップ出力ルーターへのトランスポートトンネルを解決または確立し、出力保護されたサービスのラベルの転送状態を、出力ルーター。
The service label that the backup egress router advertises to the protector can be the same as the label that the backup egress router advertises to the ingress router(s), if and only if the forwarding state of the label does not direct service packets towards the protected egress router. Otherwise, the label MUST NOT be used for egress protection, because it would create a loop for the service packets. In this case, the backup egress router MUST advertise a unique service label for egress protection and set up the forwarding state of the label to use the backup egress router's own connectivity with the service destination.
バックアップ出力ルータがプロテクタにアドバタイズするサービスラベルは、ラベルの転送状態がサービスパケットをに向けない場合に限り、バックアップ出力ルータがイングレスルータにアドバタイズするラベルと同じにすることができます。保護された出力ルーター。それ以外の場合、ラベルはサービスパケットのループを作成するため、出力保護に使用してはなりません（MUST NOT）。この場合、バックアップ出力ルーターは、出力保護のための一意のサービスラベルをアドバタイズし、ラベルの転送状態を設定して、サービス出力先とのバックアップ出力ルーター自身の接続を使用する必要があります。
Egress link protection is achievable through procedures similar to that of egress node protection. In normal situations, an egress router forwards service packets to a service destination based on a service label, whose forwarding state points to an egress link. In egress link protection, the egress router acts as the PLR and performs local failure detection and local repair. Specifically, the egress router pre-establishes an egress-protection bypass tunnel to a protector and sets up the bypass forwarding state for the service label to point to the bypass tunnel. During local repair, the egress router reroutes service packets via the bypass tunnel to the protector. The protector in turn forwards the packets to the service destination (in the co-located protector mode, as shown in Figure 3) or forwards the packets to a backup egress router (in the centralized protector mode, as shown in Figure 4).
出力リンク保護は、出力ノード保護と同様の手順で実現できます。通常の状況では、出力ルーターは、サービスラベルに基づいてサービスの宛先にサービスパケットを転送し、その転送状態は出力リンクを指します。出力リンク保護では、出力ルーターがPLRとして機能し、ローカル障害検出とローカル修復を実行します。具体的には、出力ルーターは、プロテクターへの出力保護バイパストンネルを事前に確立し、サービスラベルがバイパストンネルを指すようにバイパス転送状態を設定します。ローカルでの修復中、出力ルーターはバイパストンネルを介してサービスパケットをプロテクターに再ルーティングします。次に、プロテクターは（図3に示すように同じ場所に配置されたプロテクターモードで）サービスの宛先にパケットを転送するか、または（図4に示すように集中型プロテクターモードで）バックアップ出力ルーターにパケットを転送します。
service
=====================================> tunnel
I ------ R1 ------- R2 --------------- E ----
ingress | ............. egress \
| . PLR \
| . (primary \
| . service \
| . instance) \
| . \
| . bypass service
| . tunnel destination
| . / (CE, site)
| . /
| . /
| . /
| . /
| ............... /
R3 --------------- P ----
protector
(protection
service
instance)
Figure 3
図3
service
=====================================> tunnel
I ------ R1 ------- R2 --------------- E ----
ingress | ............. egress \
| . PLR \
| . (primary \
| . service \
| . instance) \
| . \
| . bypass service
| . tunnel destination
| . / (CE, site)
| . /
| . /
| . /
| . tunnel /
| =============> /
R3 --------------- P ----
protector backup egress
(protection (backup
service service
instance) instance)
Figure 4
図4
There are two approaches for setting up the bypass forwarding state on the egress router, depending on whether the egress router knows the service label allocated by the backup egress router. The difference is that one approach requires the protector to perform context label switching, and the other one does not. Both approaches are equally supported by this framework.
出力ルータがバックアップ出力ルータによって割り当てられたサービスラベルを知っているかどうかに応じて、出力ルータでバイパス転送状態を設定する方法は2つあります。違いは、1つの方法ではコンテキストラベルの切り替えを実行するためにプロテクターが必要であり、もう1つの方法では必要ないことです。このフレームワークでは、どちらのアプローチも等しくサポートされています。
1. The first approach applies when the egress router does not know the service label allocated by the backup egress router. In this case, the egress router sets up the bypass forwarding state as a label push with the outgoing label of the egress-protection bypass tunnel. Rerouted packets will have the egress router's service label intact. Therefore, the protector MUST perform context label switching, and the bypass tunnel MUST be destined for the context ID of the protected egress {E, P} and established as described in Section 5.9. This approach is consistent with egress node protection. Hence, a protector can serve in egress node protection and egress link protection in a consistent manner, and both the co-located protector mode and the centralized protector mode are supported (see Figures 3 and 4).
1. 最初のアプローチは、出力ルータがバックアップ出力ルータによって割り当てられたサービスラベルを認識していない場合に適用されます。この場合、出力ルーターは、バイパス転送状態を、出力保護バイパストンネルの出力ラベルを持つラベルプッシュとして設定します。再ルーティングされたパケットには、出力ルーターのサービスラベルがそのまま残ります。したがって、プロテクターはコンテキストラベルスイッチングを実行しなければならず（MUST）、バイパストンネルは、保護された出口{E、P}のコンテキストIDを宛先とし、セクション5.9で説明されているように確立される必要があります。このアプローチは、出力ノード保護と一致しています。したがって、プロテクターは出力ノード保護と出力リンク保護で一貫した方法で機能でき、同じ場所に配置されたプロテクターモードと集中型プロテクターモードの両方がサポートされます（図3および4を参照）。
2. The second approach applies when the egress router knows the service label allocated by the backup egress router, via a label distribution protocol session. In this case, the backup egress router serves as the protector for egress link protection, regardless of the protector of egress node protection, which will be the same router in the co-located protector mode but a different router in the centralized protector mode. The egress router sets up the bypass forwarding state as a label swap from the incoming service label to the service label of the backup egress router (i.e., protector), followed by a push with the outgoing label (or label stack) of the egress link protection bypass tunnel. The bypass tunnel is a regular tunnel destined for an IP address of the protector, instead of the context ID of the protected egress {E, P}. The protector simply forwards rerouted service packets based on its own service label rather than performing context label switching. In this approach, only the co-located protector mode is applicable.
2. 2番目のアプローチは、ラベル配布プロトコルセッションを介して、出力ルータがバックアップ出力ルータによって割り当てられたサービスラベルを知っている場合に適用されます。この場合、バックアップ出力ルーターは、出力ノード保護の保護機能に関係なく、出力リンク保護の保護機能として機能します。これは、同じ場所に配置された保護機能モードでは同じルーターですが、集中保護機能モードでは別のルーターになります。出力ルーターは、バイパス転送状態を、着信サービスラベルからバックアップ出力ルーター（つまり、プロテクター）のサービスラベルへのラベルスワップとして設定し、その後に、出力リンクの出力ラベル（またはラベルスタック）でプッシュします。保護バイパストンネル。バイパストンネルは、保護された出力{E、P}のコンテキストIDではなく、プロテクターのIPアドレスを宛先とする通常のトンネルです。プロテクターは、コンテキストラベルスイッチングを実行するのではなく、独自のサービスラベルに基づいて、再ルーティングされたサービスパケットを転送するだけです。このアプローチでは、同じ場所に配置されたプロテクターモードのみが適用されます。
Note that for a bidirectional service, the physical link of an egress link may carry service traffic bidirectionally. Therefore, an egress link failure may simultaneously be an ingress link failure for the traffic in the opposite direction. Protection for ingress link failure SHOULD be provided by a separate mechanism and hence is out of the scope of this document.
双方向サービスの場合、出口リンクの物理リンクはサービストラフィックを双方向に伝送する可能性があることに注意してください。したがって、出力リンク障害は、反対方向のトラフィックの入力リンク障害でもあります。入力リンク障害に対する保護は、別のメカニズムによって提供する必要があるため（SHOULD）、このドキュメントの範囲外です。
This framework provides a fast but temporary repair for egress node and egress link failures. For permanent repair, the services affected by a failure SHOULD be moved to an alternative tunnel, or replaced by alternative services, which are fully functional. This is referred to as global repair. Possible triggers of global repair include control-plane notifications of tunnel status and service status, end-to-end OAM and fault detection at the tunnel and service level, and others. The alternative tunnel and services may be pre-established in standby state or dynamically established as a result of the triggers or network protocol convergence.
このフレームワークは、出力ノードと出力リンクの障害に対して、高速ですが一時的な修復を提供します。恒久的な修理の場合、障害の影響を受けたサービスは、代替トンネルに移動するか、完全に機能する代替サービスに置き換える必要があります（SHOULD）。これは、グローバル修復と呼ばれます。グローバル修復の可能なトリガーには、トンネルステータスとサービスステータスのコントロールプレーン通知、トンネルとサービスレベルでのエンドツーエンドOAMと障害検出などがあります。代替トンネルとサービスは、スタンバイ状態で事前に確立されるか、トリガーまたはネットワークプロトコルコンバージェンスの結果として動的に確立されます。
When a PLR performs local repair, the router SHOULD generate an alert for the event. The alert may be logged locally for tracking purposes, or it may be sent to the operator at a management station. The communication channel and protocol between the PLR and the management station may vary depending on networks and are out of the scope of this document.
PLRがローカル修復を実行すると、ルーターはイベントのアラートを生成する必要があります（SHOULD）。アラートは追跡目的でローカルにログに記録されるか、管理ステーションのオペレーターに送信されます。 PLRと管理ステーション間の通信チャネルとプロトコルは、ネットワークによって異なり、このドキュメントの範囲外です。
So far, this document has been focusing on the cases where service packets are MPLS or IP packets, and protectors perform context label switching or context IP forwarding. Although this should cover most common services, it is worth mentioning that the framework is also applicable to services or sub-modes of services where service packets are Layer 2 packets or encapsulated in non-IP and non-MPLS formats. The only specific in these cases is that a protector MUST perform context-based forwarding based on the Layer 2 table or corresponding lookup table, which is indicated by a context ID (i.e., context label).
これまでのところ、このドキュメントでは、サービスパケットがMPLSまたはIPパケットであり、プロテクターがコンテキストラベルスイッチングまたはコンテキストIP転送を実行する場合に焦点を当てています。これはほとんどの一般的なサービスをカバーするはずですが、フレームワークはサービスまたはサービスのサブモードにも適用でき、サービスパケットがレイヤー2パケットであるか、非IPおよび非MPLS形式でカプセル化されていることにも言及する価値があります。これらの場合の唯一の特定は、プロテクターが、レイヤー2テーブルまたは対応するルックアップテーブルに基づいてコンテキストベースの転送を実行する必要があることです。これは、コンテキストID（つまり、コンテキストラベル）で示されます。
This section shows an example of egress protection for Layer 3 IPv4 and IPv6 VPNs.
このセクションでは、レイヤ3 IPv4およびIPv6 VPNの出力保護の例を示します。
---------- R1 ----------- PE2 -
/ (PLR) (PLR) \
( ) / | | ( )
( ) / | | ( )
( site 1 )-- PE1 < | R3 ( site 2 )
( ) \ | | ( )
( ) \ | | ( )
\ | | /
---------- R2 ----------- PE3 -
(protector)
Figure 5
図5
In this example, the core network is IPv4 and MPLS. Both of the IPv4 and IPv6 VPNs consist of sites 1 and 2. Site 1 is connected to PE1, and site 2 is dual-homed to PE2 and PE3. Site 1 includes an IPv4 subnet 203.0.113.64/26 and an IPv6 subnet 2001:db8:1:1::/64. Site 2 includes an IPv4 subnet 203.0.113.128/26 and an IPv6 subnet 2001:db8:1:2::/64. PE2 is the primary PE for site 2, and PE3 is the backup PE. Each of PE1, PE2, and PE3 hosts an IPv4 VPN instance and an IPv6 VPN instance. The PEs use BGP to exchange VPN prefixes and VPN labels between each other. In the core network, R1 and R2 are transit routers, OSPF is used as the routing protocol, and RSVP-TE is used as the tunnel signaling protocol.
この例では、コアネットワークはIPv4とMPLSです。 IPv4とIPv6の両方のVPNはサイト1と2で構成されています。サイト1はPE1に接続され、サイト2はPE2とPE3にデュアルホーム接続されています。サイト1には、IPv4サブネット203.0.113.64/26およびIPv6サブネット2001：db8：1：1 :: / 64が含まれています。サイト2には、IPv4サブネット203.0.113.128/26およびIPv6サブネット2001：db8：1：2 :: / 64が含まれています。 PE2はサイト2のプライマリPEで、PE3はバックアップPEです。 PE1、PE2、およびPE3のそれぞれは、IPv4 VPNインスタンスとIPv6 VPNインスタンスをホストします。 PEはBGPを使用して、VPNプレフィックスとVPNラベルを相互に交換します。コアネットワークでは、R1とR2は中継ルーターであり、ルーティングプロトコルとしてOSPFが使用され、トンネルシグナリングプロトコルとしてRSVP-TEが使用されています。
Using the framework in this document, the network assigns PE3 to be the protector of PE2 to protect the VPN traffic in the direction from site 1 to site 2. This is the co-located protector mode. PE2 and PE3 form a protected egress {PE2, PE3}. Context ID 198.51.100.1 is assigned to the protected egress {PE2, PE3}. (If the core network is IPv6, the context ID would be an IPv6 address.) The IPv4 and IPv6 VPN instances on PE3 serve as protection instances for the corresponding VPN instances on PE2. On PE3, context label 100 is assigned to the context ID, and a label table pe2.mpls is created to represent PE2's label space. PE3 installs label 100 in its MPLS forwarding table, with the next hop pointing to the label table pe2.mpls. PE2 and PE3 are coordinated to use the proxy mode to advertise the context ID in the routing domain and the TE domain.
このドキュメントのフレームワークを使用して、ネットワークはPE3をPE2のプロテクターとして割り当て、サイト1からサイト2への方向のVPNトラフィックを保護します。これは同じ場所に配置されたプロテクターモードです。 PE2およびPE3は保護された出力{PE2、PE3}を形成します。コンテキストID 198.51.100.1が保護された出力{PE2、PE3}に割り当てられています。 （コアネットワークがIPv6の場合、コンテキストIDはIPv6アドレスになります。）PE3のIPv4およびIPv6 VPNインスタンスは、PE2の対応するVPNインスタンスの保護インスタンスとして機能します。 PE3では、コンテキストラベル100がコンテキストIDに割り当てられ、PE2のラベルスペースを表すラベルテーブルpe2.mplsが作成されます。 PE3は、MPLS転送テーブルにラベル100をインストールし、ネクストホップはラベルテーブルpe2.mplsを指します。 PE2とPE3は、プロキシモードを使用してルーティングドメインとTEドメインのコンテキストIDをアドバタイズするように調整されています。
PE2 uses the label allocation mode per Virtual Routing and Forwarding (VRF) for both of its IPv4 and IPv6 VPN instances. It assigns label 9000 to the IPv4 VRF, and label 9001 to the IPv6 VRF. For the IPv4 prefix 203.0.113.128/26 in site 2, PE2 advertises it with label 9000 and NEXT_HOP 198.51.100.1 to PE1 and PE3 via BGP. Likewise, for the IPv6 prefix 2001:db8:1:2::/64 in site 2, PE2 advertises it with label 9001 and NEXT_HOP 198.51.100.1 to PE1 and PE3 via BGP.
PE2は、IPv4とIPv6の両方のVPNインスタンスに対して、仮想ルーティングおよび転送（VRF）ごとにラベル割り当てモードを使用します。ラベル9000をIPv4 VRFに割り当て、ラベル9001をIPv6 VRFに割り当てます。サイト2のIPv4プレフィックス203.0.113.128/26の場合、PE2はラベル9000とNEXT_HOP 198.51.100.1を使用して、BGP経由でPE1とPE3にそれをアドバタイズします。同様に、サイト2のIPv6プレフィックス2001：db8：1：2 :: / 64の場合、PE2はラベル9001およびNEXT_HOP 198.51.100.1でBGPを介してPE1およびPE3にそれをアドバタイズします。
PE3 also uses per-VRF VPN label allocation mode for both of its IPv4 and IPv6 VPN instances. It assigns label 10000 to the IPv4 VRF and label 10001 to the IPv6 VRF. For the prefix 203.0.113.128/26 in site 2, PE3 advertises it with label 10000 and NEXT_HOP as itself to PE1 and PE2 via BGP. For the IPv6 prefix 2001:db8:1:2::/64 in site 2, PE3 advertises it with label 10001 and NEXT_HOP as itself to PE1 and PE2 via BGP.
PE3は、IPv4とIPv6の両方のVPNインスタンスに対して、VRFごとのVPNラベル割り当てモードも使用します。ラベル10000をIPv4 VRFに割り当て、ラベル10001をIPv6 VRFに割り当てます。サイト2のプレフィックス203.0.113.128/26の場合、PE3はそれをラベル10000とNEXT_HOPでそれ自体としてBGP経由でPE1とPE2にアドバタイズします。サイト2のIPv6プレフィックス2001：db8：1：2 :: / 64の場合、PE3はそれをラベル10001およびNEXT_HOPでそれ自体としてBGP経由でPE1およびPE2にアドバタイズします。
Upon receipt of the above BGP advertisements from PE2, PE1 uses the context ID 198.51.100.1 as the destination to compute a path for an egress-protected tunnel. The resultant path is PE1->R1->PE2. PE1 then uses RSVP to signal the tunnel, with the context ID 198.51.100.1 as the destination, with the "node protection desired" flag set in the SESSION_ATTRIBUTE of the RSVP Path message. Once the tunnel comes up, PE1 maps the VPN prefixes 203.0.113.128/26 and 2001:db8:1:2::/64 to the tunnel and installs a route for each prefix in the corresponding IPv4 or IPv6 VRF. The next hop of route 203.0.113.128/26 is a push of the VPN label 9000, followed by a push of the outgoing label of the egress-protected tunnel. The next hop of route 2001:db8:1:2::/64 is a push of the VPN label 9001, followed by a push of the outgoing label of the egress-protected tunnel.
PE2から上記のBGPアドバタイズを受信すると、PE1は、宛先としてコンテキストID 198.51.100.1を使用して、出力保護されたトンネルのパスを計算します。結果のパスはPE1-> R1-> PE2です。次に、PE1はRSVPを使用して、コンテキストID 198.51.100.1を宛先として、RSVPパスメッセージのSESSION_ATTRIBUTEに「ノード保護が必要」フラグを設定して、トンネルに信号を送信します。トンネルが起動すると、PE1はVPNプレフィックス203.0.113.128/26および2001：db8：1：2 :: / 64をトンネルにマップし、対応するIPv4またはIPv6 VRFに各プレフィックスのルートをインストールします。ルート203.0.113.128/26の次のホップは、VPNラベル9000のプッシュであり、その後に、出力保護されたトンネルの発信ラベルのプッシュが続きます。ルート2001：db8：1：2 :: / 64の次のホップは、VPNラベル9001のプッシュであり、その後に、出力保護されたトンネルの発信ラベルのプッシュが続きます。
Upon receipt of the above BGP advertisements from PE2, PE3 recognizes the context ID 198.51.100.1 in the NEXT_HOP attribute and installs a route for label 9000 and a route for label 9001 in the label table pe2.mpls. PE3 sets the next hop of route 9000 to the IPv4 protection VRF and the next hop of route 9001 to the IPv6 protection VRF. The IPv4 protection VRF contains the routes to the IPv4 prefixes in site 2. The IPv6 protection VRF contains the routes to the IPv6 prefixes in site 2. The next hops of these routes must be based on PE3's connectivity with site 2, even if the connectivity may not have the best metrics (e.g., Multi-Exit Discriminator (MED), local preference, etc.) to be used in PE3's own VRF. The next hops must not use any path traversing PE2. Note that the protection VRFs are a logical concept, and they may simply be PE3's own VRFs if they satisfy the requirement.
PE2から上記のBGPアドバタイズを受信すると、PE3はNEXT_HOP属性のコンテキストID 198.51.100.1を認識し、ラベル9000のルートとラベル9001のルートをラベルテーブルpe2.mplsにインストールします。 PE3は、ルート9000のネクストホップをIPv4保護VRFに設定し、ルート9001のネクストホップをIPv6保護VRFに設定します。 IPv4保護VRFには、サイト2のIPv4プレフィックスへのルートが含まれています。IPv6保護VRFには、サイト2のIPv6プレフィックスへのルートが含まれています。これらのルートのネクストホップは、サイト2とのPE3の接続に基づいている必要があります。 PE3独自のVRFで使用するのに最適なメトリック（たとえば、Multi-Exit Discriminator（MED）、ローカル設定など）がない場合があります。ネクストホップは、PE2を通過するパスを使用してはなりません。保護VRFは論理的な概念であり、要件を満たす場合、それらは単にPE3独自のVRFである可能性があることに注意してください。
R1, i.e., the penultimate hop router of the egress-protected tunnel, serves as the PLR for egress node protection. Based on the "node protection desired" flag and the destination address (i.e., context ID 198.51.100.1) of the tunnel, R1 computes a bypass path to 198.51.100.1 while avoiding PE2. The resultant bypass path is R1->R2->PE3. R1 then signals the path (i.e., egress-protection bypass tunnel), with 198.51.100.1 as the destination.
R1、つまり出力保護されたトンネルの最後から2番目のホップルーターは、出力ノード保護のPLRとして機能します。 「ノード保護が必要」フラグとトンネルの宛先アドレス（つまり、コンテキストID 198.51.100.1）に基づいて、R1はPE2を回避しながら198.51.100.1へのバイパスパスを計算します。結果のバイパスパスは、R1-> R2-> PE3です。次にR1は、宛先として198.51.100.1を使用して、パス（つまり、出力保護バイパストンネル）に信号を送ります。
Upon receipt of an RSVP Path message of the egress-protection bypass tunnel, PE3 recognizes the context ID 198.51.100.1 as the destination and responds with context label 100 in an RSVP Resv message.
PE3は、出口保護バイパストンネルのRSVPパスメッセージを受信すると、コンテキストID 198.51.100.1を宛先として認識し、RSVP Resvメッセージでコンテキストラベル100で応答します。
After the egress-protection bypass tunnel comes up, R1 installs a bypass next hop for the egress-protected tunnel. The bypass next hop is a label swap from the incoming label of the egress-protected tunnel to the outgoing label of the egress-protection bypass tunnel.
出力保護バイパストンネルが起動すると、R1は出力保護トンネルのバイパスネクストホップをインストールします。バイパスネクストホップは、出力保護トンネルの着信ラベルから出力保護バイパストンネルの発信ラベルへのラベルスワップです。
When R1 detects a failure of PE2, it will invoke the above bypass next hop to reroute VPN packets. Each IPv4 VPN packet will have the label of the bypass tunnel as outer label, and the IPv4 VPN label 9000 as inner label. Each IPv6 VPN packet will have the label of the bypass tunnel as the outer label and the IPv6 VPN label 9001 as the inner label. When the packets arrive at PE3, they will have the context label 100 as the outer label and the VPN label 9000 or 9001 as the inner label. The context label will first be popped, and then the VPN label will be looked up in the label table pe2.mpls. The lookup will cause the VPN label to be popped and the IPv4 and IPv6 packets to be forwarded to site 2 based on the IPv4 and IPv6 protection VRFs, respectively.
R1がPE2の障害を検出すると、上記のバイパスネクストホップを呼び出して、VPNパケットを再ルーティングします。各IPv4 VPNパケットには、外部トンネルとしてバイパストンネルのラベルがあり、内部ラベルとしてIPv4 VPNラベル9000があります。各IPv6 VPNパケットには、外側のラベルとしてバイパストンネルのラベルがあり、内側のラベルとしてIPv6 VPNラベル9001があります。パケットがPE3に到着すると、コンテキストラベル100が外部ラベル、VPNラベル9000または9001が内部ラベルになります。最初にコンテキストラベルがポップされ、次にVPNラベルがラベルテーブルpe2.mplsで検索されます。ルックアップにより、VPNラベルがポップされ、IPv4およびIPv6パケットがそれぞれIPv4およびIPv6保護VRFに基づいてサイト2に転送されます。
PE2 serves as the PLR for egress link protection. It has already learned PE3's IPv4 VPN label 10000 and IPv6 VPN label 10001. Hence, it uses approach (2) as described in Section 6 to set up the bypass forwarding state. It signals an egress-protection bypass tunnel to PE3, by using the path PE2->R3->PE3, and PE3's IP address as the destination. After the bypass tunnel comes up, PE2 installs a bypass next hop for the IPv4 VPN label 9000 and a bypass next hop for the IPv6 VPN label 9001. For label 9000, the bypass next hop is a label swap to label 10000, followed by a label push with the outgoing label of the bypass tunnel. For label 9001, the bypass next hop is a label swap to label 10001, followed by a label push with the outgoing label of the bypass tunnel.
PE2は、出力リンク保護のPLRとして機能します。 PE3のIPv4 VPNラベル10000およびIPv6 VPNラベル10001をすでに学習しています。したがって、6章で説明したアプローチ（2）を使用して、バイパス転送状態を設定します。パスPE2-> R3-> PE3、およびPE3のIPアドレスを宛先として使用して、出力保護バイパストンネルをPE3に通知します。バイパストンネルが起動すると、PE2はIPv4 VPNラベル9000のバイパスネクストホップとIPv6 VPNラベル9001のバイパスネクストホップをインストールします。ラベル9000の場合、バイパスネクストホップはラベル10000へのラベルスワップで、その後にバイパストンネルの発信ラベルを使用したラベルプッシュ。ラベル9001の場合、バイパスネクストホップは、ラベル10001へのラベルスワップであり、その後にバイパストンネルの発信ラベルを持つラベルプッシュが続きます。
When PE2 detects a failure of the egress link, it will invoke the above bypass next hop to reroute VPN packets. Each IPv4 VPN packet will have the label of the bypass tunnel as the outer label and label 10000 as the inner label. Each IPv6 VPN packet will have the label of the bypass tunnel as the outer label and label 10001 as the inner label. When the packets arrive at PE3, the VPN label 10000 or 10001 will be popped, and the exposed IPv4 and IPv6 packets will be forwarded based on PE3's IPv4 and IPv6 VRFs, respectively.
PE2は、出力リンクの障害を検出すると、上記のバイパスネクストホップを呼び出して、VPNパケットを再ルーティングします。各IPv4 VPNパケットには、バイパストンネルのラベルが外部ラベルとして、ラベル10000が内部ラベルとして含まれます。各IPv6 VPNパケットには、外部トンネルとしてバイパストンネルのラベルがあり、内部ラベルとしてラベル10001があります。パケットがPE3に到着すると、VPNラベル10000または10001がポップされ、公開されたIPv4およびIPv6パケットは、それぞれPE3のIPv4およびIPv6 VRFに基づいて転送されます。
Eventually, global repair will take effect, as control-plane protocols converge on the new topology. PE1 will choose PE3 as a new entrance to site 2. Before that happens, the VPN traffic has been protected by the above local repair.
最終的に、コントロールプレーンプロトコルが新しいトポロジに収束すると、グローバルな修復が有効になります。 PE1はサイト2への新しい入り口としてPE3を選択します。その前に、VPNトラフィックは上記のローカル修復によって保護されています。
It is also possible that PE2 may use per-route or per-interface VPN label allocation mode. In either case, PE3 will have multiple VPN label routes in the pe2.mpls table, corresponding to the VPN labels advertised by PE2. PE3 forwards rerouted packets by popping a VPN label and performing an IP lookup in the corresponding protection VRF. PE3's forwarding behavior is consistent with the above case where PE2 uses per-VRF VPN label allocation mode. PE3 does not need to know PE2's VPN label allocation mode or construct a specific next hop for each VPN label route in the pe2.mpls table.
PE2がルートごとまたはインターフェイスごとのVPNラベル割り当てモードを使用することも可能です。どちらの場合でも、PE3は、pe2.mplsテーブルに、PE2によってアドバタイズされたVPNラベルに対応する複数のVPNラベルルートを持ちます。 PE3は、VPNラベルをポップし、対応する保護VRFでIPルックアップを実行することにより、再ルーティングされたパケットを転送します。 PE3の転送動作は、PE2がVRFごとのVPNラベル割り当てモードを使用する上記のケースと一致しています。 PE3は、PE2のVPNラベル割り当てモードを認識したり、pe2.mplsテーブルで各VPNラベルルートの特定のネクストホップを構築したりする必要はありません。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
The framework in this document involves rerouting traffic around an egress node or link failure, via a bypass path from a PLR to a protector, and ultimately to a backup egress router. The forwarding performed by the routers in the data plane is anticipated, as part of the planning of egress protection.
このドキュメントのフレームワークには、PLRからプロテクター、そして最終的にはバックアップ出力ルーターへのバイパスパスを介して、出力ノードまたはリンク障害の周りのトラフィックを再ルーティングすることが含まれます。出力保護の計画の一環として、データプレーンのルーターによって実行される転送が予想されます。
Control-plane protocols MAY be used to facilitate the provisioning of the egress protection on the routers. In particular, the framework requires a service label distribution protocol between an egress router and a protector over a secure session. The security properties of this provisioning and label distribution depend entirely on the underlying protocol chosen to implement these activities. Their associated security considerations apply. This framework introduces no new security requirements or guarantees relative to these activities.
コントロールプレーンプロトコルを使用して、ルーターの出力保護のプロビジョニングを容易にすることができます。特に、フレームワークでは、安全なセッションを介した出口ルーターとプロテクター間のサービスラベル配布プロトコルが必要です。このプロビジョニングとラベル配布のセキュリティプロパティは、これらのアクティビティを実装するために選択された基になるプロトコルに完全に依存しています。関連するセキュリティ上の考慮事項が適用されます。このフレームワークでは、これらのアクティビティに関連する新しいセキュリティ要件や保証は導入されていません。
Also, the PLR, protector, and backup egress router are located close to the protected egress router, which is normally in the same administrative domain. If they are not in the same administrative domain, a certain level of trust MUST be established between them in order for the protocols to run securely across the domain boundary. The basis of this trust is the security model of the protocols (as described above), and further security considerations for inter-domain scenarios should be addressed by the protocols as a common requirement.
また、PLR、プロテクター、およびバックアップ出力ルーターは、通常同じ管理ドメインにある保護された出力ルーターの近くに配置されます。それらが同じ管理ドメイン内にない場合、プロトコルがドメインの境界を越えて安全に実行されるように、それらの間で特定のレベルの信頼を確立する必要があります。この信頼の基礎は、プロトコルのセキュリティモデル（上記のとおり）であり、ドメイン間シナリオのセキュリティに関するさらなる考慮事項は、共通の要件としてプロトコルで対処する必要があります。
Security attacks may sometimes come from a customer domain. Such attacks are not introduced by the framework in this document and may occur regardless of the existence of egress protection. In one possible case, the egress link between an egress router and a CE could become a point of attack. An attacker that gains control of the CE might use it to simulate link failures and trigger constant and cascading activities in the network. If egress link protection is in place, egress link protection activities may also be triggered. As a general solution to defeat the attack, a damping mechanism SHOULD be used by the egress router to promptly suppress the services associated with the link or CE. The egress router would stop advertising the services, essentially detaching them from the network and eliminating the effect of the simulated link failures.
セキュリティ攻撃は、お客様のドメインから発生する場合があります。このような攻撃は、このドキュメントのフレームワークでは紹介されておらず、出力保護の有無に関係なく発生する可能性があります。考えられる1つのケースでは、出力ルータとCE間の出力リンクが攻撃ポイントになる可能性があります。 CEの制御を取得した攻撃者は、CEを使用してリンク障害をシミュレートし、ネットワーク内で継続的かつ連鎖的なアクティビティをトリガーする可能性があります。出力リンク保護が設定されている場合は、出力リンク保護アクティビティもトリガーされることがあります。攻撃を無効にするための一般的な解決策として、リンクまたはCEに関連付けられているサービスを迅速に抑制するために、減衰メカニズムを出力ルーターで使用する必要があります（SHOULD）。出力ルーターはサービスのアドバタイズを停止し、基本的にサービスをネットワークから切り離し、シミュレートされたリンク障害の影響を排除します。
From the above perspectives, this framework does not introduce any new security threat to networks.
上記の観点から、このフレームワークはネットワークに新しいセキュリティの脅威をもたらしません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402] Filsfils、C。、編、Previdi、S。、編、Ginsberg、L.、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、RFC 8402、DOI 10.17487 / RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[RFC8667] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, <https://www.rfc-editor.org/info/rfc8667>.
[RFC8667] Previdi、S.、Ginsberg、L.、Filsfils、C.、Bashandy、A.、Gredler、H。、およびB. Decraene、「IS-IS Extensions for Segment Routing」、RFC 8667、DOI 10.17487 / RFC8667 、2019年12月、<https://www.rfc-editor.org/info/rfc8667>。
[BGP-PIC] Bashandy, A., Filsfils, C., and P. Mohapatra, "BGP Prefix Independent Convergence", Work in Progress, Internet-Draft, draft-ietf-rtgwg-bgp-pic-10, 2 October 2019, <https://tools.ietf.org/html/draft-ietf-rtgwg-bgp-pic-10>.
[BGP-PIC] Bashandy、A.、Filsfils、C。、およびP. Mohapatra、「BGP Prefix Independent Convergence」、Work in Progress、Internet-Draft、draft-ietf-rtgwg-bgp-pic-10、2019年10月2日、<https://tools.ietf.org/html/draft-ietf-rtgwg-bgp-pic-10>。
[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, <https://www.rfc-editor.org/info/rfc4090>.
[RFC4090] Pan、P。、編、Swallow、G、編、A。Atlas、編、「LSPトンネル用のRSVP-TEへの高速リルート拡張」、RFC 4090、DOI 10.17487 / RFC4090、2005年5月、<https://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, <https://www.rfc-editor.org/info/rfc5286>.
[RFC5286]アトラス、A。、エド。およびA. Zinin編、「IP Fast Rerouteの基本仕様：ループフリー代替」、RFC 5286、DOI 10.17487 / RFC5286、2008年9月、<https://www.rfc-editor.org/info/rfc5286> 。
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, DOI 10.17487/RFC7490, April 2015, <https://www.rfc-editor.org/info/rfc7490>.
[RFC7490]ブライアント、S。、フィルスフィルス、C。、プレビディ、S。、シャンド、M。、およびN.したがって、「リモートループフリー代替（LFA）高速再ルーティング（FRR）」、RFC 7490、DOI 10.17487 / RFC7490、2015年4月、<https://www.rfc-editor.org/info/rfc7490>。
[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, <https://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月、< https://www.rfc-editor.org/info/rfc7812>。
[RFC8104] Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang, "Pseudowire (PW) Endpoint Fast Failure Protection", RFC 8104, DOI 10.17487/RFC8104, March 2017, <https://www.rfc-editor.org/info/rfc8104>.
[RFC8104] Shen、Y.、Aggarwal、R.、Henderickx、W。、およびY. Jiang、「Pseudowire（PW）Endpoint Fast Failure Protection」、RFC 8104、DOI 10.17487 / RFC8104、2017年3月、<https：// www.rfc-editor.org/info/rfc8104>。
[RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang, "Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June 2018, <https://www.rfc-editor.org/info/rfc8400>.
[RFC8400] Chen、H.、Liu、A.、Saad、T.、Xu、F.、L。Huang、「Extensions for RSVP-TE for Label Switched Path（LSP）Egress Protection」、RFC 8400、DOI 10.17487 / RFC8400、2018年6月、<https://www.rfc-editor.org/info/rfc8400>。
Acknowledgements
謝辞
This document leverages work done by Yakov Rekhter, Kevin Wang, and Zhaohui Zhang on MPLS egress protection. Thanks to Alexander Vainshtein, Rolf Winter, Lizhong Jin, Krzysztof Szarkowicz, Roman Danyliw, and Yuanlong Jiang for their valuable comments that helped to shape this document and improve its clarity.
このドキュメントでは、MPLS出力保護に関してYakov Rekhter、Kevin Wang、Zhaohui Zhangが行った作業を活用しています。この文書を形作り、その明快さを改善するのに役立つ貴重なコメントを提供してくれたAlexander Vainshtein、Rolf Winter、Lizhong Jin、Krzysztof Szarkowicz、Roman Danyliw、Yuanlong Jiangに感謝します。
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 978 589 0722
Email: yshen@juniper.net
Minto Jeyananth Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America
Minto Jeyananth Juniper Networks 1133 Innovation Way Sunnyvale、CA 94089アメリカ合衆国
Phone: +1 408 936 7563
Email: minto@juniper.net
Bruno Decraene Orange
ブルーノデクレイエンオレンジ
Email: bruno.decraene@orange.com
Hannes Gredler RtBrick Inc.
Hannes Gredler RtBrick Inc.
Email: hannes@rtbrick.com
Carsten Michel Deutsche Telekom
カルステンミシェルドイツテレコム
Email: c.michel@telekom.de
Huaimo Chen Futurewei Boston, MA United States of America
Huaimo Chen Futurewei Boston、MAアメリカ合衆国
Email: Huaimo.chen@futurewei.com