RFC 7392 - Explicit Path Routing for Dynamic Multi-Segment Pseudowires 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7392
タイトル : RFC 7392 - ダイナミックマルチセグメント疑似配線の明示的パスルーティング
翻訳編集 : 自動生成

[要約] RFC 7392は、動的なマルチセグメント疑似ワイヤのための明示的なパスルーティングに関する仕様です。このRFCの目的は、疑似ワイヤのパスを明示的に指定することで、ネットワークの効率性と柔軟性を向上させることです。

Internet Engineering Task Force (IETF)                          P. Dutta
Request for Comments: 7392                                      M. Bocci
Category: Standards Track                                 Alcatel-Lucent
ISSN: 2070-1721                                               L. Martini
                                                           Cisco Systems
                                                           December 2014

Explicit Path Routing for Dynamic Multi-Segment Pseudowires

ダイナミックマルチセグメント疑似配線の明示的パスルーティング

Abstract

概要

When set up through an explicit path, dynamic Multi-Segment Pseudowires (MS-PWs) may be required to provide a simple solution for 1:1 protection with diverse primary and backup MS-PWs for a service, or to enable controlled signaling (strict or loose) for special MS-PWs. This document specifies the extensions and procedures required to enable dynamic MS-PWs to be established along explicit paths.

明示的なパスを介して設定する場合、動的マルチセグメント疑似配線（MS-PW）は、サービスの多様なプライマリおよびバックアップMS-PWによる1：1保護のためのシンプルなソリューションを提供するか、制御されたシグナリング（厳密なまたは緩い）特殊なMS-PWの場合。このドキュメントでは、動的なMS-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 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7392.

このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7392で入手できます。

著作権表示

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 ....................................................2
   2. Requirements Language and Terminology ...........................3
   3. Explicit Path in MS-PW Signaling ................................3
      3.1. S-PE Addressing ............................................3
      3.2. Explicit Route TLV (ER-TLV) ................................3
      3.3. Explicit Route Hop TLV (ER-Hop TLV) ........................4
      3.4. ER-Hop Semantics ...........................................4
           3.4.1. ER-Hop Type: IPv4 Prefix ............................4
           3.4.2. ER-Hop Type: IPv6 Prefix ............................4
           3.4.3. ER-Hop Type: L2 PW Address ..........................5
   4. Explicit Route TLV Processing ...................................6
      4.1. Next-Hop Selection .........................................6
      4.2. Adding ER Hops to the Explicit Route TLV ...................8
   5. IANA Considerations .............................................8
   6. Security Considerations .........................................8
   7. Normative References ............................................9
   Acknowledgements ...................................................9
   Authors' Addresses ................................................10

1. Introduction

1. はじめに

Procedures for dynamically establishing Multi-Segment Pseudowires (MS-PWs), where their paths are automatically determined using a dynamic routing protocol, are defined in [RFC7267]. For 1:1 protection of MS-PWs with primary and backup paths, MS-PWs need to be established through a diverse set of Switching Provider Edges (S-PEs) to avoid any single points of failure at the PW level. [RFC7267] allows this through BGP-based mechanisms. This document defines an additional mechanism that allows Source Terminating Provider Edges (ST-PEs) to explicitly choose the path that a PW would take through the intervening S-PEs. Explicit path routing of dynamic MS-PWs may also be required for controlled setup of dynamic MS-PWs and network resource management.

パスが動的ルーティングプロトコルを使用して自動的に決定されるマルチセグメント疑似配線（MS-PW）を動的に確立する手順は、[RFC7267]で定義されています。プライマリパスとバックアップパスでMS-PWを1対1で保護するには、PWレベルでの単一障害点を回避するために、さまざまなスイッチングプロバイダーエッジ（S-PE）のセットを通じてMS-PWを確立する必要があります。 [RFC7267]は、BGPベースのメカニズムを通じてこれを可能にします。このドキュメントでは、送信元終端プロバイダーエッジ（ST-PE）がPWが介在するS-PEを通過するパスを明示的に選択できるようにする追加のメカニズムを定義します。動的MS-PWの制御されたセットアップおよびネットワークリソース管理のために、動的MS-PWの明示的なパスルーティングも必要になる場合があります。

