[要約] RFC 7140は、ハブアンドスポークのマルチポイントラベルスイッチパス（MPLS）に対するLDP拡張に関するものです。このRFCの目的は、ハブアンドスポークトポロジでのMPLSネットワークの効率的な設定と管理を可能にすることです。
Internet Engineering Task Force (IETF) L. Jin
Request for Comments: 7140
Category: Standards Track F. Jounay
ISSN: 2070-1721 Orange CH
IJ. Wijnands
Cisco Systems, Inc
N. Leymann
Deutsche Telekom AG
March 2014
LDP Extensions for Hub and Spoke Multipoint Label Switched Path
ハブアンドスポークマルチポイントラベルスイッチドパスのLDP拡張
Abstract
概要
This document introduces a hub and spoke multipoint (HSMP) Label Switched Path (LSP), which allows traffic from root to leaf through point-to-multipoint (P2MP) LSPs and also leaf to root along the reverse path. That means traffic entering the HSMP LSP from the application/customer at the root node travels downstream to each leaf node, exactly as if it were traveling downstream along a P2MP LSP to each leaf node. Upstream traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root, as if it were unicast to the root. Direct communication among the leaf nodes is not allowed.
このドキュメントでは、ハブアンドスポークマルチポイント（HSMP）ラベルスイッチドパス（LSP）を紹介します。これにより、ルートからリーフへのトラフィックがポイントツーマルチポイント（P2MP）LSPを経由し、リバースパスに沿ってリーフからルートへもトラフィックを転送できます。つまり、ルートノードのアプリケーション/カスタマーからHSMP LSPに入るトラフィックは、まるでP2MP LSPに沿って各リーフノードにダウンストリームであるかのように、各リーフノードにダウンストリームで転送されます。リーフノードでHSMP LSPに入るアップストリームトラフィックは、ルートにユニキャストされているかのように、ツリーに沿ってルートに向かって上流に移動します。リーフノード間の直接通信は許可されていません。
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/rfc7140.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7140で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Setting Up HSMP LSP with LDP . . . . . . . . . . . . . . . . 4
3.1. Support for HSMP LSP Setup with LDP . . . . . . . . . . . 4
3.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 5
3.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 5
3.4. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . . 6
3.4.1. HSMP LSP Leaf Node Operation . . . . . . . . . . . . 7
3.4.2. HSMP LSP Transit Node Operation . . . . . . . . . . . 7
3.4.3. HSMP LSP Root Node Operation . . . . . . . . . . . . 8
3.5. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . . . 9
3.5.1. HSMP Leaf Operation . . . . . . . . . . . . . . . . . 9
3.5.2. HSMP Transit Node Operation . . . . . . . . . . . . . 9
3.5.3. HSMP Root Node Operation . . . . . . . . . . . . . . 10
3.6. HSMP LSP Upstream LSR Change . . . . . . . . . . . . . . 10
3.7. Determining Forwarding Interface . . . . . . . . . . . . 10
4. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 11
5. Redundancy Considerations . . . . . . . . . . . . . . . . . . 11
6. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. New LDP FEC Element Types . . . . . . . . . . . . . . . . 12
8.2. HSMP LSP Capability TLV . . . . . . . . . . . . . . . . . 13
8.3. New Sub-TLVs for the Target Stack TLV . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 14
The point-to-multipoint (P2MP) Label Switched Path (LSP) defined in [RFC6388] allows traffic to transmit from root to several leaf nodes, and multipoint-to-multipoint (MP2MP) LSP allows traffic from every node to transmit to every other node. This document introduces a hub and spoke multipoint (HSMP) LSP, which has one root node and one or more leaf nodes. An HSMP LSP allows traffic from root to leaf through downstream LSP and also leaf to root along the upstream LSP. That means traffic entering the HSMP LSP at the root node travels along the downstream LSP, exactly as if it were traveling along a P2MP LSP, and traffic entering the HSMP LSP at any other leaf nodes travels along the upstream LSP toward only the root node. The upstream LSP should be thought of as a unicast LSP to the root node, except that it follows the reverse direction of the downstream LSP, rather than the unicast path based on the routing protocol. The combination of upstream LSPs initiated from all leaf nodes forms a multipoint-to-point LSP.
[RFC6388]で定義されているポイントツーマルチポイント（P2MP）ラベルスイッチドパス（LSP）は、ルートからいくつかのリーフノードへのトラフィックの送信を許可し、マルチポイントツーマルチポイント（MP2MP）LSPは、すべてのノードからのトラフィックの送信を許可します他のノード。このドキュメントでは、1つのルートノードと1つ以上のリーフノードを持つハブアンドスポークマルチポイント（HSMP）LSPを紹介します。 HSMP LSPは、ダウンストリームLSPを介してルートからリーフへのトラフィックを許可し、上流LSPに沿ってリーフからルートへのトラフィックも許可します。つまり、ルートノードでHSMP LSPに入るトラフィックは、P2MP LSPに沿って流れるかのように、ダウンストリームLSPに沿って移動し、他のリーフノードでHSMP LSPに入るトラフィックは、ルートノードのみに向かって上流LSPに沿って移動します。アップストリームLSPは、ルーティングプロトコルに基づくユニキャストパスではなく、ダウンストリームLSPの逆方向に従うことを除いて、ルートノードへのユニキャストLSPと考える必要があります。すべてのリーフノードから開始されたアップストリームLSPの組み合わせにより、マルチポイントツーポイントLSPが形成されます。
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 following terms and acronyms:
このドキュメントでは、次の用語と略語を使用しています。
mLDP: Multipoint extensions for Label Distribution Protocol (LDP) defined in [RFC6388].
mLDP：[RFC6388]で定義されているラベル配布プロトコル（LDP）のマルチポイント拡張。
P2MP LSP: point-to-multipoint Label Switched Path. An LSP that has one Ingress Label Switching Router (LSR) and one or more Egress LSRs.
P2MP LSP：ポイントツーマルチポイントラベルスイッチドパス。 1つの入力ラベルスイッチングルーター（LSR）と1つ以上の出力LSRを持つLSP。
MP2MP LSP: multipoint-to-multipoint Label Switched Path. An LSP that connects a set of nodes, such that traffic sent by any node in the LSP is delivered to all others.
MP2MP LSP：マルチポイントツーマルチポイントラベルスイッチドパス。 LSP内の任意のノードによって送信されたトラフィックが他のすべてのノードに配信されるように、ノードのセットを接続するLSP。
HSMP LSP: hub and spoke multipoint Label Switched Path. An LSP that has one root node and one or more leaf nodes, allows traffic from the root to all leaf nodes along the downstream P2MP LSP and also leaf to root node along the upstream unicast LSP.
HSMP LSP：ハブアンドスポークマルチポイントラベルスイッチドパス。 1つのルートノードと1つ以上のリーフノードを持つLSPは、ルートからダウンストリームP2MP LSPに沿ったすべてのリーフノードへのトラフィック、およびアップストリームユニキャストLSPに沿ったリーフからルートノードへのトラフィックを許可します。
FEC: Forwarding Equivalence Class
FEC：転送同等クラス
An HSMP LSP is similar to MP2MP LSP described in [RFC6388], with the difference being that, when the leaf LSRs send traffic on the LSP, the traffic is first delivered only to the root node and follows the upstream path from the leaf node to the root node. The root node then distributes the traffic on the P2MP tree to all of the leaf nodes.
HSMP LSPは[RFC6388]で説明されているMP2MP LSPに似ていますが、リーフLSRがLSPでトラフィックを送信すると、トラフィックは最初にルートノードにのみ配信され、リーフノードからルートノード。次に、ルートノードはP2MPツリー上のトラフィックをすべてのリーフノードに分散します。
An HSMP LSP consists of a downstream path and upstream path. The downstream path is the same as P2MP LSP, while the upstream path is only from leaf to root node, without communication between the leaf nodes themselves. The transmission of packets from the root node of an HSMP LSP to the receivers (the leaf nodes) is identical to that of a P2MP LSP. Traffic from a leaf node to the root follows the upstream path that is the reverse of the path from the root to the leaf. Unlike an MP2MP LSP, traffic from a leaf node does not branch toward other leaf nodes, but it is sent direct to the root where it is placed on the P2MP path and distributed to all leaf nodes including the original sender.
HSMP LSPは、ダウンストリームパスとアップストリームパスで構成されます。ダウンストリームパスはP2MP LSPと同じですが、アップストリームパスはリーフノードからルートノードへのみであり、リーフノード間の通信はありません。 HSMP LSPのルートノードからレシーバ（リーフノード）へのパケットの送信は、P2MP LSPの送信と同じです。リーフノードからルートへのトラフィックは、ルートからリーフへのパスの逆であるアップストリームパスに従います。 MP2MP LSPとは異なり、リーフノードからのトラフィックは他のリーフノードに向かって分岐しませんが、ルートに直接送信されてP2MPパスに配置され、元の送信者を含むすべてのリーフノードに配信されます。
To set up the upstream path of an HSMP LSP, ordered mode MUST be used. Ordered mode can guarantee that a leaf will start sending packets to the root immediately after the upstream path is installed, without being dropped due to an incomplete LSP.
HSMP LSPのアップストリームパスを設定するには、orderedモードを使用する必要があります。 Orderedモードでは、上流パスがインストールされた直後に、リーフが不完全なLSPによってドロップされることなく、リーフがルートへのパケットの送信を開始することを保証できます。
An HSMP LSP requires the LDP capabilities [RFC5561] for nodes to indicate that they support setup of HSMP LSPs. An implementation supporting the HSMP LSP procedures specified in this document MUST implement the procedures for Capability Parameters in Initialization messages. Advertisement of the HSMP LSP Capability indicates support of the procedures for HSMP LSP setup.
HSMP LSPは、ノードがHSMP LSPのセットアップをサポートしていることを示すために、ノードのLDP機能[RFC5561]を必要とします。このドキュメントで指定されているHSMP LSP手順をサポートする実装は、初期化メッセージの機能パラメーターの手順を実装する必要があります。 HSMP LSP機能のアドバタイズは、HSMP LSPセットアップの手順のサポートを示します。
A new Capability Parameter TLV is defined, the HSMP LSP Capability Parameter. Below is the format of the HSMP LSP Capability Parameter.
新しい機能パラメータTLVであるHSMP LSP機能パラメータが定義されています。以下は、HSMP LSP機能パラメーターのフォーマットです。
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| HSMP LSP Cap (0x0902) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
Figure 1: HSMP LSP Capability Parameter Encoding
図1：HSMP LSP機能パラメーターのエンコード
U-bit: Unknown TLV bit, as described in [RFC5036]. The value MUST be 1. The unknown TLV MUST be silently ignored and the rest of the message processed as if the unknown TLV did not exist.
Uビット：[RFC5036]で説明されているように、未知のTLVビット。値は1である必要があります。不明なTLVは通知なしで無視され、残りのメッセージは不明なTLVが存在しないかのように処理されます。
F-bit: Forward unknown TLV bit, as described in [RFC5036]. The value of this bit MUST be 0 since a Capability Parameter TLV is sent only in Initialization and Capability messages, which are not forwarded.
Fビット：[RFC5036]で説明されているように、未知のTLVビットを転送します。機能パラメータTLVは初期化および機能メッセージでのみ送信され、転送されないため、このビットの値は0でなければなりません。
Length: SHOULD be 1.
長さ：1にする必要があります。
S-bit: As defined in Section 3 of [RFC5561].
Sビット：[RFC5561]のセクション3で定義されています。
Reserved: As defined in Section 3 of [RFC5561].
予約済み：[RFC5561]のセクション3で定義されています。
HSMP LSP Capability Parameter type: 0x0902.
HSMP LSP機能パラメータータイプ：0x0902。
If the peer has not advertised the corresponding capability, then label messages using the HSMP Forwarding Equivalence Class (FEC) Element SHOULD NOT be sent to the peer (as described in Section 2.1 of [RFC6388]). Since ordered mode is applied for HSMP LSP signaling, the label message break would ensure that the initiating leaf node is unable to establish the upstream path to root node.
ピアが対応する機能をアドバタイズしていない場合、HSMP Forwarding Equivalence Class（FEC）要素を使用したラベルメッセージはピアに送信すべきではありません（[RFC6388]のセクション2.1で説明されています）。順序モードがHSMP LSPシグナリングに適用されるため、ラベルメッセージブレークにより、開始リーフノードがルートノードへのアップストリームパスを確立できないことが保証されます。
We define two new protocol entities: the HSMP Downstream FEC Element and Upstream FEC Element. If a FEC TLV contains one of the HSMP FEC Elements, the HSMP FEC Element MUST be the only FEC Element in the FEC TLV. The structure, encoding, and error handling for the HSMP-downstream FEC Element and HSMP-upstream FEC Element are the same as for the P2MP FEC Element described in Section 2.2 of [RFC6388]. The difference is that two additional new FEC types are defined: HSMP-downstream FEC (10) and HSMP-upstream FEC (9).
HSMPダウンストリームFECエレメントとアップストリームFECエレメントという2つの新しいプロトコルエンティティを定義します。 FEC TLVにHSMP FECエレメントの1つが含まれている場合、HSMP FECエレメントはFEC TLV内の唯一のFECエレメントである必要があります。 HSMPダウンストリームFEC要素とHSMPアップストリームFEC要素の構造、エンコーディング、エラー処理は、[RFC6388]のセクション2.2で説明されているP2MP FEC要素と同じです。違いは、HSMPダウンストリームFEC（10）とHSMPアップストリームFEC（9）という2つの追加の新しいFECタイプが定義されていることです。
The entries in the list below describe the processing of the HSMP FEC Elements. Additionally, the entries defined in Section 3.3 of [RFC6388] are also reused in the following sections.
以下のリストのエントリは、HSMP FEC要素の処理について説明しています。さらに、[RFC6388]のセクション3.3で定義されたエントリは、次のセクションでも再利用されます。
1. HSMP downstream LSP <X, Y> (or simply downstream <X, Y>): an HSMP LSP downstream path with root node address X and opaque value Y.
1. HSMPダウンストリームLSP <X、Y>（または単にダウンストリーム<X、Y>）：ルートノードアドレスXと不透明な値Yを持つHSMP LSPダウンストリームパス。
2. HSMP upstream LSP <X, Y> (or simply upstream <X, Y>): an HSMP LSP upstream path for root node address X and opaque value Y that will be used by any downstream node to send traffic upstream to root node.
2. HSMPアップストリームLSP <X、Y>（または単にアップストリーム<X、Y>）：ルートノードアドレスXおよび不透明な値YのHSMP LSPアップストリームパス。ダウンストリームノードがルートノードにトラフィックを送信するために使用します。
3. HSMP-downstream FEC Element <X, Y>: a FEC Element with root node address X and opaque value Y used for a downstream HSMP LSP.
3. HSMPダウンストリームFECエレメント<X、Y>：ダウンストリームHSMP LSPに使用されるルートノードアドレスXおよび不透明な値Yを持つFECエレメント。
4. HSMP-upstream FEC Element <X, Y>: a FEC Element with root node address X and opaque value Y used for an upstream HSMP LSP.
4. HSMPアップストリームFEC要素<X、Y>：アップストリームHSMP LSPに使用されるルートノードアドレスXと不透明な値Yを持つFEC要素。
5. HSMP-D Label Mapping <X, Y, L>: A Label Mapping message with a single HSMP-downstream FEC Element <X, Y> and label TLV with label L. Label L MUST be allocated from the per-platform label space of the LSR sending the Label Mapping Message.
5. HSMP-Dラベルマッピング<X、Y、L>：単一のHSMPダウンストリームFEC要素<X、Y>とラベルLのラベルTLVを含むラベルマッピングメッセージ。ラベルLは、プラットフォームごとのラベルスペースから割り当てる必要があります。ラベルマッピングメッセージを送信するLSR。
6. HSMP-U Label Mapping <X, Y, Lu>: A Label Mapping message with a single HSMP upstream FEC Element <X, Y> and label TLV with label Lu. Label Lu MUST be allocated from the per-platform label space of the LSR sending the Label Mapping Message.
6. HSMP-Uラベルマッピング<X、Y、Lu>：単一のHSMPアップストリームFEC要素<X、Y>とラベルLuのラベルTLVを含むラベルマッピングメッセージ。ラベルLuは、ラベルマッピングメッセージを送信するLSRのプラットフォームごとのラベルスペースから割り当てる必要があります。
7. HSMP-D Label Withdraw <X, Y, L>: a Label Withdraw message with a FEC TLV with a single HSMP-downstream FEC Element <X, Y> and label TLV with label L.
7. HSMP-Dラベルウィズドロウ<X、Y、L>：単一のHSMPダウンストリームFEC要素<X、Y>を持つFEC TLVとラベルLを持つラベルTLVを持つラベルウィズドローメッセージ。
8. HSMP-U Label Withdraw <X, Y, Lu>: a Label Withdraw message with a FEC TLV with a single HSMP-upstream FEC Element <X, Y> and label TLV with label Lu.
8. HSMP-Uラベルウィズドロウ<X、Y、Lu>：単一のHSMPアップストリームFEC要素<X、Y>を持つFEC TLVとラベルLu付きのラベルTLVを持つラベルウィズドローメッセージ。
9. HSMP-D Label Release <X, Y, L>: a Label Release message with a FEC TLV with a single HSMP-downstream FEC Element <X, Y> and Label TLV with label L.
9. HSMP-Dラベルリリース<X、Y、L>：単一のHSMPダウンストリームFEC要素<X、Y>を持つFEC TLVとラベルLを持つラベルTLVを含むラベルリリースメッセージ。
10. HSMP-U Label Release <X, Y, Lu>: a Label Release message with a FEC TLV with a single HSMP-upstream FEC Element <X, Y> and label TLV with label Lu.
10. HSMP-Uラベルリリース<X、Y、Lu>：単一のHSMPアップストリームFEC要素<X、Y>を持つFEC TLVとラベルLuを持つラベルTLVを含むラベルリリースメッセージ。
This section specifies the procedures for originating HSMP Label Mapping messages and processing received HSMP Label Mapping messages for a particular HSMP LSP. The procedure of a downstream HSMP LSP is similar to that of a downstream MP2MP LSP described in [RFC6388]. When LDP operates in Ordered Label Distribution Control mode [RFC5036], the upstream LSP will be set up by sending an HSMP LSP LDP Label Mapping message with a label that is allocated by the upstream LSR to its downstream LSR hop-by-hop from root to leaf node, installing the upstream forwarding table by every node along the LSP.
このセクションでは、HSMPラベルマッピングメッセージを発信し、特定のHSMP LSPの受信したHSMPラベルマッピングメッセージを処理する手順を示します。ダウンストリームHSMP LSPの手順は、[RFC6388]で説明されているダウンストリームMP2MP LSPの手順と同様です。 LDPが順序付きラベル配布制御モード[RFC5036]で動作している場合、上流のLSPは、上流のLSRによってルートから下流のLSRホップバイホップに割り当てられたラベル付きのHSMP LSP LDPラベルマッピングメッセージを送信することによってセットアップされます。リーフノードに、LSPに沿ったすべてのノードによってアップストリーム転送テーブルをインストールします。
The detailed procedure of setting up upstream HSMP LSP is different than that of upstream MP2MP LSP, and it is specified in the remainder of this section.
アップストリームHSMP LSPの詳細なセットアップ手順は、アップストリームMP2MP LSPのセットアップ手順とは異なり、このセクションの残りの部分で指定されています。
All labels discussed here are downstream-assigned [RFC5332] except those that are assigned using the procedures described in Section 4.
ここで説明するすべてのラベルは、セクション4で説明されている手順を使用して割り当てられたものを除き、ダウンストリーム割り当て[RFC5332]です。
Determining the upstream LSR for the HSMP LSP <X, Y> follows the procedure for a P2MP LSP described in Section 2.4.1.1 of [RFC6388]. That is, a node Z that wants to join an HSMP LSP <X, Y> determines the LDP peer U that is Z's next hop on the best path from Z to the root node X. If there are multiple upstream LSRs, a local algorithm should be applied to ensure that there is exactly one upstream LSR for a particular LSP.
HSMP LSP <X、Y>のアップストリームLSRの決定は、[RFC6388]のセクション2.4.1.1で説明されているP2MP LSPの手順に従います。つまり、HSMP LSP <X、Y>に参加するノードZは、ZからルートノードXへの最適パス上のZのネクストホップであるLDPピアUを決定します。複数のアップストリームLSRがある場合、ローカルアルゴリズム特定のLSPに対して1つのアップストリームLSRが存在することを確認するために適用する必要があります。
To determine one's HSMP downstream LSR, an upstream LDP peer that receives a Label Mapping with the HSMP-downstream FEC Element from an LDP peer D will treat D as HSMP downstream LDP peer.
自分のHSMPダウンストリームLSRを決定するために、LDPピアDからHSMPダウンストリームFEC要素を持つラベルマッピングを受信するアップストリームLDPピアは、DをHSMPダウンストリームLDPピアとして扱います。
The leaf node operation is much the same as the operation of MP2MP LSP defined in Section 3.3.1.4 of [RFC6388]. The only difference is the FEC elements as specified below.
リーフノードの操作は、[RFC6388]のセクション3.3.1.4で定義されているMP2MP LSPの操作とほとんど同じです。唯一の違いは、以下に示すFEC要素です。
A leaf node Z of an HSMP LSP <X, Y> determines its upstream LSR U for <X, Y> as per Section 3.3, allocates a label L, and sends an HSMP-D Label Mapping <X, Y, L> to U. Leaf node Z expects an HSMP-U Label Mapping <X, Y, Lu> from node U and checks whether it already has forwarding state for upstream <X, Y>. If not, Z creates forwarding state to push label Lu onto the traffic that Z wants to forward over the HSMP LSP. How it determines what traffic to forward on this HSMP LSP is outside the scope of this document.
HSMP LSPのリーフノードZ <X、Y>は、セクション3.3に従って、<X、Y>のアップストリームLSR Uを決定し、ラベルLを割り当て、HSMP-Dラベルマッピング<X、Y、L>を送信します。 U.リーフノードZは、ノードUからのHSMP-Uラベルマッピング<X、Y、Lu>を期待し、上流の<X、Y>の転送状態がすでにあるかどうかを確認します。そうでない場合、Zは、ZがHSMP LSPを介して転送するトラフィックにラベルLuをプッシュする転送状態を作成します。このHSMP LSPで転送するトラフィックを決定する方法は、このドキュメントの範囲外です。
The procedure for processing an HSMP-D Label Mapping message is much the same as that for an MP2MP-D Label Mapping message defined in Section 3.3.1.5 of [RFC6388]. The processing of an HSMP-U Label Mapping message is different from that of an MP2MP-U Label Mapping message as specified below.
HSMP-Dラベルマッピングメッセージを処理する手順は、[RFC6388]のセクション3.3.1.5で定義されているMP2MP-Dラベルマッピングメッセージの手順とほとんど同じです。 HSMP-Uラベルマッピングメッセージの処理は、以下で指定するMP2MP-Uラベルマッピングメッセージの処理とは異なります。
Suppose node Z receives an HSMP-D Label Mapping <X, Y, L> from LSR D. Z checks whether it has forwarding state for downstream <X, Y>. If not, Z determines its upstream LSR U for <X, Y> as per Section 3.3. Using this Label Mapping to update the label forwarding table MUST NOT be done as long as LSR D is equal to LSR U. If LSR U is different from LSR D, Z will allocate a label L' and install downstream forwarding state to swap label L' with label L over interface I associated with LSR D and send an HSMP-D Label Mapping <X, Y, L'> to U. Interface I is determined via the procedures in Section 3.7.
ノードZがLSR DからHSMP-Dラベルマッピング<X、Y、L>を受信したと仮定します。Zは、それがダウンストリーム<X、Y>の転送状態を持っているかどうかを確認します。そうでない場合、Zはセクション3.3に従って、<X、Y>のアップストリームLSR Uを決定します。 LSR DがLSR Uと等しい限り、このラベルマッピングを使用してラベル転送テーブルを更新することはできません。LSRUがLSR Dと異なる場合、ZはラベルL 'を割り当て、ラベルLを交換するためにダウンストリーム転送状態をインストールします'LSR Dに関連付けられたインターフェースIを介してラベルLで、HSMP-Dラベルマッピング<X、Y、L'>をUに送信します。インターフェースIは、セクション3.7の手順で決定されます。
If Z already has forwarding state for downstream <X, Y>, all that Z needs to do in this case is check that LSR D is not equal to the upstream LSR of <X, Y> and update its forwarding state. Assuming its old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, L>}. If the LSR D is equal to the installed upstream LSR, the Label Mapping from LSR D MUST be retained and MUST NOT update the label forwarding table.
Zがすでにダウンストリーム<X、Y>の転送状態を持っている場合、この場合Zが行う必要があるのは、LSR Dが<X、Y>のアップストリームLSRと等しくないことを確認し、その転送状態を更新することです。古い転送状態がL '-> {<I1、L1> <I2、L2> ...、<In、Ln>}であったとすると、新しい転送状態はL'-> {<I1、L1> <I2、 L2> ...、<In、Ln>、<I、L>}。 LSR DがインストールされたアップストリームLSRと等しい場合、LSR Dからのラベルマッピングは保持されなければならず、ラベル転送テーブルを更新してはなりません（MUST NOT）。
Node Z checks if the upstream LSR U already has assigned a label Lu to upstream <X, Y>. If not, transit node Z waits until it receives an HSMP-U Label Mapping <X, Y, Lu> from LSR U. Once the HSMP-U Label Mapping is received from LSR U, node Z checks whether it already has forwarding state upstream <X, Y> with incoming label Lu' and outgoing label Lu. If it does not, it allocates a label Lu' and creates a new label swap for Lu' with Label Lu over interface Iu. Interface Iu is determined via the procedures in Section 3.7. Node Z determines the downstream HSMP LSR as per Section 3.4 and sends an HSMP-U Label Mapping <X, Y, Lu'> to node D.
ノードZは、上流のLSR Uが上流にラベルLuをすでに割り当てているかどうかを確認します<X、Y>。そうでない場合、中継ノードZは、LSR UからHSMP-Uラベルマッピング<X、Y、Lu>を受信するまで待機します。HSMP-UラベルマッピングがLSR Uから受信されると、ノードZは、上流に転送状態があるかどうかを確認します<X、Y>、着信ラベルLu 'および発信ラベルLu。そうでない場合、ラベルLu 'を割り当て、インターフェースIuを介してラベルLuを使用してLu'の新しいラベルスワップを作成します。インターフェースIuは、セクション3.7の手順で決定されます。ノードZは、セクション3.4に従ってダウンストリームHSMP LSRを決定し、HSMP-Uラベルマッピング<X、Y、Lu '>をノードDに送信します。
Since a packet from any downstream node is forwarded only to the upstream node, the same label (representing the upstream path) SHOULD be distributed to all downstream nodes. This differs from the procedures for MP2MP LSPs [RFC6388], where a distinct label must be distributed to each downstream node. The forwarding state upstream <X, Y> on node Z will be like this: {<Lu'>, <Iu Lu>}. Iu means the upstream interface over which Z receives HSMP-U Label Map <X, Y, Lu> from LSR U. Packets from any downstream interface over which Z sends HSMP-U Label Map <X, Y, Lu'> with label Lu' will be forwarded to Iu with label Lu' swapped to Lu.
下流ノードからのパケットは上流ノードにのみ転送されるため、同じラベル（上流パスを表す）をすべての下流ノードに配布する必要があります。これは、MP2MP LSP [RFC6388]の手順とは異なります。この手順では、個別のラベルを各ダウンストリームノードに配布する必要があります。ノードZの上流の転送状態<X、Y>は、次のようになります：{<Lu '>、<Iu Lu>}。 Iuは、ZがLSR UからHSMP-Uラベルマップ<X、Y、Lu>を受信するアップストリームインターフェイスを意味します。ZがHSMP-Uラベルマップ<X、Y、Lu '>にラベルLuを送信するダウンストリームインターフェイスからのパケット'Luに交換されたラベルLuでIuに転送されます。
The procedure for an HSMP-D Label Mapping message is much the same as processing an MP2MP-D Label Mapping message defined in Section 3.3.1.6 of [RFC6388]. The processing of an HSMP-U Label Mapping message is different from that of an MP2MP-U Label Mapping message as specified below.
HSMP-Dラベルマッピングメッセージの手順は、[RFC6388]のセクション3.3.1.6で定義されているMP2MP-Dラベルマッピングメッセージの処理とほとんど同じです。 HSMP-Uラベルマッピングメッセージの処理は、以下で指定するMP2MP-Uラベルマッピングメッセージの処理とは異なります。
Suppose the root node Z receives an HSMP-D Label Mapping <X, Y, L> from node D. Z checks whether it already has forwarding state for downstream <X, Y>. If not, Z creates downstream forwarding state and installs an outgoing label L over interface I. Interface I is determined via the procedures in Section 3.7. If Z already has forwarding state for downstream <X, Y>, then Z will add label L over interface I to the existing state.
ルートノードZがノードDからHSMP-Dラベルマッピング<X、Y、L>を受信するとします。Zは、ダウンストリーム<X、Y>の転送状態がすでにあるかどうかを確認します。そうでない場合、Zはダウンストリーム転送状態を作成し、発信ラベルLをインターフェイスIにインストールします。インターフェイスIは、セクション3.7の手順で決定されます。 Zがすでにダウンストリーム<X、Y>の転送状態を持っている場合、Zは既存の状態にインターフェイスIを介してラベルLを追加します。
Node Z checks if it has forwarding state for upstream <X, Y>. If not, Z creates a forwarding state for incoming label Lu' that indicates that Z is the HSMP LSP egress Label Edge Router (LER). For example, the forwarding state might specify that the label stack is popped and the packet passed to some specific application. Node Z determines the downstream HSMP LSR as per Section 3.3 and sends an HSMP-U Label Map <X, Y, Lu'> to node D.
ノードZは、上流の<X、Y>に転送状態があるかどうかを確認します。そうでない場合、Zは着信ラベルLu 'の転送状態を作成します。これは、ZがHSMP LSP出力ラベルエッジルーター（LER）であることを示します。たとえば、フォワーディングステートは、ラベルスタックがポップされ、パケットが特定のアプリケーションに渡されることを指定する場合があります。ノードZは、セクション3.3に従ってダウンストリームHSMP LSRを決定し、HSMP-Uラベルマップ<X、Y、Lu '>をノードDに送信します。
Since Z is the root of the tree, Z will not send an HSMP-D Label Map and will not receive an HSMP-U Label Mapping.
Zはツリーのルートであるため、ZはHSMP-Dラベルマップを送信せず、HSMP-Uラベルマッピングを受信しません。
The root node could also be a leaf node, and it is able to determine what traffic to forward on this HSMP LSP; that determination is outside the scope of this document.
ルートノードはリーフノードにすることもでき、このHSMP LSPで転送するトラフィックを決定できます。その決定は、このドキュメントの範囲外です。
If a leaf node Z discovers that it has no need to be an Egress LSR for that LSP (by means outside the scope of this document), then it SHOULD send an HSMP-D Label Withdraw <X, Y, L> to its upstream LSR U for <X, Y>, where L is the label it had previously advertised to U for <X, Y>. Leaf node Z will also send an unsolicited HSMP-U Label Release <X, Y, Lu> to U to indicate that the upstream path is no longer used and that label Lu can be removed.
リーフノードZは、そのLSPの出力LSRである必要がないことを（このドキュメントの範囲外であることを意味して）検出した場合、HSMP-Dラベルウィズドロウ<X、Y、L>をそのアップストリームに送信する必要があります（SHOULD）。 Lは、<X、Y>のUに以前にアドバタイズしたラベルです。リーフノードZは、要求されていないHSMP-Uラベルリリース<X、Y、Lu>をUに送信して、アップストリームパスが使用されなくなったことと、ラベルLuを削除できることを示します。
Leaf node Z expects the upstream router U to respond by sending a downstream Label Release for L.
リーフノードZは、Lのダウンストリームラベルリリースを送信することにより、アップストリームルータUが応答することを期待しています。
If a transit node Z receives an HSMP-D Label Withdraw message <X, Y, L> from node D, it deletes label L from its forwarding state downstream <X, Y>. Node Z sends an HSMP-D Label Release message with label L to D. There is no need to send an HSMP-U Label Withdraw <X, Y, Lu> to D because node D already removed Lu and sent a label release for Lu to Z.
中継ノードZがノードDからHSMP-D Label Withdrawメッセージ<X、Y、L>を受信した場合、中継ノードZはその転送状態ダウンストリーム<X、Y>からラベルLを削除します。ノードZは、ラベルLのHSMP-DラベルリリースメッセージをDに送信します。ノードDはすでにLuを削除し、Luのラベルリリースを送信しているため、HSMP-U Label Withdraw <X、Y、Lu>をDに送信する必要はありません。 Zに
If deleting L from Z's forwarding state for downstream <X, Y> results in no state remaining for <X, Y>, then Z propagates the HSMP-D Label Withdraw <X, Y, L> to its upstream node U for <X, Y>. Z should also check if there are any incoming interfaces in forwarding state upstream <X, Y>. If all downstream nodes are released and there is no incoming interface, Z should delete the forwarding state upstream <X, Y> and send an HSMP-U Label Release message to its upstream node. Otherwise, no HSMP-U Label Release message will be sent to the upstream node.
ダウンストリーム<X、Y>のZの転送状態からLを削除すると、<X、Y>の状態が残っていない場合、ZはHSMP-D Label Withdraw <X、Y、L>を<Xの上流ノードUに伝播します。 、Y>。 Zは、フォワーディングステートアップストリーム<X、Y>の着信インターフェイスがあるかどうかも確認する必要があります。すべてのダウンストリームノードが解放され、着信インターフェイスがない場合、Zはフォワーディングステートアップストリーム<X、Y>を削除し、HSMP-Uラベルリリースメッセージをそのアップストリームノードに送信する必要があります。そうでない場合、HSMP-Uラベル解放メッセージは上流ノードに送信されません。
When the root node of an HSMP LSP receives an HSMP-D Label Withdraw message and an HSMP-U Label Release message, the procedure is the same as that for transit nodes, except that the root node will not propagate the Label Withdraw and Label Release upstream (as it has no upstream).
HSMP LSPのルートノードがHSMP-DラベルウィズドローメッセージとHSMP-Uラベルリリースメッセージを受信した場合、手順はトランジットノードの場合と同じですが、ルートノードがラベルウィズドローとラベルリリースを伝播しない点が異なります。アップストリーム（アップストリームがないため）。
The procedure for changing the upstream LSR is the same as defined in Section 2.4.3 of [RFC6388], only with different processing of the FEC Element.
アップストリームLSRを変更する手順は、[RFC6388]のセクション2.4.3で定義されているものと同じですが、FEC要素の処理が異なります。
When the upstream LSR changes from U to U', node Z should set up the HSMP LSP <X, Y> to U' by applying the procedures in Section 3.4. Z will also remove the HSMP LSP <X, Y> to U by applying the procedure in Section 3.5.
アップストリームLSRがUからU 'に変更されると、ノードZはセクション3.4の手順を適用して、HSMP LSP <X、Y>をU'に設定する必要があります。 Zはまた、セクション3.5の手順を適用して、HSMP LSP <X、Y>からUを削除します。
To set up an HSMP LSP to U' before/after removing the HSMP LSP to U is a local matter. The recommended default behavior is to remove before adding.
UへのHSMP LSPを削除する前/後にHSMP LSPをU 'に設定することは、ローカルな問題です。推奨されるデフォルトの動作は、追加する前に削除することです。
The upstream and downstream LSPs can be co-routed by applying the procedures below. Both LSR U and LSR D would ensure that the same interface sends traffic by applying some procedures. For a network with symmetric IGP cost configuration, the following procedure MAY be used. To determine the downstream interface, LSR U MUST do a lookup in the unicast routing table to find the best interface and next hop to reach LSR D. If the next hop and interface are also advertised by LSR D via the LDP session, it should be used to transmit the packet to LSR D. The mechanism to determine the upstream interface is the same as that used to determine the downstream interface except the roles of LSR U and LSR D are switched. If symmetric IGP cost could not be ensured, static route configuration on LSR U and D could also be a way to ensure a co-routed path.
以下の手順を適用することにより、アップストリームとダウンストリームのLSPを同じ経路でルーティングできます。 LSR UとLSR Dはどちらも、いくつかの手順を適用することにより、同じインターフェイスがトラフィックを送信することを保証します。対称IGPコスト構成のネットワークでは、次の手順を使用できます。ダウンストリームインターフェイスを決定するには、LSR Uは、ユニキャストルーティングテーブルを検索して、LSR Dに到達するための最適なインターフェイスとネクストホップを見つける必要があります。ネクストホップとインターフェイスもLDPセッションを介してLSR Dによってアドバタイズされる場合、パケットをLSR Dに送信するために使用されます。アップストリームインターフェイスを決定するメカニズムは、ダウンストリームインターフェイスを決定するために使用されるメカニズムと同じですが、LSR UとLSR Dの役割が切り替えられます。対称的なIGPコストを確保できない場合は、LSR UおよびDでの静的ルート構成も、同じルートのパスを確保するための1つの方法となります。
If a co-routed path is not required for the HSMP LSP, the procedure defined in Section 2.4.1.2 of [RFC6388] could be applied. LSR U is free to transmit the packet on any of the interfaces to LSR D. The algorithm it uses to choose a particular interface is a local matter.
HSMP LSPにコルーテッドパスが必要ない場合は、[RFC6388]のセクション2.4.1.2で定義されている手順を適用できます。 LSR Uは、LSR Dへの任意のインターフェイスでパケットを自由に送信できます。特定のインターフェイスを選択するために使用するアルゴリズムは、ローカルな問題です。
The mechanism to determine the upstream interface is the same as that used to determine the downstream interface.
アップストリームインターフェイスを決定するメカニズムは、ダウンストリームインターフェイスを決定するために使用されるメカニズムと同じです。
The procedure to process the downstream HSMP LSP on a LAN is much the same as for a downstream MP2MP LSP as described in Section 6.1.1 of [RFC6388].
[RFC6388]のセクション6.1.1で説明されているように、LAN上のダウンストリームHSMP LSPを処理する手順は、ダウンストリームMP2MP LSPの場合とほとんど同じです。
When establishing the downstream path of an HSMP LSP, as defined in [RFC6389], a Label Request message for an LSP label is sent to the upstream LSR. The upstream LSR should send a Label Mapping message that contains the LSP label for the downstream HSMP FEC and the upstream LSR context label defined in [RFC5331]. When the LSR forwards a packet downstream on one of those LSPs, the packet's top label must be the "upstream LSR context label" and the packet's second label is the "LSP label". The HSMP downstream path will be installed in the context-specific forwarding table corresponding to the upstream LSR label. Packets sent by the upstream LSR can be forwarded downstream using this forwarding state based on a two-label lookup.
[RFC6389]で定義されているように、HSMP LSPのダウンストリームパスを確立すると、LSPラベルのラベル要求メッセージがアップストリームLSRに送信されます。アップストリームLSRは、ダウンストリームHSMP FECのLSPラベルと[RFC5331]で定義されたアップストリームLSRコンテキストラベルを含むラベルマッピングメッセージを送信する必要があります。 LSRがこれらのLSPの1つでダウンストリームにパケットを転送する場合、パケットのトップラベルは「アップストリームLSRコンテキストラベル」である必要があり、パケットの2番目のラベルは「LSPラベル」です。 HSMPダウンストリームパスは、アップストリームLSRラベルに対応するコンテキスト固有の転送テーブルにインストールされます。アップストリームLSRによって送信されたパケットは、2ラベルルックアップに基づくこの転送状態を使用してダウンストリームに転送できます。
The upstream path of an HSMP LSP on a LAN is the same as the one on other kinds of links. That is, the upstream LSR must send a Label Mapping message that contains the LSP label for the upstream HSMP FEC to the downstream node. Packets traveling upstream need to be forwarded in the direction of the root by using the label allocated for the upstream HSMP FEC.
LAN上のHSMP LSPのアップストリームパスは、他の種類のリンク上のものと同じです。つまり、アップストリームLSRは、アップストリームHSMP FECのLSPラベルを含むラベルマッピングメッセージをダウンストリームノードに送信する必要があります。アップストリームに移動するパケットは、アップストリームHSMP FECに割り当てられたラベルを使用して、ルートの方向に転送する必要があります。
In some scenarios, it is necessary to provide two root nodes for redundancy purposes. One way to implement this is to use two independent HSMP LSPs acting as active and standby. At a given time, only one HSMP LSP will be active; the other will be standby. After detecting the failure of the active HSMP LSP, the root and leaf nodes will switch the traffic to the standby HSMP LSP, which takes on the role as active HSMP LSP. The details of the redundancy mechanism are out of the scope of this document.
一部のシナリオでは、冗長性のために2つのルートノードを提供する必要があります。これを実装する1つの方法は、アクティブおよびスタンバイとして機能する2つの独立したHSMP LSPを使用することです。一度に1つのHSMP LSPのみがアクティブになります。もう一方はスタンバイになります。アクティブHSMP LSPの障害を検出した後、ルートノードとリーフノードはトラフィックをスタンバイHSMP LSPに切り替え、アクティブHSMP LSPとしての役割を果たします。冗長メカニズムの詳細は、このドキュメントの範囲外です。
The idea of LSP ping for HSMP LSPs could be expressed as an intention to test the LSP Ping Echo Request packets that enter at the root along a particular downstream path of HSMP LSP and that end their MPLS path on the leaf. The leaf node then sends the LSP Ping Echo Reply along the upstream path of HSMP LSP, and it ends on the root that is the (intended) root node.
HSMP LSPのLSP pingのアイデアは、HSMP LSPの特定のダウンストリームパスに沿ってルートに入力され、リーフ上のMPLSパスを終了するLSP Pingエコー要求パケットをテストする意図として表現できます。次に、リーフノードは、HSMP LSPのアップストリームパスに沿ってLSP Ping Echo Replyを送信し、（意図した）ルートノードであるルートで終了します。
New sub-TLVs have been assigned by IANA in Target FEC Stack TLV and Reverse-path Target FEC Stack TLV to define the corresponding HSMP-downstream FEC type and HSMP-upstream FEC type. In order to ensure that the leaf node sends the LSP Ping Echo Reply along the HSMP upstream path, the R flag (Validate Reverse Path) in the Global Flags field defined in [RFC6426] is reused here.
対応するHSMPダウンストリームFECタイプおよびHSMPアップストリームFECタイプを定義するために、IANAによってターゲットFECスタックTLVおよびリバースパスターゲットFECスタックTLVに新しいサブTLVが割り当てられました。リーフノードがHSMPアップストリームパスに沿ってLSP Ping Echo Replyを送信することを保証するために、[RFC6426]で定義されているグローバルフラグフィールドのRフラグ（Validate Reverse Path）がここで再利用されます。
The node-processing mechanism of LSP Ping Echo Request and Echo Reply for the HSMP LSP is inherited from [RFC6425] and Section 3.4 of [RFC6426], except for the following:
HSMP LSPのLSP Ping Echo RequestおよびEcho Replyのノード処理メカニズムは、[RFC6425]と[RFC6426]のセクション3.4から継承されますが、次の点が異なります。
1. The root node sending the LSP Ping Echo Request message for the HSMP LSP MUST attach the Target FEC Stack TLV with the HSMP-downstream FEC type, and set the R flag to '1' in the Global Flags field.
1. HSMP LSPのLSP Ping Echo Requestメッセージを送信するルートノードは、ターゲットFECスタックTLVをHSMPダウンストリームFECタイプにアタッチし、グローバルフラグフィールドでRフラグを「1」に設定する必要があります。
2. When the leaf node receives the LSP Ping Echo Request, it MUST send the LSP Ping Echo Reply to the associated HSMP upstream path. The Reverse-path Target FEC Stack TLV attached by the leaf node in the Echo Reply message SHOULD contain the sub-TLV of the associated HSMP-upstream FEC.
2. リーフノードがLSP Pingエコー要求を受信すると、関連するHSMPアップストリームパスにLSP Pingエコー応答を送信する必要があります。エコー応答メッセージのリーフノードによって接続された逆パスターゲットFECスタックTLVには、関連付けられたHSMPアップストリームFECのサブTLVが含まれている必要があります。
The same security considerations apply as for the MP2MP LSP described in [RFC6388] and [RFC6425].
[RFC6388]と[RFC6425]で説明されているMP2MP LSPと同じセキュリティ上の考慮事項が適用されます。
Although this document introduces new FEC Elements and corresponding procedures, the protocol does not bring any new security issues beyond those in [RFC6388] and [RFC6425].
このドキュメントでは新しいFEC要素と対応する手順を紹介していますが、プロトコルは[RFC6388]と[RFC6425]の問題を超える新しいセキュリティ問題をもたらしません。
Two new LDP FEC Element types have been allocated from the "Label Distribution Protocol (LDP) Parameters" registry, under "Forwarding Equivalence Class (FEC) Type Name Space":
2つの新しいLDP FEC要素タイプが、「Label Distribution Protocol（LDP）Parameters」レジストリの「Forwarding Equivalence Class（FEC）Type Name Space」の下に割り当てられています。
1. the HSMP-upstream FEC type - 9
1. HSMPアップストリームFECタイプ-9
2. the HSMP-downstream FEC type - 10
2. HSMPダウンストリームFECタイプ-10
The values have been allocated from the "IETF Consensus" [RFC5226] range (0-127).
これらの値は、「IETFコンセンサス」[RFC5226]の範囲（0〜127）から割り当てられています。
One new code point has been allocated for the HSMP LSP capability TLV from "Label Distribution Protocol (LDP) Parameters" registry, under "TLV Type Name Space":
"ラベル配布プロトコル（LDP）パラメータ"レジストリの "TLV Type Name Space"から、HSMP LSP機能TLVに1つの新しいコードポイントが割り当てられました。
HSMP LSP Capability Parameter - 0x0902
HSMP LSP機能パラメーター-0x0902
The value has been allocated from the"IETF Consensus" range (0x0901-0x3DFF).
この値は、「IETFコンセンサス」の範囲（0x0901-0x3DFF）から割り当てられています。
Two new sub-TLV types have been allocated for inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (TLV type 1), Reverse-path Target FEC Stack TLV (TLV type 16), and Reply Path TLV (TLV type 21).
LSP ping [RFC4379]ターゲットFECスタックTLV（TLVタイプ1）、リバースパスターゲットFECスタックTLV（TLVタイプ16）、および応答パスTLV（TLVタイプ21）に含めるために、2つの新しいサブTLVタイプが割り当てられました。 。
o the HSMP-upstream LDP FEC Stack - 29
o HSMPアップストリームLDP FECスタック-29
o the HSMP-downstream LDP FEC Stack - 30
o HSMPダウンストリームLDP FECスタック-30
The value has been allocated from the "IETF Standards Action" range (0-16383) that is used for mandatory and optional sub-TLVs that requires a response if not understood.
この値は、「IETF標準アクション」の範囲（0〜16383）から割り当てられており、理解できない場合に応答を必要とする必須およびオプションのサブTLVに使用されます。
The author would like to thank Eric Rosen, Sebastien Jobert, Fei Su, Edward, Mach Chen, Thomas Morin, and Loa Andersson for their valuable comments.
著者は、Eric Rosen、Sebastien Jobert、Fei Su、Edward、Mach Chen、Thomas Morin、およびLoa Anderssonの貴重なコメントに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLSアップストリームラベル割り当ておよびコンテキスト固有のラベルスペース」、RFC 5331、2008年8月。
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[RFC5332] Eckert、T.、Rosen、E.、Aggarwal、R。、およびY. Rekhter、「MPLSマルチキャストカプセル化」、RFC 5332、2008年8月。
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5561]トーマス、B。、ラザ、K。、アガーワル、S。、アガーワル、R。、およびJL。 Le Roux、「LDP Capabilities」、RFC 5561、2009年7月。
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011.
[RFC6388] Wijnands、IJ。、Minei、I.、Kompella、K。、およびB. Thomas、「ポイントツーマルチポイントおよびマルチポイントツーマルチポイントラベルスイッチドパスのラベル配布プロトコル拡張」、RFC 6388、2011年11月。
[RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, November 2011.
[RFC6389] Aggarwal、R.、JL。 Le Roux、「MPLS Upstream Label Assignment for LDP」、RFC 6389、2011年11月。
[RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, November 2011.
[RFC6425] Saxena、S.、Swallow、G.、Ali、Z.、Farrel、A。、安川S、およびT. Nadeau、「ポイントツーマルチポイントMPLSでのデータプレーン障害の検出-LSPの拡張Ping」、RFC 6425、2011年11月。
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011.
[RFC6426]グレイ、E、バハドゥール、N、ブトロス、S、およびRアガーワル、「MPLSオンデマンド接続検証およびルートトレース」、RFC 6426、2011年11月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Detecting Multi-Protocol Label Switched（MPLS）Data Plane Failures」、RFC 4379、2006年2月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Minei、I。、およびB. Thomas、「LDP仕様」、RFC 5036、2007年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
Authors' Addresses
著者のアドレス
Lizhong Jin Shanghai China
l私は一種のジン上海中国
EMail: lizho.jin@gmail.com
Frederic Jounay Orange CH 4 rue du Caudray 1007 Lausanne Switzerland
Frederic Jounay Orange CH 4 rue du Caudray 1007ローザンヌスイス
EMail: frederic.jounay@orange.ch
IJsbrand Wijnands Cisco Systems, Inc De kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijnands Cisco Systems、Inc De Kleetlaan 6a Diegem 1831 Belgium
EMail: ice@cisco.com
Nicolai Leymann Deutsche Telekom AG Winterfeldtstrasse 21 Berlin 10781 Germany
Nicolai Leymann Deutsche Telekom AG Winterfeldtstrasse 21ベルリン10781ドイツ
EMail: N.Leymann@telekom.de