[要約] RFC 7965は、ラベルスイッチパス（LSP）トンネルへの擬似ワイヤバインディングのためのLDP拡張に関するものです。このRFCの目的は、LDPを使用して擬似ワイヤをLSPトンネルにバインドするための手順と要件を定義することです。
Internet Engineering Task Force (IETF) M. Chen
Request for Comments: 7965 W. Cao
Category: Standards Track Huawei
ISSN: 2070-1721 A. Takacs
Ericsson
P. Pan
August 2016
LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels
ラベルスイッチドパス（LSP）トンネルへの疑似配線バインディング用のLDP拡張
Abstract
概要
Many transport services require that user traffic, in the form of Pseudowires (PWs), be delivered via either a single co-routed bidirectional tunnel or two unidirectional tunnels that share the same routes. This document defines an optional extension to the Label Distribution Protocol (LDP) that enables the binding between PWs and the underlying Traffic Engineering (TE) tunnels. The extension applies to both single-segment and multi-segment PWs.
多くのトランスポートサービスでは、疑似配線（PW）の形式のユーザートラフィックが、同じルートを共有する単一の双方向ルートトンネルまたは2つの単方向トンネルのいずれかを介して配信される必要があります。このドキュメントでは、PWと基になるトラフィックエンジニアリング（TE）トンネル間のバインディングを可能にするラベル配布プロトコル（LDP）のオプションの拡張機能を定義します。拡張機能は、単一セグメントと複数セグメントの両方の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/rfc7965.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7965で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. PSN Tunnel Binding TLV . . . . . . . . . . . . . . . . . 5
3.1.1. PSN Tunnel Sub-TLV . . . . . . . . . . . . . . . . . 7
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8
5. PSN Binding Operation for SS-PW . . . . . . . . . . . . . . . 9
6. PSN Binding Operation for MS-PW . . . . . . . . . . . . . . . 11
7. PSN Tunnel Select Considerations . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. LDP TLV Types . . . . . . . . . . . . . . . . . . . . . . 13
9.1.1. PSN Tunnel Sub-TLVs . . . . . . . . . . . . . . . . . 14
9.2. LDP Status Codes . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Pseudo Wire Emulation Edge-to-Edge (PWE3) [RFC3985] is a mechanism to emulate Layer 2 services, such as Ethernet Point-to-Point circuits. Such services are emulated between two Attachment Circuits, and the Pseudowire-encapsulated Layer 2 service payload is transported via Packet Switching Network (PSN) tunnels between Provider Edges (PEs). PWE3 typically uses the Label Distribution Protocol (LDP) [RFC5036] or Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [RFC3209] Label Switched Paths (LSPs) as PSN tunnels. The PEs select and bind the Pseudowires to PSN tunnels independently. Today, there is no standardized protocol-based provisioning mechanism to associate PWs with PSN tunnels; such associations must be managed via provisioning or other private methods.
疑似ワイヤーエミュレーションエッジツーエッジ（PWE3）[RFC3985]は、イーサネットポイントツーポイント回路などのレイヤー2サービスをエミュレートするメカニズムです。このようなサービスは2つの接続回線間でエミュレートされ、疑似配線カプセル化されたレイヤー2サービスペイロードは、プロバイダーエッジ（PE）間のパケットスイッチングネットワーク（PSN）トンネルを介して転送されます。 PWE3は通常、ラベル配布プロトコル（LDP）[RFC5036]またはリソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE）[RFC3209]ラベルスイッチドパス（LSP）をPSNトンネルとして使用します。 PEは、疑似配線を選択してPSNトンネルに個別にバインドします。現在、PWをPSNトンネルに関連付ける標準化されたプロトコルベースのプロビジョニングメカニズムはありません。このような関連付けは、プロビジョニングまたはその他のプライベートな方法で管理する必要があります。
PW-to-PSN Tunnel Binding has become increasingly common and important in many deployment scenarios, as it allows service providers to offer service level agreements to their customers for such traffic attributes as bandwidth, latency, and availability.
PW-to-PSNトンネルバインディングは、サービスプロバイダーが帯域幅、遅延、可用性などのトラフィック属性についてサービスレベル契約を顧客に提供できるようになるため、多くの展開シナリオでますます一般的かつ重要になっています。
The requirements for explicit control of PW-to-LSP mapping are described in Section 5.3.2 of [RFC6373]. Figure 1 illustrates how PWs can be bound to particular LSPs.
PWからLSPへのマッピングを明示的に制御するための要件は、[RFC6373]のセクション5.3.2で説明されています。図1は、PWを特定のLSPにバインドする方法を示しています。
+------+ +------+
---AC1 ---|..............PWs...............|---AC1---
---...----| PE1 |=======LSPs=======| PE2 |---...---
---ACn ---| |-------Links------| |---ACn---
+------+ +------+
Figure 1: Explicit PW-to-LSP Binding Scenario
図1：明示的なPWからLSPへのバインドのシナリオ
There are two PEs (PE1 and PE2) connected through multiple parallel links that may be on different physical fibers. Each link is managed and controlled as a bidirectional LSP. At each PE, there are a large number of bidirectional user flows from multiple Ethernet interfaces (access circuits in the figure). Each user flow utilizes a pair of unidirectional PWs to carry bidirectional traffic. The operators need to make sure that the user flows (that is, the PW-pairs) are carried on the same fiber or bidirectional LSP.
異なる物理ファイバー上にある可能性のある複数の並列リンクを介して接続された2つのPE（PE1およびPE2）があります。各リンクは、双方向LSPとして管理および制御されます。各PEには、複数のイーサネットインターフェイス（図のアクセス回線）からの多数の双方向ユーザーフローがあります。各ユーザーフローは、一対の単方向PWを利用して双方向トラフィックを伝送します。オペレーターは、ユーザーフロー（つまり、PWペア）が同じファイバーまたは双方向LSPで伝送されることを確認する必要があります。
There are a number of reasons behind this requirement. First, due to delay and latency constraints, traffic going over different fibers may require a large amount of expensive buffer memory to compensate for the differential delay at the head-end nodes. Further, the operators may apply different protection mechanisms on different parts of the network (e.g., to deploy 1:1 protection in one part and 1+1 protection in other parts). As such, operators may prefer to have a user's traffic traverse the same fiber. That implies that both forwarding and reserve direction PWs that belong to the same user flow need to be mapped to the same co-routed bidirectional LSP or two LSPs with the same route.
この要件にはいくつかの理由があります。まず、遅延とレイテンシの制約により、異なるファイバーを経由するトラフィックは、ヘッドエンドノードでの遅延差を補償するために、大量の高価なバッファーメモリを必要とする場合があります。さらに、事業者はネットワークの異なる部分に異なる保護メカニズムを適用する場合があります（たとえば、1つの部分に1：1の保護を、他の部分に1 + 1の保護を展開するため）。そのため、オペレーターはユーザーのトラフィックが同じファイバーを通過することを好むかもしれません。つまり、同じユーザーフローに属する転送方向と予約方向の両方のPWを、同じルートを持つ同じルートの双方向LSPまたは2つのLSPにマップする必要があります。
Figure 2 illustrates a scenario where PW-LSP binding is not applied.
図2は、PW-LSPバインディングが適用されていないシナリオを示しています。
+----+ +--+ LSP1 +--+ +----+
+-----+ | PE1|===|P1|======|P2|===| PE2| +-----+
| |----| | +--+ +--+ | |----| |
| CE1 | |............PW................| | CE2 |
| |----| | +--+ | |----| |
+-----+ | |======|P3|==========| | +-----+
+----+ +--+ LSP2 +----+
Figure 2: Inconsistent SS-PW-to-LSP Binding Scenario
図2：一貫性のないSS-PWからLSPへのバインドのシナリオ
LSP1 and LSP2 are two bidirectional connections on diverse paths. The operator needs to deliver a bidirectional flow between PE1 and PE2. Using existing mechanisms, it's possible that PE1 may select LSP1 (PE1-P1-P2-PE2) as the PSN tunnel for traffic from PE1 to PE2, while selecting LSP2 (PE2-P3-PE1) as the PSN tunnel for traffic from PE2 to PE1.
LSP1とLSP2は、さまざまなパス上の2つの双方向接続です。オペレーターは、PE1とPE2の間に双方向フローを提供する必要があります。既存のメカニズムを使用して、PE1がPE1からPE2へのトラフィックのPSNトンネルとしてLSP1（PE1-P1-P2-PE2）を選択し、PE2からPE2へのトラフィックのPSNトンネルとしてLSP2（PE2-P3-PE1）を選択する可能性があります。 PE1。
Consequently, the user traffic is delivered over two disjointed LSPs that may have very different service attributes in terms of latency and protection. This may not be acceptable as a reliable and effective transport service to the customer.
その結果、ユーザートラフィックは、レイテンシと保護の点で非常に異なるサービス属性を持つ2つのばらばらのLSPを介して配信されます。これは、信頼できる効果的な顧客への輸送サービスとして受け入れられない場合があります。
A similar problem may also exist in multi-segment PWs (MS-PWs), where user traffic on a particular PW may hop over different networks in forward and reverse directions.
同様の問題がマルチセグメントPW（MS-PW）にも存在する可能性があり、特定のPW上のユーザートラフィックが異なるネットワークを順方向と逆方向にホップする可能性があります。
One way to solve this problem is by introducing manual provisioning at each PE to bind the PWs to the underlying PSN tunnels. However, this is prone to configuration errors and does not scale.
この問題を解決する1つの方法は、各PEに手動プロビジョニングを導入して、PWを基礎となるPSNトンネルにバインドすることです。ただし、これは構成エラーが発生しやすく、拡張されません。
This document introduces an automatic solution by extending Forwarding Equivalence Class (FEC) 128/129 PW based on [RFC4447].
このドキュメントは、[RFC4447]に基づいてForwarding Equivalence Class（FEC）128/129 PWを拡張することによる自動ソリューションを紹介します。
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 defines a new optional TLV, the PSN Tunnel Binding TLV, to communicate tunnel/LSP selection and binding requests between PEs. The TLV carries a PW's binding profile and provides explicit or implicit information for the underlying PSN Tunnel Binding operation.
このドキュメントでは、PE間でトンネル/ LSP選択およびバインディング要求を通信するための新しいオプションのTLV、PSNトンネルバインディングTLVを定義します。 TLVはPWのバインディングプロファイルを伝送し、基礎となるPSNトンネルバインディング操作の明示的または暗黙的な情報を提供します。
The binding operation applies in both single-segment (SS) and multi-segment (MS) scenarios.
バインド操作は、単一セグメント（SS）と複数セグメント（MS）の両方のシナリオに適用されます。
The extension supports two types of binding requests:
拡張機能は、2つのタイプのバインディング要求をサポートします。
1. Strict binding: The requesting PE will choose and explicitly indicate the LSP information in the requests; the receiving PE MUST obey the requests; otherwise, the PW will not be established.
1. 厳密なバインディング：要求側のPEは、要求内のLSP情報を選択して明示的に示します。受信側PEは要求に従う必要があります。そうでない場合、PWは確立されません。
2. Co-routed binding: The requesting PE will suggest an underlying LSP to a remote PE. Upon receipt, the remote PE has the option to use the suggested LSP or reply to the information for an alternative.
2. 共同ルーティングバインディング：要求しているPEは、基になるLSPをリモートPEに提案します。受信すると、リモートPEは、提案されたLSPを使用するか、情報に返信して代替を選択できます。
In this document, the term "tunnel" is identical to the "TE Tunnel" defined in Section 2.1 of [RFC3209], which is uniquely identified by a SESSION object that includes the Tunnel endpoint address, the Tunnel ID, and the Extended Tunnel ID. The term "LSP" is identical to the "LSP tunnel" defined in Section 2.1 of [RFC3209], which is uniquely identified by the SESSION object together with the SENDER_TEMPLATE (or FILTER_SPEC) object that consists of the LSP ID and the Tunnel endpoint address.
このドキュメントでは、「トンネル」という用語は、[RFC3209]のセクション2.1で定義されている「TEトンネル」と同じであり、トンネルエンドポイントアドレス、トンネルID、および拡張トンネルIDを含むSESSIONオブジェクトによって一意に識別されます。 。 「LSP」という用語は、[RFC3209]のセクション2.1で定義されている「LSPトンネル」と同じであり、LSP IDとトンネルエンドポイントアドレスで構成されるSENDER_TEMPLATE（またはFILTER_SPEC）オブジェクトとともにSESSIONオブジェクトによって一意に識別されます。
The PSN Tunnel Binding TLV is an optional TLV and MUST be carried in the LDP Label Mapping message [RFC5036] if PW-to-LSP binding is required. The format is as follows:
PSNトンネルバインディングTLVはオプションのTLVであり、PW-to-LSPバインディングが必要な場合は、LDPラベルマッピングメッセージ[RFC5036]で伝達する必要があります。形式は次のとおりです。
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| PSN Tunnel Binding(0x0973)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|S|T| Unallocated flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ PSN Tunnel Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PSN Tunnel Binding TLV
図3：PSNトンネルバインディングTLV
The U-bit and F-bit are defined in Section 3.3 [RFC5036]. Since the PSN Tunnel Binding TLV is an optional TLV, 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ビットとFビットはセクション3.3 [RFC5036]で定義されています。 PSNトンネルバインディングTLVはオプションのTLVであるため、Uビットを1に設定する必要があります。これにより、不明な場合は受信者がこのTLVを黙って無視し、メッセージの残りの処理を続行する必要があります。
A receiver of this TLV is not allowed to forward the TLV further when it does not know the TLV. So, the F-bit MUST be set to 0.
このTLVの受信者は、TLVを知らない場合、TLVをさらに転送することはできません。したがって、Fビットは0に設定する必要があります。
The PSN Tunnel Binding TLV type is 0x0973.
PSNトンネルバインディングTLVタイプは0x0973です。
The Length field is 2 octets long. It defines the length in octets of the value field (including Flags, Reserved, and sub-TLV fields).
長さフィールドは2オクテット長です。値フィールドの長さをオクテットで定義します（フラグ、予約済み、およびサブTLVフィールドを含む）。
The Flags field is 2 octets in length and three flags are defined in this document. The rest of the unallocated flags MUST be set to zero when sending and MUST be ignored when received.
Flagsフィールドは長さが2オクテットで、このドキュメントでは3つのフラグが定義されています。残りの未割り当てフラグは、送信時にゼロに設定する必要があり、受信時に無視する必要があります。
C (Co-routed path) bit: This bit informs the remote T-PE/S-PEs about the properties of the underlying LSPs. When set, the remote T-PE/S-PEs SHOULD select the co-routed LSP (as the forwarding tunnel) as the reverse PSN tunnel. If there is no such tunnel available, it may trigger the remote T-PE/S-PEs to establish a new LSP.
C（共同経路）ビット：このビットは、基になるLSPのプロパティについてリモートT-PE / S-PEに通知します。設定されている場合、リモートT-PE / S-PEは、（転送トンネルとして）共ルーティングされたLSPを逆PSNトンネルとして選択する必要があります（SHOULD）。このようなトンネルが利用できない場合、リモートT-PE / S-PEをトリガーして新しいLSPを確立することがあります。
S (Strict) bit: This bit instructs the PEs with respect to the handling of the underlying LSPs. When set, the remote PE MUST use the tunnel/LSP specified in the PSN Tunnel Sub-TLV as the PSN tunnel on the reverse direction of the PW, or the PW will fail to be established.
S（厳格）ビット：このビットは、基礎となるLSPの処理に関してPEに指示します。設定すると、リモートPEはPSNトンネルサブTLVで指定されたトンネル/ LSPをPWの逆方向のPSNトンネルとして使用する必要があります。そうしないと、PWの確立に失敗します。
Either the C-bit or the S-bit MUST be set. The C-bit and S-bit are mutually exclusive from each other, and they cannot be set in the same message. If a status code set to "both C-bit and S-bit are set" or "both C-bit and S-bit are clear" is received, a Label Release message with the status code set to "The C-bit or S-bit unknown" (0x0000003C) MUST be the reply, and the PW will not be established.
CビットまたはSビットのいずれかを設定する必要があります。 CビットとSビットは相互に排他的であり、同じメッセージに設定することはできません。 「CビットとSビットの両方が設定されている」または「CビットとSビットの両方がクリアされている」に設定されたステータスコードを受信した場合、ステータスコードが「CビットまたはSビットS-bit unknown "（0x0000003C）は応答である必要があり、PWは確立されません。
T (Tunnel Representation) bit: This bit indicates the format of the LSP tunnels. When the bit is set, the tunnel uses the tunnel information to identify itself, and the LSP Number fields in the PSN Tunnel sub-TLV (Section 3.1.1) MUST be set to zero. Otherwise, both the tunnel and LSP information of the PSN tunnel are required. The default is set. The motivation for the T-bit is to support the MPLS protection operation where the LSP Number fields may be ignored.
T（トンネル表現）ビット：このビットは、LSPトンネルのフォーマットを示します。ビットが設定されると、トンネルはトンネル情報を使用してそれ自体を識別し、PSNトンネルサブTLV（セクション3.1.1）のLSP番号フィールドはゼロに設定する必要があります。それ以外の場合は、PSNトンネルのトンネル情報とLSP情報の両方が必要です。デフォルトが設定されています。 Tビットの動機は、LSP番号フィールドが無視されるMPLS保護動作をサポートすることです。
The Reserved field is 2 octets in length and is left for future use.
予約フィールドの長さは2オクテットで、将来の使用のために残されています。
PSN Tunnel Sub-TLVs are designed for inclusion in the PSN Tunnel Binding TLV to specify the tunnel/LSPs to which a PW is required to bind.
PSNトンネルサブTLVは、PSWトンネルバインディングTLVに含めるように設計されており、PWがバインドする必要のあるトンネル/ LSPを指定します。
Two sub-TLVs are defined: The IPv4 and IPv6 Tunnel sub-TLVs.
IPv4およびIPv6トンネルサブTLVの2つのサブ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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1) | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Number | Source LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Tunnel Number | Destination LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
Figure 4: IPv4 PSN Tunnel Sub-TLV Format
図4：IPv4 PSNトンネルサブ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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (2) | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Source Node ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Number | Source LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Destination Node ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Tunnel Number | Destination LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv6 PSN Tunnel Sub-TLV Format
図5：IPv6 PSNトンネルサブTLV形式
The definition of the Source and Destination Global/Node IDs and Tunnel/LSP Numbers are derived from [RFC6370]. This describes the underlying LSPs. Note that the LSPs in this notation are globally unique. The ITU-T style identifiers [RFC6923] are not used in this document.
送信元と宛先のグローバル/ノードIDとトンネル/ LSP番号の定義は、[RFC6370]から派生しています。これは、基になるLSPについて説明します。この表記のLSPはグローバルに一意であることに注意してください。 ITU-Tスタイル識別子[RFC6923]は、このドキュメントでは使用されていません。
As defined in Sections 4.6.1.1 and 4.6.1.2 of [RFC3209], the "Tunnel endpoint address" is mapped to the Destination Node ID, and the "Extended Tunnel ID" is mapped to the Source Node ID. Both IDs can be either IPv4 or IPv6 addresses. The Node IDs are routable addresses of the ingress LSR and egress LSR of the Tunnel/LSP.
[RFC3209]のセクション4.6.1.1および4.6.1.2で定義されているように、「トンネルエンドポイントアドレス」は宛先ノードIDにマップされ、「拡張トンネルID」はソースノードIDにマップされます。どちらのIDもIPv4またはIPv6アドレスのいずれかです。ノードIDは、トンネル/ LSPの入力LSRおよび出力LSRのルーティング可能なアドレスです。
A PSN Tunnel sub-TLV could be used to identify either a tunnel or a specific LSP. The T-bit in the Flags field defines the distinction as such that, when the T-bit is set, the Source/Destination LSP Number fields MUST be zero and ignored during processing. Otherwise, both Source/Destination LSP Number fields MUST have the actual LSP IDs of specific LSPs.
PSNトンネルサブTLVは、トンネルまたは特定のLSPを識別するために使用できます。 FlagsフィールドのTビットは、Tビットが設定されている場合、Source / Destination LSP番号フィールドがゼロであり、処理中に無視されるように、区別を定義します。それ以外の場合、送信元/宛先LSP番号フィールドの両方に、特定のLSPの実際のLSP IDが必要です。
Each PSN Tunnel Binding TLV MUST only have one such sub-TLV. When sending, only one sub-TLV MUST be carried. When received, if there are more than one sub-TLVs carried, only the first sub-TLV MUST be used, the rest of the sub-TLVs MUST be ignored.
各PSNトンネルバインディングTLVは、そのようなサブTLVを1つだけ持つ必要があります。送信するときは、1つのサブTLVのみを伝送する必要があります。受信時に、複数のサブTLVが運ばれる場合、最初のサブTLVのみを使用する必要があり、残りのサブTLVは無視する必要があります。
During PW setup, the PEs may choose to select the desired forwarding tunnels/LSPs and inform the remote T-PE/S-PEs about the desired reverse tunnels/LSPs.
PWのセットアップ中に、PEは目的の転送トンネル/ LSPを選択し、目的の逆方向トンネル/ LSPについてリモートT-PE / S-PEに通知することを選択できます。
Specifically, to set up a PW (or PW Segment), a PE may select a candidate tunnel/LSP to act as the PSN tunnel. If no candidate is available or none satisfy the constraints, the PE will trigger and establish a new tunnel/LSP. The selected tunnel/LSP information is carried in the PSN Tunnel Binding TLV and sent with the Label Mapping message to the target PE.
具体的には、PW（またはPWセグメント）を設定するために、PEはPSNトンネルとして機能する候補トンネル/ LSPを選択できます。使用可能な候補がない場合、または制約を満たすものがない場合、PEは新しいトンネル/ LSPをトリガーして確立します。選択されたトンネル/ LSP情報は、PSNトンネルバインディングTLVで伝達され、ラベルマッピングメッセージと共にターゲットPEに送信されます。
Upon the reception of the Label Mapping message, the receiving PE will process the PSN Tunnel Binding TLV, determine whether it can accept the suggested tunnel/LSP or to find the reverse tunnel/LSP that meets the request, and respond with a Label Mapping message, which contains the corresponding PSN Tunnel Binding TLV.
ラベルマッピングメッセージを受信すると、受信側PEはPSNトンネルバインディングTLVを処理し、提案されたトンネル/ LSPを受け入れることができるかどうか、または要求を満たすリバーストンネル/ LSPを見つけて、ラベルマッピングメッセージで応答するかどうかを決定します、対応するPSNトンネルバインディングTLVが含まれます。
It is possible that two PEs request PSN Binding to the same PW or PW segment over different tunnels/LSPs at the same time. This may cause collisions of tunnel/LSPs selection as both PEs assume the active role.
2つのPEが、異なるトンネル/ LSP上の同じPWまたはPWセグメントへのPSNバインディングを同時に要求する可能性があります。これにより、両方のPEがアクティブな役割を引き受けるため、トンネル/ LSP選択の衝突が発生する可能性があります。
As defined in (Section 7.2.1, [RFC6073]), each PE may be categorized into active and passive roles:
（セクション7.2.1、[RFC6073]）で定義されているように、各PEはアクティブロールとパッシブロールに分類できます。
1. Active PE: The PE that initiates the selection of the tunnel/LSPs and informs the remote PE;
1. アクティブPE：トンネル/ LSPの選択を開始し、リモートPEに通知するPE。
2. Passive PE: The PE that obeys the active PE's suggestion.
2. パッシブPE：アクティブPEの提案に従うPE。
In the rest of this document, we will elaborate upon the operation for SS-PW and MS-PW:
このドキュメントの残りの部分では、SS-PWおよびMS-PWの操作について詳しく説明します。
1. SS-PW: In this scenario, both PEs for a particular PW may assume the active roles.
1. SS-PW：このシナリオでは、特定のPWの両方のPEがアクティブな役割を担う場合があります。
2. MS-PW: One PE is active, while the other is passive. The PWs are set up using FEC 129.
2. MS-PW：1つのPEがアクティブで、もう1つはパッシブです。 PWはFEC 129を使用して設定されます。
As illustrated in Figure 6, both PEs (e.g., PE1 and PE2) of a PW may independently initiate the setup. To perform PSN Binding, the Label Mapping messages MUST carry a PSN Tunnel Binding TLV, and the PSN Tunnel sub-TLV MUST contain the desired tunnel/LSPs of the sender.
図6に示すように、PWの両方のPE（PE1とPE2など）は、セットアップを個別に開始できます。 PSNバインディングを実行するには、ラベルマッピングメッセージにPSNトンネルバインディングTLVが含まれている必要があり、PSNトンネルサブTLVには送信者の目的のトンネル/ LSPが含まれている必要があります。
+----+ LSP1 +----+
+-----+ | PE1|====================| PE2| +-----+
| |----| | | |----| |
| CE1 | |............PW................| | CE2 |
| |----| | | |----| |
+-----+ | |====================| | +-----+
+----+ LSP2 +----+
Figure 6: PSN Binding Operation in SS-PW Environment
図6：SS-PW環境でのPSNバインディング操作
As outlined previously, there are two types of binding requests: co-routed and strict.
前に概説したように、バインディング要求には、共ルーティングと厳密の2つのタイプがあります。
In strict binding, a PE (e.g., PE1) will mandate that the other PE (e.g., PE2) use a specified tunnel/LSP (e.g., LSP1) as the PSN tunnel on the reverse direction. In the PSN Tunnel Binding TLV, the S-bit MUST be set, the C-bit MUST be cleared, and the Source and Destination IDs/Numbers MUST be filled.
厳密なバインディングでは、PE（たとえば、PE1）は、他のPE（たとえば、PE2）が指定されたトンネル/ LSP（たとえば、LSP1）を逆方向のPSNトンネルとして使用することを義務付けます。 PSNトンネルバインディングTLVでは、Sビットを設定する必要があり、Cビットをクリアする必要があり、送信元と宛先のID /番号を入力する必要があります。
Upon receipt, if the S-bit is set, as well as following the processing procedure defined in Section 5.3.3 of [RFC4447], the receiving PE (i.e., PE2) needs to determine whether to accept the indicated tunnel/LSP in PSN Tunnel Sub-TLV.
受信時にSビットが設定されている場合、および[RFC4447]のセクション5.3.3で定義されている処理手順に従う場合、受信側のPE（つまり、PE2）は、指定されたトンネル/ LSPをPSNで受け入れるかどうかを決定する必要がありますトンネルサブTLV。
The receiving PE (PE2) may also be an active PE, and it may have initiated the PSN Binding requests to the other PE (PE1); if the received PSN tunnel/LSP is the same as was sent in the Label Mapping message by PE2, then the signaling has converged on a mutually agreed upon Tunnel/LSP. The binding operation is completed.
受信側PE（PE2）もアクティブPEである可能性があり、他のPE（PE1）へのPSNバインディング要求を開始した可能性があります。受信したPSNトンネル/ LSPがPE2によってラベルマッピングメッセージで送信されたものと同じである場合、シグナリングは相互に合意したトンネル/ LSPに収束しています。バインド操作が完了しました。
Otherwise, the receiving PE (PE2) MUST compare its own Node ID against the received Source Node ID as unsigned integers. If the received Source Node ID is larger, the PE (PE2) will reply with a Label Mapping message to complete the PW setup and confirm the binding request. The PSN Tunnel Binding TLV in the message MUST contain the same Source and Destination IDs/Numbers as in the received binding request, in the appropriate order (where the source is PE2 and PE1 becomes the destination). On the other hand, if the receiving PE (PE2) has a Node ID that is larger than the Source Node ID carried in the PSN Tunnel Binding TLV, it MUST reply with a Label Release message with the status code set to "Reject - unable to use the suggested tunnel/LSPs", and the received PSN Tunnel Binding TLV, and the PW will not be established.
それ以外の場合、受信側のPE（PE2）は、自身のノードIDを受信したソースノードIDと符号なし整数として比較する必要があります。受信したソースノードIDの方が大きい場合、PE（PE2）はラベルマッピングメッセージで応答し、PWセットアップを完了してバインディング要求を確認します。メッセージ内のPSNトンネルバインディングTLVには、受信したバインディング要求と同じ送信元および宛先ID /番号を適切な順序で含める必要があります（送信元がPE2で、PE1が宛先になります）。一方、受信側PE（PE2）のノードIDがPSNトンネルバインディングTLVで伝送されるソースノードIDより大きい場合、ステータスコードを「拒否-できません」に設定したラベル解放メッセージで応答する必要があります。提案されたトンネル/ LSPを使用するには」、および受信したPSNトンネルバインディングTLV、およびPWは確立されません。
To support co-routed binding, the receiving PE can select the appropriate PSN tunnel/LSP for the reverse direction of the PW, so long as the forwarding and reverse PSNs share the same route (links and nodes).
転送ルーティングと逆PSNが同じルート（リンクとノード）を共有している限り、共ルーティングバインディングをサポートするために、受信PEはPWの逆方向に適切なPSNトンネル/ LSPを選択できます。
Initially, a PE (PE1) sends a Label Mapping message to the remote PE (PE2) with the PSN Tunnel Binding TLV, with C-bit set, S-bit cleared, and the appropriate Source and Destination IDs/Numbers. In case of unidirectional LSPs, the PSN Tunnel Binding TLV may only contain the Source IDs/Numbers; the Destination IDs/Numbers are set to zero and left for PE2 to complete when responding to the Label Mapping message.
最初に、PE（PE1）は、PSNトンネルバインディングTLV、Cビットセット、Sビットクリア、適切な送信元および宛先ID /番号を使用して、ラベルマッピングメッセージをリモートPE（PE2）に送信します。単方向LSPの場合、PSNトンネルバインディングTLVにはソースID /番号のみを含めることができます。宛先ID /番号はゼロに設定され、ラベルマッピングメッセージに応答するときにPE2が完了するために残されます。
Upon receipt, since PE2 is also an active PE, and may have initiated the PSN Binding requests to the other PE (PE1), if the received PSN tunnel/LSP has the same route as the one that has been sent in the Label Mapping message to PE1, then the signaling has converged. The binding operation is completed.
受信すると、PE2はアクティブなPEでもあり、他のPE（PE1）へのPSNバインディング要求を開始した可能性があるため、受信したPSNトンネル/ LSPがラベルマッピングメッセージで送信されたものと同じルートを持っている場合PE1に、それからシグナリングは収束しました。バインド操作が完了しました。
Otherwise, PE2 needs to compare its own Node ID against the received Source Node ID as unsigned integers. If the received Source Node ID is larger, PE2 needs to find/establish a tunnel/LSP that meets the co-routed constraint, and reply with a Label Mapping message that has a PSN Binding TLV that contains the Source and Destination IDs/ Numbers of the tunnel/LSP. On the other hand, if the receiving PE (PE2) has a Node ID that is larger than the Source Node ID carried in the PSN Tunnel Binding TLV, it MUST reply with a Label Release message that has a status code set to "Reject - unable to use the suggested tunnel/LSPs" (0x0000003B) and the received PSN Tunnel Binding TLV.
それ以外の場合、PE2は、自身のノードIDを、受信したソースノードIDと符号なし整数として比較する必要があります。受信した送信元ノードIDの方が大きい場合、PE2は、同じルートの制約を満たすトンネル/ LSPを検出/確立し、送信元IDと宛先ID /の数を含むPSNバインディングTLVを含むラベルマッピングメッセージで応答する必要があります。トンネル/ LSP。一方、受信側PE（PE2）のノードIDがPSNトンネルバインディングTLVで伝送されるソースノードIDより大きい場合、ステータスコードが「拒否-提案されたトンネル/ LSP（0x0000003B）および受信したPSNトンネルバインディングTLVを使用できません。
In addition, if the received PSN tunnel/LSP endpoints do not match the PW endpoints, PE2 MUST reply with a Label Release message with the status code set to "Reject - unable to use the suggested tunnel/LSPs" (0x0000003B) and the received PSN Tunnel Binding TLV MUST also be carried.
さらに、受信したPSNトンネル/ LSPエンドポイントがPWエンドポイントと一致しない場合、PE2は、ステータスコードを「拒否-提案されたトンネル/ LSPを使用できない」（0x0000003B）に設定したラベル解放メッセージで応答する必要があります。 PSNトンネルバインディングTLVも実行する必要があります。
In both strict and co-routed bindings, if the T-bit is set, the LSP Number field MUST be set to zero. Otherwise, the field MUST contain the actual LSP number for the related PSN LSP.
厳密なバインディングと共同ルーティングバインディングの両方で、Tビットが設定されている場合は、LSP番号フィールドをゼロに設定する必要があります。それ以外の場合、フィールドには、関連するPSN LSPの実際のLSP番号が含まれている必要があります。
After a PW is established, the operators may choose to move the PWs from the current tunnel/LSPs to other tunnel/LSPs. Also, the underlying PSN tunnel may break due to a network failure. When either of these scenarios occur, a new Label Mapping message MUST be sent to notify the remote PE of the changes. Note that when the T-bit is set, the working LSP broken will not provide this update if there are protection LSPs in place.
PWが確立された後、オペレータはPWを現在のトンネル/ LSPから他のトンネル/ LSPに移動することを選択できます。また、基になるPSNトンネルは、ネットワーク障害が原因で壊れることがあります。これらのシナリオのいずれかが発生した場合、新しいラベルマッピングメッセージを送信して、変更をリモートPEに通知する必要があります。 Tビットが設定されている場合、保護LSPが配置されていると、機能しているLSPが壊れてもこのアップデートは提供されません。
The message may carry a new PSN Tunnel Binding TLV, which contains the new Source and Destination Numbers/IDs. The handling of the new message should be identical to what has been described in this section.
メッセージは、新しい送信元番号と宛先番号/ IDを含む新しいPSNトンネルバインディングTLVを運ぶ場合があります。新しいメッセージの処理は、このセクションで説明したものと同じでなければなりません。
However, if the new Label Mapping message does not contain the PSN Tunnel Binding TLV, it declares the removal of any co-routed/strict constraints. The current independent PW-to-PSN Binding will be used.
ただし、新しいラベルマッピングメッセージにPSNトンネルバインディングTLVが含まれていない場合は、同じルートの/厳密な制約の削除を宣言します。現在の独立したPW-to-PSNバインディングが使用されます。
Further, as an implementation option, the PEs may choose not to remove the traffic from an operational PW until the completion of the underlying PSN tunnel/LSP changes.
さらに、実装オプションとして、基礎となるPSNトンネル/ LSPの変更が完了するまで、PEは運用PWからトラフィックを削除しないことを選択できます。
MS-PW uses FEC 129 for PW setup. We refer to Figure 7 for this operation.
MS-PWはPWセットアップにFEC 129を使用します。この操作については、図7を参照してください。
+-----+ LSP1 +-----+ LSP2 +-----+ LSP3 +-----+
+---+ |T-PE1|======|S-PE1|======|S-PE2|======|T-PE2| +---+
| |---| | | | | | | |---| |
|CE1| |......................PW....................| |CE2|
| |---| | | | | | | |---| |
+---+ | |======| |======| |======| | +---+
+-----+ LSP4 +-----+ LSP5 +-----+ LSP6 +-----+
Figure 7: PSN Binding Operation in MS-PW Environment
図7：MS-PW環境でのPSNバインディング操作
When an active PE (that is, T-PE1) starts to signal an MS-PW, a PSN Tunnel Binding TLV MUST be carried in the Label Mapping message and sent to the adjacent S-PE (that is, S-PE1). The PSN Tunnel Binding TLV includes the PSN Tunnel sub-TLV that carries the desired tunnel/LSP of T-PE1.
アクティブなPE（つまり、T-PE1）がMS-PWに信号を送り始めると、PSNトンネルバインディングTLVがラベルマッピングメッセージで運ばれ、隣接するS-PE（つまり、S-PE1）に送信される必要があります。 PSNトンネルバインディングTLVには、T-PE1の目的のトンネル/ LSPを伝送するPSNトンネルサブTLVが含まれています。
For strict binding, the initiating PE MUST set the S-bit, clear the C-bit, and indicate the binding tunnel/LSP to the next-hop S-PE.
厳密なバインディングの場合、開始PEはSビットを設定し、Cビットをクリアして、ネクストホップS-PEにバインディングトンネル/ LSPを示す必要があります。
When S-PE1 receives the Label Mapping message, it needs to determine if the signaling is for the forward or reverse direction, as defined in Section 4.2.3 of [RFC7267].
[RFC7267]のセクション4.2.3で定義されているように、S-PE1はラベルマッピングメッセージを受信すると、シグナリングが順方向か逆方向かを判別する必要があります。
If the Label Mapping message is for the forward direction, and S-PE1 accepts the requested tunnel/LSPs from T-PE1, S-PE1 MUST save the tunnel/LSP information for reverse-direction processing later on. If the PSN Binding request is not acceptable, S-PE1 MUST reply with a Label Release Message to the upstream PE (T-PE1) with the status code set to "Reject - unable to use the suggested tunnel/LSPs" (0x0000003B).
ラベルマッピングメッセージが順方向であり、S-PE1がT-PE1からの要求されたトンネル/ LSPを受け入れる場合、S-PE1は後で逆方向処理のためにトンネル/ LSP情報を保存する必要があります。 PSNバインディング要求が受け入れられない場合、S-PE1は、ステータスコードを「拒否-提案されたトンネル/ LSPを使用できない」（0x0000003B）に設定して、ラベル解放メッセージを上流のPE（T-PE1）に返信する必要があります。
Otherwise, S-PE1 relays the Label Mapping message to the next S-PE (that is, S-PE2), with the PSN Tunnel sub-TLV carrying the information of the new PSN tunnel/LSPs selected by S-PE1. S-PE2 and subsequent S-PEs will repeat the same operation until the Label Mapping message reaches to the remote T-PE (that is, T-PE2).
それ以外の場合、S-PE1はラベルマッピングメッセージを次のS-PE（つまり、S-PE2）にリレーし、PSNトンネルサブTLVはS-PE1によって選択された新しいPSNトンネル/ LSPの情報を伝送します。 S-PE2以降のS-PEは、Label MappingメッセージがリモートT-PE（つまり、T-PE2）に到達するまで同じ操作を繰り返します。
If T-PE2 agrees with the requested tunnel/LSPs, it will reply with a Label Mapping message to initiate the binding process in the reverse direction. The Label Mapping message contains the received PSN Tunnel Binding TLV for confirmation purposes.
T-PE2が要求されたトンネル/ LSPに同意した場合、T-PE2はラベルマッピングメッセージで応答して、逆方向のバインディングプロセスを開始します。ラベルマッピングメッセージには、確認のために受信したPSNトンネルバインディングTLVが含まれています。
When its upstream S-PE (S-PE2) receives the Label Mapping message, the S-PE relays the Label Mapping message to its upstream adjacent S-PE (S-PE1), with the previously saved PSN tunnel/LSP information in the PSN Tunnel sub-TLV. The same procedure will be applied on subsequent S-PEs, until the message reaches T-PE1 to complete the PSN Binding setup.
上流のS-PE（S-PE2）がラベルマッピングメッセージを受信すると、S-PEはラベルマッピングメッセージを上流の隣接するS-PE（S-PE1）にリレーし、以前に保存されたPSNトンネル/ LSP情報をPSNトンネルサブTLV。メッセージがT-PE1に到達してPSNバインディングのセットアップを完了するまで、同じ手順が後続のS-PEに適用されます。
During the binding process, if any PE does not agree to the requested tunnel/LSPs, it can send a Label Release Message to its upstream adjacent PE with the status code set to "Reject - unable to use the suggested tunnel/LSPs" (0x0000003B). In addition, if the received PSN tunnel/LSP endpoints do not match the PW Segment endpoints, the receiving PE MUST reply with a Label Release message with the status code set to "Reject - unable to use the suggested tunnel/LSPs" (0x0000003B) and the received PSN Tunnel Binding TLV MUST also be carried.
バインドプロセス中に、要求されたトンネル/ LSPに同意しないPEがある場合、ステータスコードを「拒否-提案されたトンネル/ LSPを使用できない」に設定して、ラベル解放メッセージを上流の隣接PEに送信できます（0x0000003B ）。さらに、受信したPSNトンネル/ LSPエンドポイントがPWセグメントエンドポイントと一致しない場合、受信側のPEは、ステータスコードが「拒否-提案されたトンネル/ LSPを使用できない」（0x0000003B）に設定されたラベル解放メッセージで応答する必要があります。受信したPSNトンネルバインディングTLVも伝送する必要があります。
For co-routed binding, the initiating PE (T-PE1) MUST set the C-bit, reset the S-bit, and indicate the suggested tunnel/LSP in the PSN Tunnel sub-TLV to the next-hop S-PE (S-PE1).
共同ルーティングされたバインディングの場合、開始PE（T-PE1）はCビットを設定し、Sビットをリセットし、PSNトンネルサブTLVの推奨トンネル/ LSPをネクストホップS-PEに示す必要があります（ S-PE1）。
During the MS-PW setup, the PEs have the option of ignoring the suggested tunnel/LSP, and to select another tunnel/LSP for the segment PW between itself and its upstream PE in reverse direction only if the tunnel/LSP is co-routed with the forward one. Otherwise, the procedure is the same as the strict binding.
MS-PWのセットアップ中に、PEには推奨されるトンネル/ LSPを無視するオプションがあり、トンネル/ LSPが同じルートである場合にのみ、自身とその上流PEの間のセグメントPWに対して逆方向に別のトンネル/ LSPを選択できます。前方のものと。それ以外の場合の手順は、厳密なバインディングと同じです。
The tunnel/LSPs may change after a MS-PW has been established. When a tunnel/LSP has changed, the PE that detects the change SHOULD select an alternative tunnel/LSP for temporary use while negotiating with other PEs following the procedure described in this section.
MS-PWが確立された後、トンネル/ LSPが変更される場合があります。トンネル/ LSPが変更された場合、変更を検出したPEは、このセクションで説明する手順に従って他のPEとネゴシエートするときに一時的に使用する代替トンネル/ LSPを選択する必要があります（SHOULD）。
As stated in Section 1, the PSN tunnel that is used for binding can be either a co-routed bidirectional LSP or two LSPs with the same route. The co-routed bidirectional LSP has the characteristics that both directions not only cross the same nodes and links, but have the same life span. But for the two LSPs case, even if they have the same route at the beginning, it cannot be guaranteed that they will always have the same route all the time. For example, when Fast ReRoute (FRR) [RFC4090] is deployed for the LSPs, link or node failure may make the two LSPs use different routes. So, if the network supports co-routed bidirectional LSPs, it is RECOMMENDED that a co-routed bidirectional LSP should be used; otherwise, two LSPs with the same route may be used.
セクション1で述べたように、バインディングに使用されるPSNトンネルは、同じルートを持つ双方向ルーティングLSPまたは2つのLSPのいずれかです。コルーテッド双方向LSPには、両方向が同じノードとリンクを通過するだけでなく、同じ寿命を持つという特性があります。ただし、2つのLSPの場合、最初に同じルートがあったとしても、常に同じルートが常にあるとは限りません。たとえば、高速再ルーティング（FRR）[RFC4090]がLSPに展開されている場合、リンクまたはノードの障害により、2つのLSPが異なるルートを使用する場合があります。したがって、ネットワークが共同ルーティングされた双方向LSPをサポートしている場合は、共同ルーティングされた双方向LSPを使用することをお勧めします。それ以外の場合は、同じルートを持つ2つのLSPを使用できます。
The ability to control which LSP is used to carry traffic from a PW can be a potential security risk both for denial of service and traffic interception. It is RECOMMENDED that PEs not accept the use of LSPs identified in the PSN Tunnel Binding TLV unless the LSP endpoints match the PW or PW segment endpoints. Furthermore, it is RECOMMENDED that PEs implement the LDP security mechanisms described in [RFC5036] and [RFC5920].
PWからトラフィックを伝送するために使用されるLSPを制御する機能は、サービス拒否とトラフィック傍受の両方で潜在的なセキュリティリスクになる可能性があります。 LSPエンドポイントがPWまたはPWセグメントエンドポイントと一致しない限り、PEはPSNトンネルバインディングTLVで識別されたLSPの使用を受け入れないことをお勧めします。さらに、PEが[RFC5036]と[RFC5920]で説明されているLDPセキュリティメカニズムを実装することをお勧めします。
This document defines a new TLV (Section 3.1) for inclusion in the LDP Label Mapping message. IANA has assigned TLV type value 0x0973 from the "LDP TLV Type Name Space" registry.
このドキュメントでは、LDPラベルマッピングメッセージに含めるための新しいTLV（セクション3.1）を定義しています。 IANAは、「LDP TLVタイプ名前空間」レジストリからTLVタイプ値0x0973を割り当てました。
This document defines two sub-TLVs (Section 3.1.1) for the PSN Tunnel Binding TLV. IANA has created a new PWE3 subregistry titled "PSN Tunnel Sub-TLV Name Space" for PSN Tunnel sub-TLVs and has assigned Sub-TLV type values to the following sub-TLVs:
このドキュメントでは、PSNトンネルバインディングTLVの2つのサブTLV（セクション3.1.1）を定義しています。 IANAは、PSNトンネルサブTLVの「PSNトンネルサブTLV名前空間」という新しいPWE3サブレジストリを作成し、サブTLVタイプの値を次のサブTLVに割り当てました。
IPv4 PSN Tunnel sub-TLV - 1
IPv4 PSNトンネルサブTLV-1
IPv6 PSN Tunnel sub-TLV - 2
IPv6 PSNトンネルサブTLV-2
In addition, the values 0 and 255 in this new registry should be reserved, and values 1-254 will be allocated by IETF Review [RFC5226].
さらに、この新しいレジストリの値0と255は予約する必要があり、値1〜254はIETFレビュー[RFC5226]によって割り当てられます。
This document defines two new LDP status codes, IANA has assigned status codes to these new defined codes from the "LDP Status Code Name Space" registry.
このドキュメントでは、2つの新しいLDPステータスコードを定義します。IANAは、「LDPステータスコード名前空間」レジストリからこれらの新しく定義されたコードにステータスコードを割り当てました。
"Reject - unable to use the suggested tunnel/LSPs" - 0x0000003B
"The C-bit or S-bit unknown" - 0x0000003C
「CビットまたはSビットは不明」-0x0000003C
The E bit is set to 1 for both new codes.
Eビットは、両方の新しいコードで1に設定されます。
[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>。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, DOI 10.17487/RFC4447, April 2006, <http://www.rfc-editor.org/info/rfc4447>.
[RFC4447] Martini、L.、Ed。、Rosen、E.、El-Aawar、N.、Smith、T.、and G. Heron、 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol（LDP）"、RFC 4447 、DOI 10.17487 / RFC4447、2006年4月、<http://www.rfc-editor.org/info/rfc4447>。
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, DOI 10.17487/RFC6370, September 2011, <http://www.rfc-editor.org/info/rfc6370>.
[RFC6370] Bocci、M.、Swallow、G。、およびE. Gray、「MPLS Transport Profile（MPLS-TP）Identifiers」、RFC 6370、DOI 10.17487 / RFC6370、2011年9月、<http：//www.rfc- editor.org/info/rfc6370>。
[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>。
[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 >。
[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>。
[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>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[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>。
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, DOI 10.17487/RFC6073, January 2011, <http://www.rfc-editor.org/info/rfc6073>.
[RFC6073]マティーニ、L。、メッツ、C。、ナドー、T。、ボッチ、M。、およびM.アイサウイ、「セグメント化された疑似配線」、RFC 6073、DOI 10.17487 / RFC6073、2011年1月、<http：// www .rfc-editor.org / info / rfc6073>。
[RFC6373] Andersson, L., Ed., Berger, L., Ed., Fang, L., Ed., Bitar, N., Ed., and E. Gray, Ed., "MPLS Transport Profile (MPLS-TP) Control Plane Framework", RFC 6373, DOI 10.17487/RFC6373, September 2011, <http://www.rfc-editor.org/info/rfc6373>.
[RFC6373] Andersson、L.、Ed。、Berger、L.、Ed。、Fang、L.、Ed。、Bitar、N.、Ed。、and E. Gray、Ed。、 "MPLS Transport Profile（MPLS- TP）コントロールプレーンフレームワーク」、RFC 6373、DOI 10.17487 / RFC6373、2011年9月、<http://www.rfc-editor.org/info/rfc6373>。
[RFC6923] Winter, R., Gray, E., van Helvoort, H., and M. Betts, "MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions", RFC 6923, DOI 10.17487/RFC6923, May 2013, <http://www.rfc-editor.org/info/rfc6923>.
[RFC6923] Winter、R.、Gray、E.、van Helvoort、H。、およびM. Betts、「ITLS-T規則に従うMPLSトランスポートプロファイル（MPLS-TP）識別子」、RFC 6923、DOI 10.17487 / RFC6923、5月2013、<http://www.rfc-editor.org/info/rfc6923>。
[RFC7267] Martini, L., Ed., Bocci, M., Ed., and F. Balus, Ed., "Dynamic Placement of Multi-Segment Pseudowires", RFC 7267, DOI 10.17487/RFC7267, June 2014, <http://www.rfc-editor.org/info/rfc7267>.
[RFC7267] Martini、L.、Ed。、Bocci、M.、Ed。、and F. Balus、Ed。、 "Dynamic Placement of Multi-Segment Pseudowires"、RFC 7267、DOI 10.17487 / RFC7267、June 2014、<http ：//www.rfc-editor.org/info/rfc7267>。
Acknowledgements
謝辞
The authors would like to thank Adrian Farrel, Kamran Raza, Xinchun Guo, Mingming Zhu, and Li Xue for their comments and help in preparing this document. Also this document benefits from the discussions with Nabil Bitar, Paul Doolan, Frederic Journay, Andy Malis, Curtis Villamizar, Luca Martini, Alexander Vainshtein, Huub van Helvoort, Daniele Ceccarelli, and Stewart Bryant.
著者は、このドキュメントの作成に関するコメントと手助けをしてくれたAdrian Farrel、Kamran Raza、Xinchun Guo、Mingming Zhu、およびLi Xueに感謝します。また、このドキュメントは、Nabil Bitar、Paul Doolan、Frederic Journay、Andy Malis、Curtis Villamizar、Luca Martini、Alexander Vainshtein、Huub van Helvoort、Daniele Ceccarelli、およびStewart Bryantとの議論の恩恵を受けています。
We would especially like to acknowledge Ping Pan, a coauthor on the early draft versions of this document. It was a privilege to have known him.
このドキュメントの初期ドラフトバージョンの共著者であるPing Panに特に感謝いたします。彼と知り合ったのは光栄でした。
The coauthors of this document, the working group chairs, the responsible AD, and the PALS working group wish to dedicate this RFC to the memory of our friend and colleague Ping Pan, in recognition for his devotion and hard work at the IETF.
このドキュメントの共同執筆者、ワーキンググループチェア、責任あるAD、およびPALSワーキンググループは、IETFでの献身とハードワークを認めて、このRFCを友人や同僚のピンパンの記憶に捧げたいと考えています。
Authors' Addresses
著者のアドレス
Mach(Guoyi) Chen Huawei
マッハ（GUお一）陳湖Aは
Email: mach.chen@huawei.com
Wei Cao Huawei
Wei CAああUAは
Email: wayne.caowei@huawei.com
Attila Takacs Ericsson Laborc u. 1. Budapest 1037 Hungary
Attila Takacs Ericsson Laborc u。 1.ブダペスト1037ハンガリー
Email: attila.takacs@ericsson.com
Ping Pan
ピンパン