Note that in many deployments the ST-PE will not have a view of the topology of S-PEs and so the explicit route will need to be supplied from a management application. How that management application determines the explicit route is outside the scope of this document.

多くの展開では、ST-PEはS-PEのトポロジのビューを持たないため、明示的なルートを管理アプリケーションから提供する必要があることに注意してください。その管理アプリケーションが明示的なルートを決定する方法は、このドキュメントの範囲外です。

2. Requirements Language and Terminology

2. 要件の言語と用語

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 uses the terminology defined in [RFC7267], [RFC4447], and [RFC5036].

このドキュメントでは、[RFC7267]、[RFC4447]、および[RFC5036]で定義されている用語を使用しています。

The following additional terminology is used:

以下の追加の用語が使用されます。

Abstract Node: A group of nodes (S-PEs) representing an explicit hop along the path of an MS-PW. An abstract node is identified by an IPv4, IPv6, or S-PE address.

抽象ノード：MS-PWのパスに沿った明示的なホップを表すノード（S-PE）のグループ。抽象ノードは、IPv4、IPv6、またはS-PEアドレスによって識別されます。

3. Explicit Path in MS-PW Signaling

3. MS-PWシグナリングの明示パス

This section describes the Label Distribution Protocol (LDP) extensions required for signaling explicit paths in dynamic MS-PW setup messages. An explicitly routed MS-PW is set up using a Label Mapping message that carries an ordered list of the S-PEs that the MS-PW is expected to traverse. The ordered list is encoded as a series of Explicit Route Hop TLVs (ER-Hop TLVs) encoded in an ER-TLV that is carried in a Label Mapping message.

このセクションでは、動的MS-PWセットアップメッセージで明示的なパスをシグナリングするために必要なラベル配布プロトコル（LDP）拡張について説明します。明示的にルーティングされるMS-PWは、MS-PWが通過すると予想されるS-PEの順序付きリストを運ぶラベルマッピングメッセージを使用してセットアップされます。順序付きリストは、ラベルマッピングメッセージで伝送されるER-TLVでエンコードされた一連の明示的ルートホップTLV（ER-Hop TLV）としてエンコードされます。

3.1. S-PE Addressing

3.1. S-PEアドレッシング

An S-PE address is used to identify a given S-PE among the set of S-PEs belonging to the Packet Switched Networks (PSNs) that may be used by an MS-PW. Each S-PE MUST be assigned an address as specified in Section 3.2 of [RFC7267]. An S-PE that is capable of dynamic MS-PW signaling, but has not been assigned an S-PE address, and that receives a Label Mapping message for a dynamic MS-PW MUST follow the procedures in Section 3.2 of [RFC7267].

S-PEアドレスは、MS-PWで使用できるパケット交換ネットワーク（PSN）に属するS-PEのセットから特定のS-PEを識別するために使用されます。各S-PEには、[RFC7267]のセクション3.2で指定されているアドレスを割り当てる必要があります。動的MS-PWシグナリングが可能であるが、S-PEアドレスが割り当てられておらず、動的MS-PWのラベルマッピングメッセージを受信するS-PEは、[RFC7267]のセクション3.2の手順に従う必要があります。

3.2. Explicit Route TLV (ER-TLV)

3.2. 明示ルートTLV（ER-TLV）

The ER-TLV specifies the path to be taken by the MS-PW being established. Each hop along the path is represented by an abstract node, which is a group of one or more S-PEs, identified by an IPv4, IPv6, or S-PE address. The ER-TLV format is as per Section 4.1 of [RFC3212].

ER-TLVは、確立されるMS-PWがたどるパスを指定します。パスに沿った各ホップは、IPv4、IPv6、またはS-PEアドレスで識別される1つ以上のS-PEのグループである抽象ノードによって表されます。 ER-TLV形式は、[RFC3212]のセクション4.1に準拠しています。

The ER-TLV contains one or more ER-Hop TLVs as defined in Section 3.3.

ER-TLVには、セクション3.3で定義されている1つ以上のER-Hop TLVが含まれています。

3.3. Explicit Route Hop TLV (ER-Hop TLV)

