[要約] 要約：RFC 7473は、非協議型LDPアプリケーションの状態広告を制御するためのガイドラインを提供しています。 目的：このRFCの目的は、非協議型LDPアプリケーションがネットワーク上での状態広告を適切に制御できるようにすることです。
Internet Engineering Task Force (IETF) K. Raza
Request for Comments: 7473 S. Boutros
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 March 2015
Controlling State Advertisements of Non-negotiated LDP Applications
交渉されていないLDPアプリケーションの状態通知の制御
Abstract
概要
There is no capability negotiation done for Label Distribution Protocol (LDP) applications that set up Label Switched Paths (LSPs) for IP prefixes or that signal point-to-point (P2P) Pseudowires (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like Multipoint LDP (mLDP) or the Inter-Chassis Communication Protocol (ICCP). This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications, thus disabling the unnecessary advertisement of corresponding application state, which would have otherwise been advertised over the established LDP session.
IPプレフィックスのラベルスイッチドパス（LSP）を設定するラベル配布プロトコル（LDP）アプリケーション、またはレイヤー2仮想プライベートネットワーク（L2VPN）のポイントツーポイント（P2P）疑似配線（PW）を通知する機能ネゴシエーションはありません。 。 LDPセッションが起動すると、マルチポイントLDP（mLDP）やシャーシ間通信プロトコル（ICCP）などの他のアプリケーションに対してピアセッションが確立されている場合でも、LDPスピーカーがそのようなLDPアプリケーションのローカル状態を不必要にアドバタイズすることがあります。このドキュメントでは、LDPスピーカーがそのようなネゴシエーションされていないアプリケーションでの無関心をピアに通知し、対応するアプリケーション状態の不要なアドバタイズを無効にするソリューションを定義します。そうしないと、確立されたLDPセッションでアドバタイズされます。
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/rfc7473.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7473で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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. Conventions Used in This Document ...............................4
3. Non-negotiated LDP Applications .................................4
3.1. Uninteresting State ........................................5
3.1.1. Prefix-LSPs .........................................5
3.1.2. P2P-PWs .............................................5
4. Controlling State Advertisement .................................5
4.1. State Advertisement Control Capability .....................6
4.2. Capabilities Procedures ....................................8
4.2.1. State Control Capability in an
Initialization Message ..............................9
4.2.2. State Control Capability in a Capability Message ....9
5. Applicability Statement .........................................9
6. Operational Examples ...........................................11
6.1. Disabling Prefix-LSPs and P2P-PWs on an ICCP Session ......11
6.2. Disabling Prefix-LSPs on a L2VPN/PW tLDP Session ..........11
6.3. Disabling Prefix-LSPs Dynamically on an
Established LDP Session ...................................12
6.4. Disabling Prefix-LSPs on an mLDP-only Session .............12
6.5. Disabling IPv4 or IPv6 Prefix-LSPs on a Dual-Stack LSR ....12
7. Security Considerations ........................................13
8. IANA Considerations ............................................13
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................14
Acknowledgments ...................................................15
Authors' Addresses ................................................15
The LDP Capabilities specification [RFC5561] introduced a mechanism to negotiate LDP capabilities for a given feature between peer Label Switching Routers (LSRs). The capability mechanism ensures that no unnecessary state is exchanged between peer LSRs unless the corresponding feature capability is successfully negotiated between the peers.
LDP機能仕様[RFC5561]は、ピアラベルスイッチングルーター（LSR）間で特定の機能のLDP機能をネゴシエートするメカニズムを導入しました。機能メカニズムは、対応する機能の機能がピア間で正常にネゴシエートされない限り、不要な状態がピアLSR間で交換されないことを保証します。
Newly defined LDP features and applications, such as Typed Wildcard Forwarding Equivalence Class (FEC) [RFC5918], Inter-Chassis Communication Protocol [RFC7275], mLDP [RFC6388], and L2VPN Point-to-multipoint (P2MP) PW [RFC7338] make use of LDP capabilities framework for their feature negotiation. However, the earlier LDP applications allowed LDP speakers to exchange application state without any capability negotiation. This, in turn, results in the unnecessary advertisement of state when a given application is not enabled on one of the LDP speakers. These earlier LDP applications include (i) application to establish LSPs for IP unicast prefixes and (ii) application to signal when L2VPN P2P PW [RFC4447] [RFC4762]. For example, when bringing up and using an LDP peer session with a remote Provider Edge (PE) LSR for purely ICCP-signaling reasons, an LDP speaker may unnecessarily advertise labels for IP (unicast) prefixes to this ICCP-related LDP peer.
Typed Wildcard Forwarding Equivalence Class（FEC）[RFC5918]、シャーシ間通信プロトコル[RFC7275]、mLDP [RFC6388]、L2VPNポイントツーマルチポイント（P2MP）PW [RFC7338]など、新しく定義されたLDP機能とアプリケーション機能ネゴシエーションのためのLDP機能フレームワークの使用。ただし、以前のLDPアプリケーションでは、LDPスピーカーは機能のネゴシエーションなしでアプリケーションの状態を交換できました。これにより、LDPスピーカーの1つで特定のアプリケーションが有効になっていない場合に、不要な状態のアドバタイズが発生します。これらの以前のLDPアプリケーションには、（i）IPユニキャストプレフィックスのLSPを確立するアプリケーション、および（ii）L2VPN P2P PW [RFC4447] [RFC4762]を通知するアプリケーションが含まれます。たとえば、純粋にICCPシグナリングの理由でリモートプロバイダーエッジ（PE）LSRとのLDPピアセッションを起動して使用する場合、LDPスピーカーは、このICCP関連のLDPピアにIP（ユニキャスト）プレフィックスのラベルを不必要にアドバタイズすることがあります。
Another example of unnecessary state advertisement can be cited when LDP is to be deployed in an IP dual-stack environment. For instance, an LSR that is locally enabled to set up LSPs for both IPv4 and IPv6 prefixes may advertise (address and label) bindings for both IPv4 and IPv6 address families towards an LDP peer that is interested in IPv4 bindings only. In this case, the advertisement of IPv6 bindings to the peer is unnecessary, as well as wasteful, from the point of view of LSR memory/CPU and network resource consumption.
LDPがIPデュアルスタック環境に配備される場合、不要な状態通知の別の例が挙げられます。たとえば、IPv4とIPv6の両方のプレフィックスに対してLSPを設定するためにローカルで有効になっているLSRは、IPv4とIPv6の両方のアドレスファミリのバインディングを、IPv4バインディングのみに関心のあるLDPピアにアドバタイズ（アドレスとラベル）する場合があります。この場合、ピアへのIPv6バインディングのアドバタイズは、LSRメモリ/ CPUおよびネットワークリソース消費の観点からは無駄であるだけでなく、不要です。
To avoid this unnecessary state advertisement and exchange, currently an operator is typically required to configure and define filtering policies on the LSR, which introduces unnecessary operational overhead and complexity for such deployments.
この不要な状態のアドバタイズと交換を回避するために、現在、オペレーターは通常、LSRでフィルタリングポリシーを構成および定義する必要があります。これにより、このような展開に不要な運用オーバーヘッドと複雑さが生じます。
This document defines a solution based on LDP Capabilities [RFC5561] by which an LDP speaker may announce to its peer(s) its disinterest (or non-support) for state to set up IP Prefix LSPs and/or to signal L2VPN P2P PW at the time of session establishment. This capability helps in avoiding unnecessary state advertisement for such feature applications. This document also states the mechanics to dynamically disable or enable the state advertisement for such applications during the session lifetime. The "uninteresting" state of an application depends on the type of application and is described later in Section 3.1.
このドキュメントでは、LDP機能[RFC5561]に基づくソリューションを定義します。これにより、LDPスピーカーは、IPプレフィックスLSPをセットアップするため、および/またはL2VPN P2P PWに信号を送信するために、状態の無関心（または非サポート）をピアに通知できます。セッション確立の時間。この機能は、そのような機能アプリケーションの不要な状態通知を回避するのに役立ちます。このドキュメントでは、セッションの存続期間中にそのようなアプリケーションの状態の通知を動的に無効または有効にするメカニズムについても説明しています。アプリケーションの「興味のない」状態は、アプリケーションのタイプによって異なり、後でセクション3.1で説明します。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The term "IP" in this document refers to both IPv4 and IPv6 unicast address families.
このドキュメントの「IP」という用語は、IPv4とIPv6の両方のユニキャストアドレスファミリを指します。
For the applications that existed prior to the definition of the LDP Capabilities framework [RFC5561], an LDP speaker typically advertises, without waiting for any capabilities exchange and negotiation, its corresponding application state to its peers after the session establishment. These early LDP applications include:
LDP機能フレームワーク[RFC5561]の定義前に存在していたアプリケーションの場合、LDPスピーカーは通常、機能の交換とネゴシエーションを待たずに、セッションの確立後に対応するアプリケーションの状態をピアにアドバタイズします。これらの初期LDPアプリケーションには次のものがあります。
o IPv4/IPv6 Prefix LSPs Setup o L2VPN P2P FEC 128 and FEC 129 PWs Signaling
o IPv4 / IPv6プレフィックスLSPの設定o L2VPN P2P FEC 128およびFEC 129 PWシグナリング
The rest of This document uses the following shorthand terms for these earlier LDP applications:
このドキュメントの残りの部分では、これらの以前のLDPアプリケーションに次の略語を使用しています。
o "Prefix-LSPs": Refers to an application that sets up LDP LSPs corresponding to IP routes/prefixes by advertising label bindings for Prefix FEC (as defined in RFC 5036).
o 「プレフィックスLSP」：プレフィックスFECのラベルバインディングをアドバタイズすることにより、IPルート/プレフィックスに対応するLDP LSPをセットアップするアプリケーションを指します（RFC 5036で定義）。
o "P2P-PWs": Refers to an application that signals FEC 128 and/or FEC 129 L2VPN P2P PWs using LDP (as defined in RFC 4447).
o 「P2P-PWs」：LDP（RFC 4447で定義）を使用してFEC 128またはFEC 129 L2VPN P2P PWに信号を送るアプリケーションを指します。
To disable unnecessary state exchange for such LDP applications over an established LDP session, a new capability is being introduced in this document. This new capability controls the advertisement of application state and enables an LDP speaker to notify its peer its disinterest in the state of one or more of these "Non-negotiated" LDP applications at the time of session establishment. Upon receipt of such a capability, the receiving LDP speaker, if supporting the capability, disables the advertisement of the state related to the application towards the sender of the capability. This new capability can also be sent later in a Capability message either to disable a previously enabled application's state advertisement or to enable a previously disabled application's state advertisement.
確立されたLDPセッションでのこのようなLDPアプリケーションの不要な状態交換を無効にするために、このドキュメントでは新しい機能が導入されています。この新しい機能は、アプリケーションの状態のアドバタイズを制御し、LDPスピーカーがセッション確立時にこれらの「ネゴシエーションされていない」LDPアプリケーションの1つ以上の状態に興味がないことをピアに通知できるようにします。このような機能を受信すると、受信側のLDPスピーカーは、機能をサポートしている場合、機能に関連するアプリケーションの状態のアドバタイズを無効にします。この新しい機能は、以前に有効にしたアプリケーションの状態の通知を無効にするか、以前に無効にしたアプリケーションの状態の通知を有効にするために、後でCapabilityメッセージで送信することもできます。
A uninteresting state of a non-negotiated LDP application:
交渉されていないLDPアプリケーションの興味のない状態：
- is the application state that is of no interest to an LSR and need not be advertised to the LSR;
- LSRに関係のないアプリケーション状態であり、LSRに通知する必要はありません。
- need not be advertised in any of the LDP protocol messages;
- LDPプロトコルメッセージでアドバタイズする必要はありません。
- is dependent on application type and specified accordingly.
- アプリケーションのタイプに依存し、それに応じて指定されます。
For the Prefix-LSP application type, the uninteresting state refers to any state related to IP Prefix FEC (such as FEC label bindings, LDP Status). This document, however, does not classify IP address bindings (advertised via ADDRESS message) as a uninteresting state and allows the advertisement of IP address bindings. The reason for this allowance is that an LSR typically uses peer IP address(es) to map an IP routing next hop to an LDP peer in order to implement its control plane procedures. For example, mLDP [RFC6388] uses a peer's IP address(es) to determine its upstream LSR to reach the Root node as well as to select the forwarding interface towards its downstream LSR. Hence, in an mLDP-only network, while it is desirable to disable advertisement of label bindings for IP (unicast) prefixes, disabling advertisement of IP address bindings will break mLDP functionality. Similarly, other LDP applications may also depend on learnt peer IP addresses; hence, this document does not put IP address binding into a uninteresting state category to facilitate such LDP applications.
Prefix-LSPアプリケーションタイプの場合、興味のない状態とは、IPプレフィックスFECに関連するすべての状態（FECラベルバインディング、LDPステータスなど）を指します。ただし、このドキュメントでは、IPアドレスバインディング（ADDRESSメッセージを介して通知される）を興味のない状態として分類せず、IPアドレスバインディングの通知を許可しています。この許可の理由は、LSRは通常、コントロールプレーン手順を実装するために、ピアIPアドレスを使用してIPルーティングのネクストホップをLDPピアにマップするためです。たとえば、mLDP [RFC6388]は、ピアのIPアドレスを使用して、ルートノードに到達するためのアップストリームLSRを決定し、ダウンストリームLSRへの転送インターフェイスを選択します。したがって、mLDPのみのネットワークでは、IP（ユニキャスト）プレフィックスのラベルバインディングのアドバタイズを無効にすることが望ましい一方で、IPアドレスバインディングのアドバタイズを無効にすると、mLDP機能が無効になります。同様に、他のLDPアプリケーションも、学習したピアIPアドレスに依存する場合があります。したがって、このドキュメントでは、そのようなLDPアプリケーションを容易にするために、IPアドレスバインディングを興味のない状態のカテゴリに含めません。
For the P2P-PW application type, the uninteresting state refers to any state related to P2P PW FEC 128 / FEC 129 (such as FEC label bindings, Media Access Control (MAC) address withdrawal, and LDP PW Status). In this document, the term "state" will mean to refer to the "uninteresting state" for an application, as defined in this section.
P2P-PWアプリケーションタイプの場合、興味のない状態とは、P2P PW FEC 128 / FEC 129に関連するすべての状態（FECラベルバインディング、メディアアクセス制御（MAC）アドレスの取り消し、およびLDP PWステータスなど）を指します。このドキュメントでは、「状態」という用語は、このセクションで定義されている、アプリケーションの「興味のない状態」を指すことを意味します。
To control advertisement of uninteresting state related to non-negotiated LDP applications defined in Section 3, a new capability TLV is defined as follows.
セクション3で定義されている交渉されていないLDPアプリケーションに関連する興味のない状態の通知を制御するために、新しい機能TLVが次のように定義されています。
The "State Advertisement Control Capability" is a new Capability Parameter TLV defined in accordance with Section 3 of LDP Capabilities specification [RFC5561]. The format of this new TLV is as follows:
「状態アドバタイズメント制御機能」は、LDP機能仕様[RFC5561]のセクション3に従って定義された新しい機能パラメーターTLVです。この新しい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| SAC Capability (0x050D) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |
+-+-+-+-+-+-+-+-+
| |
~ State Advertisement Control Element(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of a "State Advertisement Control Capability" TLV
図1：「状態アドバタイズメント制御機能」TLVのフォーマット
The value of the U-bit for the TLV 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. Whereas, The value of F-bit MUST be set to 0. Once advertised, this capability cannot be withdrawn; thus, the S-bit MUST be set to 1 in an Initialization and Capability message.
TLVのUビットの値は1に設定する必要があります。これにより、不明な場合は受信者がこのTLVを黙って無視し、メッセージの残りの処理を続行する必要があります。一方、Fビットの値は0に設定する必要があります。いったん通知されると、この機能は撤回できません。したがって、Sビットは初期化および機能メッセージで1に設定する必要があります。
The capability data associated with this State Advertisement Control (SAC) Capability TLV is one or more State Advertisement Control Elements, where each element indicates enabling/disabling of advertisement of uninteresting state for a given application. The format of a SAC Element is defined as follows:
このState Advertisement Control（SAC）Capability TLVに関連付けられている機能データは、1つ以上のState Advertisement Control Elementです。各要素は、特定のアプリケーションの興味のない状態のアドバタイズの有効化/無効化を示します。 SAC要素の形式は次のように定義されます。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|D| App |Unused |
+-+-+-+-+-+-+-+-+
Figure 2: Format of "State Advertisement Control Element"
図2：「State Advertisement Control Element」のフォーマット
Where: D-bit: Controls the advertisement of the state specified in the "App" field: 1: Disable state advertisement 0: Enable state advertisement When sent in an Initialization message, the D-bit MUST be set to 1.
Dビット：「アプリ」フィールドで指定された状態の通知を制御します。1：状態通知を無効にします。0：状態通知を有効にします。初期化メッセージで送信される場合、Dビットは1に設定する必要があります。
App: Defines the legacy application type whose state advertisement is to be controlled. The value of this field is defined as follows:
アプリ：状態の通知を制御するレガシーアプリケーションの種類を定義します。このフィールドの値は次のように定義されます。
1: IPv4 Prefix-LSPs (LSPs for IPv4 prefixes) 2: IPv6 Prefix-LSPs (LSPs for IPv6 prefixes) 3: FEC 128 P2P-PW (L2VPN PWid FEC signaling) 4: FEC 129 P2P-PW (L2VPN Generalized PWid FEC signaling)
1：IPv4 Prefix-LSP（IPv4プレフィックスのLSP）2：IPv6 Prefix-LSP（IPv6プレフィックスのLSP）3：FEC 128 P2P-PW（L2VPN PWid FECシグナリング）4：FEC 129 P2P-PW（L2VPN汎用PWid FECシグナリング） ）
Any other value in this field MUST be treated as an error.
このフィールドの他の値はすべてエラーとして処理する必要があります。
Unused: Must Be Zero (MBZ) on transmit and ignored on receipt.
未使用：送信時にはゼロ（MBZ）でなければならず、受信時には無視されます。
The "Length" field of the SAC Capability TLV (in octets) is computed as follows:
SAC機能TLVの「長さ」フィールド（オクテット単位）は、次のように計算されます。
Length (in octets) = 1 + number of SAC elements
長さ（オクテット単位）= 1 + SAC要素の数
For example, if there are two SAC elements present, then the "Length" field is set to 3 octets. A receiver of this capability TLV can deduce the number of elements present in the TLV by using the "Length" field.
たとえば、2つのSAC要素が存在する場合、「長さ」フィールドは3オクテットに設定されます。この機能のTLVの受信者は、「長さ」フィールドを使用して、TLVに存在する要素の数を推定できます。
This document uses the term "element" to refer to a SAC Element.
このドキュメントでは、「要素」という用語を使用してSAC要素を指します。
As described earlier, the SAC Capability TLV MAY be included by an LDP speaker in an Initialization message to signal to its peer LSR that state exchange for one or more applications needs to be disabled on the given peer session. This TLV can also be sent later in a Capability message to selectively enable or disable these applications. If there is more than one element present in a SAC Capability TLV, the elements MUST belong to distinct app types and the app type MUST NOT appear more than once. If a receiver receives such a malformed TLV, it SHOULD discard this TLV and continue processing the rest of the message. If an LSR receives a message with a SAC capability TLV containing an element with the "App" field set to a value other than defined above, the receiver MUST ignore and discard the element and continue processing the rest of the TLV.
前述のように、SDP機能TLVは、LDPスピーカーが初期化メッセージに含めて、特定のピアセッションで1つ以上のアプリケーションの状態交換を無効にする必要があることをピアLSRに通知する場合があります。このTLVは、後で機能メッセージで送信して、これらのアプリケーションを選択的に有効または無効にすることもできます。 SAC機能TLVに複数の要素が存在する場合、要素は異なるアプリタイプに属している必要があり、アプリタイプは複数回出現してはなりません。受信者がそのような不正なTLVを受信した場合、このTLVを破棄し、メッセージの残りの処理を続行する必要があります（SHOULD）。 LSRが、「App」フィールドが上記で定義された以外の値に設定された要素を含むSAC機能TLVのメッセージを受信した場合、受信者はその要素を無視して破棄し、残りのTLVの処理を継続する必要があります。
To control more than one application state, a sender LSR can either send a single capability TLV in a message with multiple elements present or send separate messages with a capability TLV specifying one or more elements. A receiving LSR, however, MUST treat each incoming capability TLV with an element corresponding to a given application type as an update to its existing policy for the given type.
複数のアプリケーション状態を制御するために、送信側LSRは、複数の要素が存在するメッセージで単一の機能TLVを送信するか、1つ以上の要素を指定する機能TLVを持つ個別のメッセージを送信できます。ただし、受信LSRは、特定のアプリケーションタイプに対応する要素を持つ各着信機能TLVを、特定のタイプの既存のポリシーの更新として扱う必要があります。
To understand capability updates from an example, let us consider two LSRs, S (LDP speaker) and P (LDP peer), both of which support all the non-negotiated applications listed earlier. By default, these LSRs will advertise state for these applications, as configured, to their peer as soon as an LDP session is established. Now assume that P receives from S a SAC capability in an Initialization message with "IPv6 Prefix-LSPs" and "FEC 129 P2P-PW" applications disabled. This updates P's outbound policy towards S to advertise state related to only IPv4 Prefix-LSPs and FEC 128 P2P-PW applications. Later, P receives another capability update from S via a Capability message with "IPv6 Prefix-LSPs" enabled and "FEC 128 P2P-PWs" disabled. This results in P's outbound policy towards S to advertise both IPv4 and IPv6 Prefix-LSPs application state and disable both FEC 128 and FEC 129 P2P-PWs signaling. Finally, P receives another update from S via a Capability message that specifies to disable all four non-negotiated applications states, resulting in P outbound policy towards S to block/disable state for all these applications and only advertise state for any other application, as applicable.
例から機能の更新を理解するために、S（LDPスピーカー）とP（LDPピア）の2つのLSRについて考えてみましょう。どちらも前述の非ネゴシエートされたすべてのアプリケーションをサポートしています。デフォルトでは、これらのLSRは、LDPセッションが確立されるとすぐに、設定されたこれらのアプリケーションの状態をピアにアドバタイズします。ここで、PがSから、「IPv6 Prefix-LSPs」および「FEC 129 P2P-PW」アプリケーションを無効にした初期化メッセージでSAC機能を受信するとします。これにより、Sに対するPの発信ポリシーが更新され、IPv4 Prefix-LSPおよびFEC 128 P2P-PWアプリケーションのみに関連する状態がアドバタイズされます。その後、Pは、「IPv6 Prefix-LSPs」を有効にして「FEC 128 P2P-PWs」を無効にした機能メッセージを介して、Sから別の機能更新を受信します。これにより、Sに対するPの発信ポリシーがIPv4とIPv6の両方のプレフィックスLSPアプリケーション状態をアドバタイズし、FEC 128とFEC 129の両方のP2P-PWシグナリングを無効にします。最後に、Pは、ネゴシエーションされていない4つのアプリケーション状態すべてを無効にすることを指定する機能メッセージを介してSから別の更新を受信します。その結果、PはSに対する送信ポリシーで、これらすべてのアプリケーションの状態をブロック/無効にし、他のアプリケーションの状態のみをアドバタイズします。該当します。
The SAC capability conveys the desire of an LSR to disable the receipt of unwanted/unnecessary state from its LDP peer. This capability is unilateral and unidirectional in nature, and a receiving LSR is not required to send a similar capability TLV in an Initialization or Capability message towards the sender of this capability. This unilateral behavior conforms to the procedures defined in the Section 6 of LDP Capabilities [RFC5561].
SAC機能は、LSRがLDPピアからの不要な/不要な状態の受信を無効にするという要望を伝えます。この機能は本質的に一方向性および一方向性であり、この機能の送信者に向けて初期化または機能メッセージで同様の機能TLVを送信するために受信LSRは必要ありません。この一方的な動作は、LDP機能[RFC5561]のセクション6で定義された手順に準拠しています。
After this capability is successfully negotiated (i.e., sent by an LSR and received/understood by its peer), then the receiving LSR MUST NOT advertise any state related to the disabled applications towards the capability-sending LSR until and unless these application states are explicitly enabled again via a capability update. Upon receipt of a capability update to disable an enabled application state during the lifetime of a session, the receiving LSR MUST also withdraw from the peer any previously advertised state corresponding to the disabled application.
この機能が正常にネゴシエートされた（つまり、LSRによって送信され、ピアによって受信/理解された）後、受信側のLSRは、これらのアプリケーションの状態が明示的になるまで、無効にされたアプリケーションに関連する状態を、機能を送信するLSRに向けて通知してはなりません（MUST NOT）。機能の更新により再度有効化されました。セッションの有効期間中に有効なアプリケーションの状態を無効にする機能の更新を受信すると、受信側のLSRは、無効にされたアプリケーションに対応する以前にアドバタイズされた状態もピアから取り消す必要があります。
If a receiving LDP speaker does not understand the SAC capability TLV, then it MUST respond to the sender with an "Unsupported TLV" notification as described in "LDP Capabilities" [RFC5561]. If a receiving LDP speaker does not understand or does not support an application specified in an application control element, it SHOULD silently ignore/skip such an element and continue processing rest of the TLV.
受信LDPスピーカーがSAC機能TLVを理解できない場合、「LDP機能」[RFC5561]で説明されているように、「サポートされていないTLV」通知で送信者に応答する必要があります。受信側のLDPスピーカーがアプリケーション制御要素で指定されたアプリケーションを理解しないかサポートしていない場合は、そのような要素を黙って無視/スキップし、TLVの残りの処理を続行する必要があります。
The LDP Capabilities framework [RFC5561] dictates that the S-bit of the capability parameter in an Initialization message MUST be set to 1 and SHOULD be ignored on receipt.
LDP機能フレームワーク[RFC5561]では、初期化メッセージの機能パラメーターのSビットを1に設定する必要があり、受信時には無視する必要があります。
An LDP speaker determines (e.g., via some local configuration or default policy) if it needs to disable Prefix-LSPs and/or P2P-PW applications with a peer LSR. If there is a need to disable, then the SAC TLV needs to be included in the Initialization message with respective SAC elements included with their D-bit set to 1.
LDPスピーカーは、ピアLSRを使用してPrefix-LSPやP2P-PWアプリケーションを無効にする必要があるかどうかを（たとえば、ローカル構成またはデフォルトポリシーを介して）決定します。無効にする必要がある場合は、SAC TLVを初期化メッセージに含める必要があり、それぞれのSAC要素にはDビットが1に設定されて含まれています。
An LDP speaker that supports the SAC capability MUST interpret the capability TLV in a received Initialization message such that it disables the advertisement of the application state towards the capability sending LSR for Prefix-LSPs and/or P2P-PW applications if their SAC element's D-bit is set to 1.
SAC機能をサポートするLDPスピーカーは、受信した初期化メッセージの機能TLVを解釈して、SAC要素のD-の場合、プレフィックスLSPやP2P-PWアプリケーションのLSRを送信する機能へのアプリケーション状態のアドバタイズを無効にする必要があります。ビットは1に設定されます。
If the LDP peer supports "Dynamic Announcement Capability" [RFC5561], then an LDP speaker may send a SAC capability in a Capability message towards the peer. Once advertised, these capabilities cannot be withdrawn; hence, the S-bit of the TLV MUST be set to 1 when sent in a Capability message.
LDPピアが「ダイナミックアナウンス機能」[RFC5561]をサポートしている場合、LDPスピーカーはピアに向けて機能メッセージでSAC機能を送信できます。いったん宣伝されると、これらの機能を撤回することはできません。したがって、Capabilityメッセージで送信される場合、TLVのSビットを1に設定する必要があります。
An LDP speaker may decide to send this TLV towards an LDP peer if one or more of its Prefix-LSPs and/or P2P-PW applications get disabled, or if a previously disabled application gets enabled again. In this case, the LDP speaker constructs the TLV with appropriate SAC elements and sends the corresponding capability TLV in a Capability message.
LDPスピーカーは、1つ以上のPrefix-LSPやP2P-PWアプリケーションが無効になった場合、または以前に無効にされたアプリケーションが再び有効になった場合に、このTLVをLDPピアに送信することを決定できます。この場合、LDPスピーカーは適切なSAC要素を使用してTLVを構築し、対応する機能TLVを機能メッセージで送信します。
Upon receipt of this TLV in a Capability message, the receiving LDP speaker reacts in the same manner as it reacts upon the receipt of this TLV in an Initialization message. Additionally, the peer withdraws/advertises the application state to/from the capability-sending LDP speaker according to the capability update.
ケイパビリティメッセージでこのTLVを受信すると、受信側のLDPスピーカーは、初期化メッセージでこのTLVを受信したときと同じように反応します。さらに、ピアは、機能の更新に応じて、アプリケーションの状態を機能送信LDPスピーカーとの間で撤回/アドバタイズします。
The procedures defined in this document may result in a disabling announcement of label bindings for IP Prefixes and/or P2P PW FECs and, hence, should be used with caution and discretion. This document recommends that this new SAC capability and its procedures SHOULD be enabled on an LSR only via a configuration knob. This knob could either be a global LDP knob or be implemented per LDP neighbor. Hence, it is recommended that an operator SHOULD enable this capability and its associated procedures on an LSR towards a neighbor only if it is known that such bindings advertisement and exchange with the neighbor is unnecessary and wasteful.
このドキュメントで定義されている手順は、IPプレフィックスやP2P PW FECのラベルバインディングの無効化の通知をもたらす可能性があるため、注意して慎重に使用する必要があります。このドキュメントでは、この新しいSAC機能とその手順は、構成ノブを介してのみLSRで有効にする必要があることを推奨しています。このノブは、グローバルLDPノブにすることも、LDPネイバーごとに実装することもできます。したがって、このようなバインディングアドバタイズとネイバーとの交換が不要で無駄であることがわかっている場合にのみ、オペレーターはこの機能とその関連手順をLSRでネイバーに向けて有効にする必要があります。
The following table summarizes a non-exhaustive list of typical LDP session types on which this new SAC capability and its procedures are expected to be applied to disable advertisement of uninteresting state:
次の表は、この新しいSAC機能とその手順を適用して、関心のない状態のアドバタイズを無効にすることが期待される一般的なLDPセッションタイプの完全なリストをまとめたものです。
+===============================+=================================+
| Session Type(s) | Uninteresting State |
+===============================+=================================+
| P2P-PW FEC 128-only | IP Prefix LSPs + P2P-PW FEC 129 |
|-------------------------------|---------------------------------|
| P2P-PW only (FEC 128/129) | IP Prefix LSPs |
|-------------------------------|---------------------------------|
| IPv4-only on a Dual-Stack LSR | IPv6 Prefix LSPs + P2P-PW |
|-------------------------------|---------------------------------|
| IPv6-only on a Dual-Stack LSR | IPv4 Prefix LSPs + P2P-PW |
|-------------------------------|---------------------------------|
| mLDP-only | IP Prefix LSPs + P2P-PW |
|-------------------------------|---------------------------------|
| ICCP-only | IP Prefix LSPs + P2P-PW |
+-------------------------------+---------------------------------+
It is to be noted that if an application state needs changing after session initialization (e.g., to enable a previously disabled application or to disable a previously enabled application), the procedures defined in this document expect LSR peers to support the LDP "Dynamic Announcement" Capability to announce the change in SAC capability via an LDP Capability message. However, if any of the peering LSRs do not support this capability, the alternate option is to force reset the LDP session to advertise the new SAC capability accordingly during the following session initialization.
セッションの初期化後にアプリケーションの状態を変更する必要がある場合（たとえば、以前に無効にしたアプリケーションを有効にする、または以前に有効にしたアプリケーションを無効にするなど）、このドキュメントで定義されている手順では、LSRピアがLDPの「ダイナミックアナウンス」をサポートすることを想定しています。 LDP機能メッセージを介してSAC機能の変更を通知する機能。ただし、ピアリングLSRのいずれかがこの機能をサポートしていない場合、代替オプションは、LDPセッションを強制的にリセットして、次のセッションの初期化中に新しいSAC機能をアドバタイズすることです。
The following are some additional important points that an operator needs to consider regarding the applicability of this new capability and associated procedures defined in this document:
オペレーターがこのドキュメントで定義されているこの新しい機能と関連する手順の適用性に関して考慮する必要があるいくつかの追加の重要なポイントを次に示します。
- An operator SHOULD disable Prefix-LSP state on any Targeted LDP (tLDP) session that is established for ICCP-only and/or PW-only purposes.
- オペレーターはICCPのみまたはPWのみの目的で確立されたターゲットLDP（tLDP）セッションでPrefix-LSP状態を無効にする必要があります（SHOULD）。
- An operator MUST NOT disable Prefix-LSP state on any tLDP session that is established for reasons related to remote Loop-Free Alternate (LFA) Fast Re-Route (FRR) [RLFA].
- オペレーターは、リモートのループフリー代替（LFA）高速再ルーティング（FRR）[RLFA]に関連する理由で確立されたtLDPセッションでPrefix-LSP状態を無効にしてはなりません（MUST NOT）。
- In a remote network that is LFA FRR [RLFA] enabled, it is RECOMMENDED not to disable Prefix-LSP state on a tLDP session even if the current session type is PW-only and/or ICCP-only. This is recommended because any remote/tLDP neighbor could potentially be picked as a remote LFA PQ node.
- LFA FRR [RLFA]が有効になっているリモートネットワークでは、現在のセッションタイプがPWのみまたはICCPのみ、あるいはその両方であっても、tLDPセッションでPrefix-LSP状態を無効にしないことをお勧めします。リモート/ tLDPネイバーがリモートLFA PQノードとして選択される可能性があるため、これが推奨されます。
- This capability SHOULD be enabled for Prefix-LSPs in the scenarios when it is desirable to disable (or enable) advertisement of "all" the prefix label bindings. For scenarios in which a "subset" of bindings need to be filtered, the existing filtering procedures pertaining to label binding announcement should be used.
- この機能は、「すべて」のプレフィックスラベルバインディングのアドバタイズを無効（または有効）にすることが望ましいシナリオで、プレフィックスLSPに対して有効にする必要があります（SHOULD）。バインディングの「サブセット」をフィルタリングする必要があるシナリオでは、ラベルバインディングアナウンスに関する既存のフィルタリング手順を使用する必要があります。
- Using label advertisement filtering policies in conjunction with the procedures defined in this document for Prefix-LSPs is allowed. In such cases, the label bindings will be announced as per the label filtering policy for the given neighbor when Prefix-LSP application is enabled.
- このドキュメントで定義されている手順と組み合わせて、ラベルアドバタイズメントフィルタリングポリシーをPrefix-LSPに対して使用することが許可されています。このような場合、ラベルバインディングは、Prefix-LSPアプリケーションが有効になっているときに、指定されたネイバーのラベルフィルタリングポリシーに従って通知されます。
Consider two PE routers, LSR1 and LSR2, that understand/support SAC capability TLV and have an established LDP session to exchange ICCP state related to dual-homed devices connected to these LSRs. Let us assume that both LSRs are provisioned not to exchange any state for Prefix-LSPs (IPv4/IPv6) and P2P-PWs (FEC 128/129) application.
SAC機能TLVを理解/サポートし、これらのLSRに接続されたデュアルホームデバイスに関連するICCP状態を交換するために確立されたLDPセッションを持っている2つのPEルーター、LSR1とLSR2を考えます。両方のLSRが、Prefix-LSP（IPv4 / IPv6）およびP2P-PW（FEC 128/129）アプリケーションの状態を交換しないようにプロビジョニングされていると仮定します。
To indicate their disinterest in these applications, the LSRs will include a SAC capability TLV (with four SAC elements corresponding to these four applications with D-bit set to 1 for each one) in the Initialization message. Upon receipt of this TLV in Initialization message, the receiving LSR will disable the advertisement of IPv4/IPv6 label bindings, as well as P2P PW FEC 128/129 signaling, towards its peer after session establishment.
これらのアプリケーションへの関心がないことを示すために、LSRは初期化メッセージにSAC機能TLV（Dビットが1に設定されたこれらの4つのアプリケーションに対応する4つのSAC要素）を含めます。初期化メッセージでこのTLVを受信すると、受信側のLSRは、セッションの確立後にピアへのIPv4 / IPv6ラベルバインディングのアドバタイズとP2P PW FEC 128/129シグナリングを無効にします。
Consider LSR1 and LSR2 have an established tLDP session for P2P-PW applications to exchange label bindings for FEC 128/129. Given that there is no need to exchange IP label bindings amongst the PE LSRs over a PW tLDP session in most typical deployments, let us assume that LSRs are provisioned to disable IPv4/IPv6 Prefix-LSPs application state on the given PW session.
LSR1とLSR2がP2P-PWアプリケーションがFEC 128/129のラベルバインディングを交換するためのtLDPセッションを確立していることを考慮してください。ほとんどの一般的な展開では、PW tLDPセッションを介してPE LSR間でIPラベルバインディングを交換する必要がないことを考慮して、特定のPWセッションでIPv4 / IPv6 Prefix-LSPsアプリケーション状態を無効にするためにLSRがプロビジョニングされていると仮定します。
To indicate their disinterest in Prefix-LSP applications over a PW tLDP session, the LSRs will follow/apply the same procedures as described in previous section. As a result, only P2P-PW-related state will be exchanged between these LSRs over this tLDP session.
PW tLDPセッションを介してPrefix-LSPアプリケーションに関心がないことを示すために、LSRは前のセクションで説明したのと同じ手順に従います/適用します。その結果、このtLDPセッションでこれらのLSR間で交換されるのは、P2P-PW関連の状態のみです。
Assume that LSRs from previous sections were initially provisioned to exchange both Prefix-LSP and P2P-PW state over the session between them and also support the "Dynamic Announcement" Capability of [RFC5561]. Now, assume that LSR1 is dynamically provisioned to disable (IPv4/IPv6) Prefix-LSPs over a tLDP session with LSR2. In this case, LSR1 will send a SAC capability TLV in a Capability message towards LSR2 with application control elements defined for IPv4 and IPv6 Prefix-LSPs with the D-bit set to 1. Upon receipt of this TLV, LSR2 will disable Prefix-LSPs application state(s) towards LSR1 and withdraw all previously advertised application state from LSR1. To withdraw label bindings from its peer, LSR2 MAY use a single Prefix FEC Typed Wildcard Label Withdraw message [RFC5918] if the peer supports the Typed Wildcard FEC capability.
前のセクションのLSRは、セッション間のPrefix-LSPとP2P-PWの両方の状態を交換するために最初にプロビジョニングされ、[RFC5561]の「ダイナミックアナウンス」機能もサポートすると想定します。ここで、LSR1が動的にプロビジョニングされ、LSR2とのtLDPセッションで（IPv4 / IPv6）Prefix-LSPを無効にするとします。この場合、LSR1は、ケイパビリティメッセージでSAC機能TLVをLSR2に向けて送信し、IPv4およびIPv6 Prefix-LSPに対して定義されたDビットが1に設定されたアプリケーション制御要素を使用します。このTLVを受信すると、LSR2はPrefix-LSPを無効にしますアプリケーションの状態をLSR1に向け、以前にアドバタイズされたすべてのアプリケーションの状態をLSR1から取り消します。ピアからラベルバインディングを撤回するために、ピアがタイプワイルドカードFEC機能をサポートしている場合、LSR2は単一のPrefix FEC Typed Wildcard Label Withdrawメッセージ[RFC5918]を使用してもよい（MAY）。
This dynamic disability of Prefix-LSPs application does not impact L2VPN P2P-PW application on the given session, and both LSRs should continue to exchange state related to PW Signaling applications.
Prefix-LSPアプリケーションのこの動的な障害は、特定のセッションのL2VPN P2P-PWアプリケーションに影響を与えず、両方のLSRがPWシグナリングアプリケーションに関連する状態を交換し続ける必要があります。
Assume that LSR1 and LSR2 have formed an LDP session to exchange mLDP state only. In typical deployments, LSR1 and LSR2 also exchange bindings for IP (unicast) prefixes upon mLDP session, which is unnecessary and wasteful for an mLDP-only LSR.
LSR1とLSR2がLDPセッションを形成して、mLDP状態のみを交換するとします。通常の展開では、LSR1とLSR2は、mLDPセッションでIP（ユニキャスト）プレフィックスのバインディングも交換します。これは、MLDPのみのLSRには不要で無駄です。
Using the procedures defined earlier, an LSR can indicate its disinterest in Prefix-LSP application state to its peer upon session establishment time or dynamically later via an LDP capabilities update.
LSRは、以前に定義された手順を使用して、セッションの確立時に、またはLDP機能の更新を介して動的に、ピアにPrefix-LSPアプリケーション状態の無関心を示すことができます。
In reference to Section 3.1, the peer disables the advertisement of any state related to IP Prefix FECs, but it still advertises IP address bindings that are required for the correct operation of mLDP.
セクション3.1を参照すると、ピアはIPプレフィックスFECに関連するすべての状態の通知を無効にしますが、mLDPの正しい操作に必要なIPアドレスバインディングを通知します。
In IP dual-stack scenarios, LSR2 may advertise unnecessary state (e.g., IPv6 prefix label bindings) towards peer LSR1 corresponding to IPv6 Prefix-LSP applications once a session is established mainly for exchanging state for IPv4. The similar scenario also applies when advertising IPv4 Prefix-LSP state on a session meant for IPv6. The SAC capability and its procedures defined in this document can help to avoid such unnecessary state advertisement.
IPデュアルスタックシナリオでは、セッションが主にIPv4の状態を交換するために確立されると、LSR2はIPv6 Prefix-LSPアプリケーションに対応するピアLSR1に向けて不要な状態（IPv6プレフィックスラベルバインディングなど）をアドバタイズします。 IPv6向けのセッションでIPv4 Prefix-LSP状態をアドバタイズする場合も、同様のシナリオが適用されます。このドキュメントで定義されているSAC機能とその手順は、このような不要な状態の通知を回避するのに役立ちます。
Consider an IP dual-stack environment where LSR2 is enabled for Prefix-LSPs application for both IPv4 and IPv6, but LSR1 is enabled for (or interested in) only IPv4 Prefix-LSPs. To avoid receiving unwanted state advertisement for IPv6 Prefix-LSP applications from LSR2, LSR1 can send a SAC capability with an element for IPv6 Prefix-LSPs with the D-bit set to 1 in the Initialization message towards LSR2 at the time of session establishment. Upon receipt of this capability, LSR2 will disable all IPv6 label binding advertisements towards LSR1. If IPv6 Prefix-LSP applications are later enabled on LSR1, LSR1 can update the capability by sending a SAC capability in a Capability message towards LSR2 to enable this application dynamically.
LSR2がIPv4とIPv6の両方のPrefix-LSPアプリケーションで有効になっているが、LSR1はIPv4 Prefix-LSPのみで有効になっている（または関心がある）IPデュアルスタック環境を考えてみます。 LSR2からIPv6 Prefix-LSPアプリケーションの不要な状態アドバタイズを受信しないようにするために、LSR1は、セッションの確立時にLSR2に向けて、初期化メッセージでDビットが1に設定されたIPv6 Prefix-LSPの要素を含むSAC機能を送信できます。この機能を受け取ると、LSR2はLSR1へのすべてのIPv6ラベルバインディングアドバタイズを無効にします。 LSR1でIPv6 Prefix-LSPアプリケーションを後で有効にした場合、LSR1は、機能メッセージでSAC機能をLSR2に送信して機能を更新し、このアプリケーションを動的に有効にすることができます。
The proposal introduced in this document does not introduce any new security considerations beyond those that already apply to the base LDP specification [RFC5036] and to MPLS and GMPLS [RFC5920].
このドキュメントで紹介されている提案は、ベースLDP仕様[RFC5036]とMPLSおよびGMPLS [RFC5920]にすでに適用されているセキュリティの考慮事項を超える新しいセキュリティの考慮事項を紹介していません。
This document defines a new LDP capability parameter TLV. IANA has assigned the following value from "TLV Type Name Space" in the "Label Distribution Protocol (LDP) Parameters" registry as the new code point for the new LDP capability TLV code point.
このドキュメントでは、新しいLDP機能パラメータTLVを定義しています。 IANAは、「Label Distribution Protocol（LDP）Parameters」レジストリの「TLV Type Name Space」から次の値を、新しいLDP機能のTLVコードポイントの新しいコードポイントとして割り当てました。
+--------+---------------------+-----------+-----------------------+
| Value | Description | Reference |Notes/Registration Date|
+--------+---------------------+-----------+-----------------------+
| 0x050D | State Advertisement | RFC 7473 | |
| | Control Capability | | |
+--------+---------------------+-----------+-----------------------+
[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>。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、October 2007、<http://www.rfc-editor.org / info / rfc5036>。
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009, <http://www.rfc-editor.org/info/rfc5561>.
[RFC5561]トーマス、B。、ラザ、K。、アガーワル、S。、アガーワル、R。、およびJL。 Le Roux、「LDP Capabilities」、RFC 5561、2009年7月、<http://www.rfc-editor.org/info/rfc5561>。
[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, 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 、2006年4月、<http://www.rfc-editor.org/info/rfc4447>。
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007, <http://www.rfc-editor.org/info/rfc4762>.
[RFC4762] Lasserre、M。、編、およびV. Kompella、編、「Label Distribution Protocol（LDP）シグナリングを使用した仮想プライベートLANサービス（VPLS）」、RFC 4762、2007年1月、<http：// www。 rfc-editor.org/info/rfc4762>。
[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, August 2010, <http://www.rfc-editor.org/info/rfc5918>.
[RFC5918] Asati、R.、Minei、I。、およびB. Thomas、「Label Distribution Protocol（LDP） 'Typed Wildcard' Forward Equivalence Class（FEC）」、RFC 5918、2010年8月、<http：// www。 rfc-editor.org/info/rfc5918>。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月、<http://www.rfc-editor.org/info/rfc5920>。
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011, <http://www.rfc-editor.org/info/rfc6388>.
[RFC6388] Wijnands、IJ。、Ed。、Minei、I.、Ed。、Kompella、K.、and B. Thomas、 "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths" 、RFC 6388、2011年11月、<http://www.rfc-editor.org/info/rfc6388>。
[RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M., Matsushima, S., and T. Nadeau, "Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy", RFC 7275, June 2014, <http://www.rfc-editor.org/info/rfc7275>.
[RFC7275] Martini、L.、Salam、S.、Sajassi、A.、Bocci、M.、Matsushima、S。、およびT. Nadeau、「レイヤー2仮想プライベートネットワーク（L2VPN）プロバイダーエッジのシャーシ間通信プロトコル」 （PE）Redundancy」、RFC 7275、2014年6月、<http://www.rfc-editor.org/info/rfc7275>。
[RFC7338] Jounay, F., Ed., Kamite, Y., Ed., Heron, G., and M. Bocci, "Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks", RFC 7338, September 2014, <http://www.rfc-editor.org/info/rfc7338>.
[RFC7338] Jounay、F.、Ed。、Kamite、Y.、Ed。、Heron、G.、and M. Bocci、 "Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks"、RFC 7338、 2014年9月、<http://www.rfc-editor.org/info/rfc7338>。
[RLFA] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Re-Route (FRR)", draft-ietf-rtgwg-remote-lfa-11, Work in Progress, January 2015.
[RLFA] Bryant、S.、Filsfils、C.、Previdi、S.、Shand、M。、およびN.したがって、「Remote Loop-Free Alternate（LFA）Fast Re-Route（FRR）」、draft-ietf- rtgwg-remote-lfa-11、Work in Progress、2015年1月。
Acknowledgments
謝辞
The authors would like to thank Eric Rosen and Alexander Vainshtein for their review and valuable comments. We also acknowledge Karthik Subramanian and IJsbrand Wijnands for bringing up mLDP use case.
著者たちは、レビューと貴重なコメントをしてくれたEric RosenとAlexander Vainshteinに感謝します。また、mLDPの使用例を提起してくれたKarthik Subramanian氏とIJsbrand Wijnands氏にも感謝いたします。
Authors' Addresses
著者のアドレス
Kamran Raza Cisco Systems, Inc. 2000 Innovation Drive Ottawa, ON K2K-3E8 Canada EMail: skraza@cisco.com
Kamran Raza Cisco Systems、Inc. 2000 Innovation Drive Ottawa、ON K2K-3E8 Canada EMail：skraza@cisco.com
Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, CA 95134 United States EMail: sboutros@cisco.com
Sami Boutros Cisco Systems、Inc. 3750 Cisco Way San Jose、CA 95134米国Eメール：sboutros@cisco.com