3.3. 明示的ルートホップTLV（ERホップTLV）

The contents of an ER-TLV are a series of variable-length ER-Hop TLVs. Each hop contains the identification of an "abstract node" that represents the hop to be traversed. The ER-Hop TLV format is as specified in Section 4.2 of [RFC3212].

ER-TLVの内容は、一連の可変長ER-Hop TLVです。各ホップには、通過するホップを表す「抽象ノード」のIDが含まれています。 ERホップTLV形式は、[RFC3212]のセクション4.2で指定されています。

[RFC3212] defines four ER-Hop TLV Types: IPv4 Prefix, IPv6 Prefix, Autonomous System Number, and LSP-ID. This document specifies the following new ER-Hop TLV Type:

[RFC3212]は、IPv4プレフィックス、IPv6プレフィックス、自律システム番号、LSP-IDの4つのERホップTLVタイプを定義しています。このドキュメントでは、次の新しいERホップTLVタイプを指定しています。

                 Value  Type
                 ------ --------------------------------
                 0x0805 L2 PW Address of Switching Point

ER-Hop TLV

ERホップTLV

Details of the ER-Hop semantics are defined in Section 3.4.

ER-Hopセマンティクスの詳細はセクション3.4で定義されています。

3.4. ER-Hop Semantics

3.4. ERホップのセマンティクス

This section describes the various semantics associated with the ER-Hop TLV.

このセクションでは、ERホップTLVに関連するさまざまなセマンティクスについて説明します。

3.4.1. ER-Hop Type: IPv4 Prefix

3.4.1. ERホップタイプ：IPv4プレフィックス

The semantics of the IPv4 ER-Hop TLV Type are specified in [RFC3212], Section 4.7.1.

IPv4 ERホップTLVタイプのセマンティクスは、[RFC3212]のセクション4.7.1で指定されています。

3.4.2. ER-Hop Type: IPv6 Prefix

3.4.2. ERホップタイプ：IPv6プレフィックス

The semantics of the IPv6 ER-Hop TLV Type are specified in [RFC3212], Section 4.7.2.

IPv6 ERホップTLVタイプのセマンティクスは、[RFC3212]のセクション4.7.2で指定されています。

3.4.3. ER-Hop Type: L2 PW Address

3.4.3. ERホップタイプ：L2 PWアドレス

The semantics of the L2 PW Address ER-Hop TLV Type, which contains the L2 PW Address derived from the Generalized PWid Forwarding Equivalence Class (FEC) AII Type 2 structure as defined in [RFC5003], are as follows.

[RFC5003]で定義されている一般化PWid転送等価クラス（FEC）AIIタイプ2構造から派生したL2 PWアドレスを含むL2 PWアドレスERホップTLVタイプのセマンティクスは、次のとおりです。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |U|F|      ER-Hop Type          |      Length = 18              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |L|             Reserved                        |    PreLen     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  AII Type=02  |    Length     |        Global ID              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Global ID (contd.)      |        Prefix                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Prefix (contd.)         |        AC ID                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      AC ID                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

U/F These bits MUST be set to zero and the procedures of [RFC5036] followed when the TLV is not known to the receiving node.

U / Fこれらのビットはゼロに設定しなければならず（MUST）、[LVC5036]の手順は、TLVが受信ノードに認識されていない場合に続きます。

Type A fourteen-bit field carrying the value of the ER-Hop 3, L2 PW Address, Value = 0x0805.

タイプERホップ3、L2 PWアドレスの値を運ぶ14ビットのフィールド、値= 0x0805。

Length Specifies the length of the value field in bytes = 18.

長さ値フィールドの長さをバイト数= 18で指定します。

L Bit Set to indicate a loose hop. Cleared to indicate a strict hop.

Lビットセットはルーズホップを示します。厳密なホップを示すためにクリアされます。

Reserved Zero on transmission. Ignored on receipt.

送信時に予約済みゼロ。領収書では無視されます。

PreLen Prefix Length 1-96 (including the length of the Global ID, Prefix, and AC ID fields).

PreLenプレフィックス長1-96（グローバルID、プレフィックス、AC IDフィールドの長さを含む）。

All other fields (AII Type, Length, Global ID, Prefix, and AC ID) define the L2 PW Address and are to be set and interpreted as defined in Section 3.2 of [RFC5003].

他のすべてのフィールド（AIIタイプ、長さ、グローバルID、プレフィックス、AC ID）はL2 PWアドレスを定義し、[RFC5003]のセクション3.2で定義されているように設定および解釈されます。

4. Explicit Route TLV Processing

4. 明示的なルートTLV処理

4.1. Next-Hop Selection

4.1. ネクストホップの選択

A PW Label Mapping message containing an Explicit Route TLV specifies the next hop for a given MS-PW path. Selection of this next hop by the ST-PE or S-PE inserting the ER-Hop TLV may involve a selection from a set of possible alternatives. The mechanism for making a selection from this set is implementation specific and is outside the scope of this document. The mechanism used to select a particular path is also outside the scope of this document, but each node MUST determine a loop-free path if it is to signal the MS-PW. [RFC6073], Section 7.6 provides a mechanism by which a node can check that the path taken by an MS-PW does not include loops.

明示的ルートTLVを含むPWラベルマッピングメッセージは、特定のMS-PWパスのネクストホップを指定します。 ER-Hop TLVを挿入するST-PEまたはS-PEによるこのネクストホップの選択には、一連の可能な選択肢からの選択が含まれる場合があります。このセットから選択するためのメカニズムは実装固有であり、このドキュメントの範囲外です。特定のパスを選択するために使用されるメカニズムもこのドキュメントの範囲外ですが、各ノードがMS-PWに信号を送る場合は、ループのないパスを決定する必要があります。 [RFC6073]、セクション7.6は、MS-PWがたどるパスにループが含まれていないことをノードが確認できるメカニズムを提供しています。

As noted in Section 1, in many deployments the ST-PE will not have a view of the topology of S-PEs and so the path will need to be supplied from a management application.

セクション1で述べたように、多くの展開では、ST-PEはS-PEのトポロジのビューを持たないため、管理アプリケーションからパスを提供する必要があります。

If a loop-free path cannot be found by an ST-PE or S-PE, then a node MUST NOT attempt to signal the MS-PW. For an S-PE, if it cannot determine a loop-free path, then the received Label Mapping message MUST be released with a status code of "PW Loop Detected" as per Section 4.2.3 of [RFC7267].

ループのないパスがST-PEまたはS-PEで見つからない場合、ノードはMS-PWに信号を送ろうとしてはなりません。 S-PEの場合、ループのないパスを判別できない場合、[RFC7267]のセクション4.2.3に従って、受信したラベルマッピングメッセージを「PWループが検出されました」というステータスコードで解放する必要があります。

To determine the next hop for the MS-PW path, a node performs the following steps. Note that these procedures assume that a valid S-PE address has been assigned to the node, as per Section 3.1, above.

MS-PWパスのネクストホップを決定するために、ノードは次の手順を実行します。これらの手順では、上記のセクション3.1に従って、有効なS-PEアドレスがノードに割り当てられていることを前提としています。

1. The node receiving the Label Mapping message that contains an ER-TLV MUST evaluate the first ER-Hop. If the L bit is not set in the first ER-Hop and if the node is not part of the abstract node described by the first ER-Hop (i.e., it does not lie within the prefix as determined by the prefix length specified in the ER-Hop TLV), it has received the message in error. Therefore, the node MUST reply with a Label Release message with a "Bad Initial ER-Hop Error" (0x04000004) status code. If the L bit is set and the local node is not part of the abstract node described by the first ER-Hop, the node selects a next hop that is along the path to the abstract node described by the first ER-Hop. If there is no ER-Hop TLV contained in the ER-TLV, the message is also in error, and the node SHOULD return a "Bad Explicit Routing TLV Error" (0x04000001) status code in a Label Release message sent to the upstream node. Note that this statement does not preclude a Label Mapping message with no ER-TLV. If a Label Mapping message with no ER-TLV is received, then it MUST be processed as per [RFC7267].

1. ER-TLVを含むラベルマッピングメッセージを受信するノードは、最初のERホップを評価する必要があります。 Lビットが最初のERホップで設定されておらず、ノードが最初のERホップで記述された抽象ノードの一部でない場合（つまり、ノードで指定されたプレフィックス長によって決定されるプレフィックス内にない場合） ER-Hop TLV）、エラーメッセージを受信しました。したがって、ノードは「Bad Initial ER-Hop Error」（0x04000004）ステータスコードを含むラベルリリースメッセージで応答する必要があります。 Lビットが設定されていて、ローカルノードが最初のERホップで記述された抽象ノードの一部でない場合、ノードは最初のERホップで記述された抽象ノードへのパスに沿った次のホップを選択します。 ER-TLVにER-Hop TLVが含まれていない場合、メッセージにもエラーがあり、ノードは上流ノードに送信されたラベル解放メッセージで「Bad Explicit Routing TLV Error」（0x04000001）ステータスコードを返す必要があります（SHOULD）。このステートメントは、ER-TLVのないラベルマッピングメッセージを排除しないことに注意してください。 ER-TLVのないラベルマッピングメッセージを受信した場合は、[RFC7267]に従って処理する必要があります。

2. If there are no further ER-Hop TLVs following the first ER-Hop TLV, this indicates the end of the explicit route. The Explicit Route TLV MUST be removed from the Label Mapping message. This node may or may not be the end of the PW. Processing continues as per Section 4.2, where a new Explicit Route TLV MAY be added to the Label Mapping message.

2. 最初のERホップTLVに続くERホップTLVがない場合、これは明示的なルートの終わりを示します。ラベルマッピングメッセージから明示的ルートTLVを削除する必要があります。このノードは、PWの終わりである場合とそうでない場合があります。セクション4.2に従って処理が続行されます。新しいマッピングルートTLVがラベルマッピングメッセージに追加される場合があります。

3. If a second ER-Hop TLV does exist, and the node is also a part of the abstract node described by the second ER-Hop, then the node deletes the first ER-Hop and continues processing with step 2, above. Note that this makes the second ER-Hop into the first ER-Hop for the iteration for the next PW segment.

3. 2番目のERホップTLVが存在し、ノードが2番目のERホップによって記述された抽象ノードの一部でもある場合、ノードは最初のERホップを削除し、上記のステップ2の処理を続行します。これにより、次のPWセグメントの反復のために、2番目のERホップが最初のERホップになります。

4. The node determines if it is topologically adjacent to the abstract node described by the second ER-Hop. That is, it is directly connected to the next node by a PW control-plane adjacency. If so, the node selects a particular next hop that is a member of the abstract node. The node then deletes the first ER-Hop and continues processing as per Section 4.2, below.

4. ノードは、2番目のERホップで記述された抽象ノードにトポロジ的に隣接しているかどうかを判断します。つまり、PWコントロールプレーン隣接関係によって次のノードに直接接続されます。もしそうなら、ノードは抽象ノードのメンバーである特定のネクストホップを選択します。次に、ノードは最初のERホップを削除し、以下のセクション4.2に従って処理を続行します。

5. Next, the node selects a next hop within the abstract node of the first ER-Hop that is along the path to the abstract node of the second ER-Hop. If no such path exists, then there are two cases:

5. 次に、ノードは、2番目のERホップの抽象ノードへのパスに沿った最初のERホップの抽象ノード内の次のホップを選択します。そのようなパスが存在しない場合、2つのケースがあります。

A. If the second ER-Hop is a strict ER Hop, then there is an error, and the node MUST return a Label Release message to the upstream node with a "Bad Strict Node Error" (0x04000002) status code.

A. 2番目のERホップが厳密なERホップである場合、エラーが発生し、ノードは「Bad Strict Node Error」（0x04000002）ステータスコードを含むラベルリリースメッセージを上流ノードに返さなければなりません（MUST）。

B. Otherwise, if the second ER-Hop is a loose ER Hop, then the node selects any next hop that is along the path to the next abstract node. If no path exists within the MPLS domain, then there is an error, and the node MUST return a Label Release message to the upstream node with a "Bad Loose Node Error" (0x04000003) status code.

B.それ以外の場合、2番目のERホップがルーズなERホップである場合、ノードは次の抽象ノードへのパスに沿った次のホップを選択します。 MPLSドメイン内にパスが存在しない場合、エラーが発生し、ノードは「Bad Loose Node Error」（0x04000003）ステータスコードを含むラベルリリースメッセージを上流ノードに返さなければなりません（MUST）。

6. Finally, the node replaces the first ER-Hop with any ER Hop that denotes an abstract node containing the next hop. This is necessary so that when the explicit route is received by the next hop, it will be accepted.

6. 最後に、ノードは最初のERホップを、ネクストホップを含む抽象ノードを示す任意のERホップに置き換えます。これは、明示的なルートがネクストホップで受信されたときに受け入れられるようにするために必要です。

7. Progress the Label Mapping message to the next hop.

7. ラベルマッピングメッセージを次のホップに進めます。

4.2. Adding ER Hops to the Explicit Route TLV

4.2. 明示的ルートTLVへのERホップの追加

After selecting a next hop, the node MAY alter the explicit route in the following ways.

ネクストホップを選択した後、ノードは次の方法で明示的なルートを変更してもよい（MAY）。

If, as part of executing the algorithm in Section 4.1, the Explicit Route TLV is removed, then the node MAY add a new Explicit Route TLV.

セクション4.1のアルゴリズムの実行の一環として、明示的ルートTLVが削除された場合、ノードは新しい明示的ルートTLVを追加してもよい（MAY）。

Otherwise, if the node is a member of the abstract node for the first ER-Hop, then a series of ER Hops MAY be inserted before the First ER Hop or the first ER-Hop MAY be replaced. Each ER Hop in this series MUST denote an abstract node that is a subset of the current abstract node.

それ以外の場合、ノードが最初のERホップの抽象ノードのメンバーである場合、一連のERホップが最初のERホップまたは最初のERホップが置き換えられる前に挿入される場合があります。このシリーズの各ERホップは、現在の抽象ノードのサブセットである抽象ノードを示す必要があります。

Alternately, if the first ER-Hop is a loose ER Hop, an arbitrary series of ER Hops MAY be inserted prior to the first ER-Hop.

あるいは、最初のERホップがルーズなERホップである場合、任意の一連のERホップを最初のERホップの前に挿入してもよい（MAY）。

5. IANA Considerations

5. IANAに関する考慮事項

RFC 5036 [RFC5036] defines the LDP TLV name space, which is maintained by IANA, in the LDP "TLV Type Name Space" registry. TLV types for the Explicit Route TLV, the IPv4 Prefix ER-Hop TLV, and the IPv6 Prefix ER-Hop TLV are already defined in this registry.

RFC 5036 [RFC5036]は、LDP "TLV Type Name Space"レジストリで、IANAによって維持されるLDP TLV名前空間を定義しています。明示ルートTLV、IPv4プレフィックスERホップTLV、およびIPv6プレフィックスERホップTLVのTLVタイプは、このレジストリですでに定義されています。

IANA has assigned a further code point from the IETF consensus portion of this registry as follows:

IANAは、次のように、このレジストリのIETFコンセンサス部分からさらにコードポイントを割り当てました。

      TLV Type                               Value   Reference
      ------------------------------------   ------  -------------
      L2 PW Address of Switching Point       0x0805  This Document

6. Security Considerations

6. セキュリティに関する考慮事項

This document introduces no new security considerations beyond those discussed in [RFC5036], [RFC4447], and [RFC7267]. The security considerations detailed in those documents apply to the protocol extensions described in this RFC.

このドキュメントでは、[RFC5036]、[RFC4447]、および[RFC7267]で説明されているものを超える新しいセキュリティの考慮事項を紹介していません。これらのドキュメントで詳述されているセキュリティの考慮事項は、このRFCで説明されているプロトコル拡張に適用されます。

As with [RFC7267], it should be noted that the path selection mechanisms specified in this document enable the network to automatically select the S-PEs that are used to forward packets on the MS-PW. Appropriate tools, such as the Virtual Circuit Connectivity Verification (VCCV) trace mechanisms specified in [RFC6073], can be used by an operator of the network to verify the path taken by the MS-PW and therefore be satisfied that the path does not represent an additional security risk.

[RFC7267]と同様に、このドキュメントで指定されているパス選択メカニズムにより、ネットワークはMS-PWでパケットを転送するために使用されるS-PEを自動的に選択できるようになります。 [RFC6073]で指定されているVirtual Circuit Connectivity Verification（VCCV）トレースメカニズムなどの適切なツールをネットワークのオペレーターが使用して、MS-PWがたどるパスを確認し、パスが表していないことを確認できます。追加のセキュリティリスク。

7. Normative References

7. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。

[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002, <http://www.rfc-editor.org/info/rfc3212>.

[RFC3212] Jamoussi、B.、Andersson、L.、Callon、R.、Dantu、R.、Wu、L.、Doolan、P.、Worster、T.、Feldman、N.、Fredette、A.、Girish、 M.、Gray、E.、Heinanen、J.、Kilty、T。、およびA. Malis、「LDPを使用した制約ベースのLSPセットアップ」、RFC 3212、2002年1月、<http：//www.rfc-editor。 org / info / rfc3212>。

[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006, <http://www.rfc-editor.org/info/rfc4447>.

[RFC4447] Martini、L.、Rosen、E.、El-Aawar、N.、Smith、T。、およびG. Heron、「Pseudowire Setup and Maintenance Using a Label Distribution Protocol（LDP）」、RFC 4447、2006年4月、<http://www.rfc-editor.org/info/rfc4447>。

[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007, <http://www.rfc-editor.org/info/rfc5003>.

[RFC5003] Metz、C.、Martini、L.、Balus、F.、J。Sugimoto、「Attachment Individual Identifier（AII）Types for Aggregation」、RFC 5003、2007年9月、<http：//www.rfc- editor.org/info/rfc5003>。

[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.

[RFC5036] Andersson、L.、Minei、I.、and B. Thomas、 "LDP Specification"、RFC 5036、October 2007、<http://www.rfc-editor.org/info/rfc5036>。

[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011, <http://www.rfc-editor.org/info/rfc6073>.

[RFC6073]マティーニ、L。、メッツ、C。、ナドー、T。、ボッチ、M。、およびM.アイサウィー、「セグメント化された疑似配線」、RFC 6073、2011年1月、<http：//www.rfc-editor。 org / info / rfc6073>。

[RFC7267] Martini, L., Bocci, M., and F. Balus, "Dynamic Placement of Multi-Segment Pseudowires", RFC 7267, June 2014, <http://www.rfc-editor.org/info/rfc7267>.

[RFC7267] Martini、L.、Bocci、M。、およびF. Balus、「Dynamic Placement of Multi-Segment Pseudowires」、RFC 7267、2014年6月、<http://www.rfc-editor.org/info/rfc7267 >。

Acknowledgements

謝辞

The authors gratefully acknowledge the contribution of the RFC 3212 [RFC3212] authors for the specification of the ER TLV and the ER-Hop TLV, which are reused by this document. The authors also gratefully acknowledge the input of Lizhong Jin.

著者は、この文書で再利用されるER TLVとER-Hop TLVの仕様に対するRFC 3212 [RFC3212]の著者の貢献に感謝します。著者はまた、Lizhong Jinの意見を感謝します。

Authors' Addresses

著者のアドレス

Pranjal Kumar Dutta Alcatel-Lucent 701 E. Middlefield Road Mountain View, California 94043 United States

Pranjal Kumar Duttaアルカテルルーセント701 E. Middlefield Roadマウンテンビュー、カリフォルニア94043アメリカ合衆国

   EMail: pranjal.dutta@alcatel-lucent.com

Matthew Bocci Alcatel-Lucent Voyager Place, Shoppenhangers Road Maidenhead, Berks SL6 2PJ United Kingdom

Matthew Bocci Alcatel-Lucent Voyager Place、Shoppenhangers Road Maidenhead、Berks SL6 2PJイギリス

   EMail: matthew.bocci@alcatel-lucent.com

Luca Martini Cisco Systems 9155 East Nichols Avenue, Suite 400 Englewood, Colorado 80112 United States

Luca Martini Cisco Systems 9155 East Nichols Avenue、Suite 400 Englewood、Colorado 80112 United States

   EMail: lmartini@cisco.com