[要約] RFC 8223は、アプリケーションに適したターゲットLDP（Label Distribution Protocol）の要約です。その目的は、LDPを使用してアプリケーションの要件に合わせた最適な経路を提供することです。
Internet Engineering Task Force (IETF) S. Esale
Request for Comments: 8223 R. Torvi
Updates: 7473 Juniper Networks
Category: Standards Track L. Jalil
ISSN: 2070-1721 Verizon
U. Chunduri
Huawei
K. Raza
Cisco Systems, Inc.
August 2017
Application-Aware Targeted LDP
アプリケーション対応のターゲットLDP
Abstract
概要
Recent Targeted Label Distribution Protocol (tLDP) applications, such as remote Loop-Free Alternates (LFAs) and BGP auto-discovered pseudowires, may automatically establish a tLDP session with any Label Switching Router (LSR) in a network. The initiating LSR has information about the targeted applications to administratively control initiation of the session. However, the responding LSR has no such information to control acceptance of this session. This document defines a mechanism to advertise and negotiate the Targeted Application Capability (TAC) during LDP session initialization. As the responding LSR becomes aware of targeted applications, it may establish a limited number of tLDP sessions for certain applications. In addition, each targeted application is mapped to LDP Forwarding Equivalence Class (FEC) elements to advertise only necessary LDP FEC label bindings over the session. This document updates RFC 7473 for enabling advertisement of LDP FEC label bindings over the session.
リモートのLoop-Free Alternate（LFA）やBGP自動検出疑似配線などの最近のターゲットラベル配布プロトコル（tLDP）アプリケーションは、ネットワーク内の任意のラベルスイッチングルーター（LSR）とのtLDPセッションを自動的に確立する場合があります。開始LSRには、セッションの開始を管理上制御するためのターゲットアプリケーションに関する情報があります。ただし、応答するLSRには、このセッションの受け入れを制御するそのような情報はありません。このドキュメントでは、LDPセッションの初期化中にターゲットアプリケーション機能（TAC）を通知およびネゴシエートするメカニズムを定義します。応答するLSRがターゲットアプリケーションを認識すると、特定のアプリケーションに対して限られた数のtLDPセッションを確立できます。さらに、対象となる各アプリケーションはLDPフォワーディング同等クラス（FEC）要素にマップされ、必要なLDP FECラベルバインディングのみをセッションで通知します。このドキュメントは、セッションでのLDP FECラベルバインディングのアドバタイズを有効にするためにRFC 7473を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8223.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8223で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
1.2. Terminology ................................................4
2. Targeted Application Capability .................................5
2.1. Encoding ...................................................5
2.2. Procedures .................................................5
2.3. LDP Message Procedures .....................................8
2.3.1. Initialization Message ..............................8
2.3.2. Capability Message ..................................8
3. Targeted Application FEC Advertisement Procedures ...............9
4. Interaction of Targeted Application Capabilities and State
Advertisement Control Capabilities .............................10
5. Use Cases ......................................................12
5.1. Remote LFA Automatic Targeted Session .....................12
5.2. FEC 129 Auto-discovery Targeted Session ...................13
5.3. LDP over RSVP and Remote LFA Targeted Session .............13
5.4. mLDP Node Protection Targeted Session .....................13
6. Security Considerations ........................................14
7. IANA Considerations ............................................14
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
Acknowledgments ...................................................17
Contributors ......................................................17
Authors' Addresses ................................................18
LDP uses the Extended Discovery mechanism to establish the Targeted LDP (tLDP) adjacency and subsequent session, as described in [RFC5036]. A Label Switching Router (LSR) initiates Extended Discovery by sending a tLDP Hello to a specific address. The remote LSR decides to either accept or ignore the tLDP Hello based on local configuration only. A tLDP application is an application that uses a tLDP session to exchange information such as FEC label bindings ("FEC" stands for "Forwarding Equivalence Class") with a peer LSR in the network. For an application such as FEC 128 pseudowire, the remote LSR is configured with the source LSR address so that it can use that information to accept or ignore a given tLDP Hello.
[RFC5036]で説明されているように、LDPは拡張ディスカバリメカニズムを使用して、ターゲットLDP（tLDP）隣接と後続のセッションを確立します。ラベルスイッチングルーター（LSR）は、tLDP Helloを特定のアドレスに送信することにより、拡張ディスカバリーを開始します。リモートLSRは、ローカル構成のみに基づいて、tLDP Helloを受け入れるか無視するかを決定します。 tLDPアプリケーションは、tLDPセッションを使用して、FECラベルバインディング（ "FEC"は "Forwarding Equivalence Class"の略）などの情報をネットワーク内のピアLSRと交換するアプリケーションです。 FEC 128疑似配線などのアプリケーションの場合、リモートLSRは送信元LSRアドレスで構成されているため、その情報を使用して、特定のtLDP Helloを受け入れるか無視できます。
However, applications such as remote Loop-Free Alternates (LFAs) and BGP auto-discovered pseudowires automatically initiate asymmetric Extended Discovery to any LSR in a network based on local state only. With these applications, the remote LSR is not explicitly configured with the source LSR address. So, the remote LSR either responds to all tLDP Hellos or ignores them.
ただし、リモートループフリー代替（LFA）やBGP自動検出疑似配線などのアプリケーションは、ローカル状態のみに基づいて、ネットワーク内の任意のLSRに対して非対称拡張検出を自動的に開始します。これらのアプリケーションでは、リモートLSRはソースLSRアドレスで明示的に構成されていません。したがって、リモートLSRはすべてのtLDP Helloに応答するか、それらを無視します。
In addition, since the session is initiated and established after adjacency formation, the responding LSR has no information on targeted applications available from which it can choose a session with a targeted application that it is configured to support. Also, the initiating LSR may employ a limit per application on locally initiated automatic tLDP sessions; however, the responding LSR has no such information to employ a similar limit on the incoming tLDP sessions. Further, the responding LSR does not know whether the source LSR is establishing a tLDP session for configured applications, automatic applications, or both.
さらに、隣接関係の形成後にセッションが開始および確立されるため、応答するLSRには、サポートするように構成されているターゲットアプリケーションとのセッションを選択できる、ターゲットアプリケーションに関する情報がありません。また、開始側のLSRは、ローカルで開始された自動tLDPセッションでアプリケーションごとの制限を採用する場合があります。ただし、応答するLSRには、着信tLDPセッションに同様の制限を適用するための情報がありません。さらに、応答するLSRは、構成されたアプリケーション、自動アプリケーション、またはその両方に対して、ソースLSRがtLDPセッションを確立しているかどうかを知りません。
This document proposes and describes a solution to advertise the Targeted Application Capability (TAC), consisting of a list of targeted applications, during initialization of a tLDP session. It also defines a mechanism to enable a new application and disable an old application after session establishment. This capability advertisement provides the responding LSR with the necessary information to control the acceptance of tLDP sessions per application. For instance, an LSR may accept all BGP auto-discovered tLDP sessions as described in [RFC6074] but may only accept a limited number of remote LFA tLDP sessions as described in [RFC7490].
このドキュメントでは、tLDPセッションの初期化中に、ターゲットアプリケーションのリストで構成されるターゲットアプリケーション機能（TAC）をアドバタイズするソリューションを提案および説明します。また、セッションの確立後に新しいアプリケーションを有効にし、古いアプリケーションを無効にするメカニズムも定義します。この機能アドバタイズは、アプリケーションごとのtLDPセッションの受け入れを制御するために必要な情報を、応答するLSRに提供します。たとえば、LSRは、[RFC6074]で説明されているように、すべてのBGP自動検出tLDPセッションを受け入れることができますが、[RFC7490]で説明されているように、限られた数のリモートLFA tLDPセッションのみを受け入れることができます。
Also, the tLDP application is mapped to LDP FEC element types to advertise specific application FECs only, avoiding the advertisement of other unnecessary FECs over a tLDP session.
また、tLDPアプリケーションはLDP FEC要素タイプにマップされ、特定のアプリケーションFECのみをアドバタイズし、tLDPセッションで他の不要なFECのアドバタイズを回避します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
In addition to the terminology defined in [RFC7473], this document uses the following terms:
[RFC7473]で定義されている用語に加えて、このドキュメントでは次の用語を使用しています。
tLDP : Targeted LDP TAC : Targeted Application Capability TAE : Targeted Application Element TA-Id : Targeted Application Identifier SAC : State Advertisement Control LSR : Label Switching Router mLDP : Multipoint LDP PQ node : Remote LFA next hops RSVP-TE : RSVP Traffic Engineering P2MP : Point-to-Multipoint PW : Pseudowire P2P-PW : Point-to-Point Pseudowire MP2MP : Multipoint-to-Multipoint HSMP LSP: Hub and Spoke Multipoint Label Switched Path LSP : Label Switched Path MP2P : Multipoint-to-Point MPT : Merge Point
tLDP：ターゲットLDP TAC：ターゲットアプリケーション機能TAE：ターゲットアプリケーション要素TA-Id：ターゲットアプリケーション識別子SAC：状態通知制御LSR：ラベルスイッチングルータmLDP：マルチポイントLDP PQノード：リモートLFAネクストホップRSVP-TE：RSVPトラフィックエンジニアリングP2MP ：ポイントツーマルチポイントPW：疑似配線P2P-PW：ポイントツーポイント疑似配線MP2MP：マルチポイントツーマルチポイントHSMP LSP：ハブアンドスポークマルチポイントラベルスイッチドパスLSP：ラベルスイッチドパスMP2P：マルチポイントツーポイントMPT：マージポイント
An LSR MAY advertise that it is capable of negotiating a tLDP application list over a tLDP session by using the capability advertisement as defined in [RFC5561] and encoded as follows:
LSRは、[RFC5561]で定義され、次のようにエンコードされた機能アドバタイズメントを使用して、tLDPセッションを介してtLDPアプリケーションリストをネゴシエートできることをアドバタイズできます（MAY）。
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| TLV Code Point | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |
+-+-+-+-+-+-+-+-+ Capability Data |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flag "U" MUST be set to 1 to indicate that this capability must be silently ignored if unknown. The TAC's Capability Data field contains the Targeted Application Element (TAE) information, encoded as follows:
フラグ "U"を1に設定して、この機能が不明な場合は黙って無視する必要があることを示す必要があります。 TACの能力データフィールドには、次のようにエンコードされたターゲットアプリケーションエレメント（TAE）情報が含まれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TA-Id |E| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TA-Id: A 16-bit Targeted Application Identifier value.
TA-Id：16ビットのターゲットアプリケーションID値。
E: E-bit (Enable bit). Indicates whether the sender is advertising or withdrawing the TAE. The E-bit value is used as follows:
E：Eビット（ビットを有効にする）。送信者がTAEをアドバタイズしているか、取り下げているかを示します。 Eビット値は次のように使用されます。
1 - The TAE is advertising the targeted application. 0 - The TAE is withdrawing the targeted application.
1-TAEはターゲットアプリケーションを宣伝しています。 0-TAEはターゲットアプリケーションを撤回しています。
At tLDP session establishment time, an LSR MAY include a new capability TLV, the TAC TLV, as an optional TLV in the LDP Initialization message. The TAC TLV's Capability data MAY consist of zero or more TAEs, each pertaining to a unique TA-Id that an LSR supports over the session. If the receiver LSR receives the same TA-Id in more than one TAE, it MUST process the first element and ignore the duplicate elements. If the receiver LSR receives an unknown TA-Id in the TAE, it MUST silently ignore such a TAE and continue processing the rest of the TLV.
tLDPセッションの確立時に、LSRは、LDP初期化メッセージのオプションのTLVとして、新しい機能TLV、TAC TLVを含めることができます（MAY）。 TAC TLVの機能データは、ゼロ個以上のTAEで構成されている場合があり、それぞれがLSRがセッションでサポートする一意のTA-Idに関連しています。レシーバーLSRが複数のTAEで同じTA-Idを受信する場合、最初の要素を処理し、重複する要素を無視する必要があります。レシーバーLSRがTAEで不明なTA-Idを受信した場合、そのようなTAEを黙って無視し、残りのTLVの処理を続行する必要があります。
If the receiver LSR does not receive the TAC TLV in the Initialization message or it does not understand the TAC TLV, the TAC negotiation is considered unsuccessful and the session establishment proceeds as per [RFC5036]. On receipt of a valid TAC TLV, an LSR MUST generate its own TAC TLV with TAEs consisting of unique TA-Ids that it supports over the tLDP session. If there is at least one common TAE between the TAC TLV it has received and its own, the session MUST proceed to establishment as per [RFC5036]. If not, an LSR MUST send a 'Session Rejected/Targeted Application Capability Mismatch' Notification message to the peer and close the session. The initiating LSR SHOULD tear down the corresponding tLDP adjacency after sending or receiving a 'Session Rejected/Targeted Application Capability Mismatch' Notification message to or from the responding LSR, respectively.
レシーバLSRが初期化メッセージでTAC TLVを受信しないか、TAC TLVを理解しない場合、TACネゴシエーションは失敗したと見なされ、セッションの確立は[RFC5036]に従って進行します。 LSRは、有効なTAC TLVを受信すると、tLDPセッションでサポートする一意のTA-Idで構成されるTAEを含む独自のTAC TLVを生成する必要があります。受信したTAC TLVとそれ自身のTAEの間に少なくとも1つの共通のTAEがある場合、セッションは[RFC5036]に従って確立に進む必要があります。そうでない場合、LSRは 'Session Rejected / Targeted Application Capability Mismatch'通知メッセージをピアに送信してセッションを閉じる必要があります。開始LSRは、対応するtLDP隣接関係を、応答するLSRとの間でそれぞれ「セッション拒否/ターゲットアプリケーション機能の不一致」通知メッセージを送信または受信した後に破棄する必要があります（SHOULD）。
If both of the peers support the TAC TLV, an LSR decides to establish or close a tLDP session based on the negotiated list of targeted applications. For example, an initiating LSR advertises A, B, and C as TA-Ids, and the responding LSR advertises C, D, and E as TA-Ids. Then, the negotiated TA-Id as per both LSRs is C. In another example, an initiating LSR advertises A, B, and C as TA-Ids, and the responding LSR, which acts as a passive LSR, advertises all of the applications -- A, B, C, D, and E -- as TA-Ids that it supports over this session. The negotiated targeted applications as per both LSRs are then A, B, and C. Finally, if the initiating LSR advertises A, B, and C as TA-Ids and the responding LSR advertises D and E as TA-Ids, then the negotiated targeted applications as per both LSRs are "none". Therefore, if the intersection of the sets of received and sent TA-Ids is null, then the LSR sends a 'Session Rejected/Targeted Application Capability Mismatch' Notification message to the peer LSR and closes the session.
両方のピアがTAC TLVをサポートしている場合、LSRは、ターゲットアプリケーションのネゴシエートされたリストに基づいて、tLDPセッションを確立または閉じることを決定します。たとえば、開始LSRはA、B、CをTA-Idとしてアドバタイズし、応答するLSRはC、D、EをTA-Idとしてアドバタイズします。次に、両方のLSRごとにネゴシエートされたTA-IdはCです。別の例では、開始LSRがA、B、CをTA-Idとしてアドバタイズし、パッシブLSRとして機能する応答LSRがすべてのアプリケーションをアドバタイズします。 -A、B、C、D、およびE-このセッションでサポートされるTA-Idとして。両方のLSRに従ってネゴシエートされたターゲットアプリケーションはA、B、Cです。最後に、開始LSRがA、B、CをTA-Idとしてアドバタイズし、応答するLSRがDおよびEをTA-Idとしてアドバタイズすると、ネゴシエーションされます。両方のLSRによるターゲットアプリケーションは「なし」です。したがって、送受信されたTA-Idのセットの共通部分がnullの場合、LSRは「Session Rejected / Targeted Application Capability Mismatch」通知メッセージをピアLSRに送信し、セッションを閉じます。
When the responding LSR playing the active role [RFC5036] in LDP session establishment receives a 'Session Rejected/Targeted Application Capability Mismatch' Notification message, it MUST set its session setup retry interval to a maximum value -- that is, 0xFFFF. The session MAY stay in a non-existent state. When it detects a change in the initiating LSR or local LSR configuration pertaining to the TAC TLV, it MUST clear the session setup backoff delay associated with the session to reattempt session establishment. An LSR detects the configuration change on the other LSR upon receipt of a tLDP Hello message that has a higher configuration sequence number than the earlier tLDP Hello message.
LDPセッションの確立でアクティブな役割を果たしている応答LSR [RFC5036]が「セッション拒否/ターゲットアプリケーション機能の不一致」通知メッセージを受信した場合、セッションセットアップの再試行間隔を最大値、つまり0xFFFFに設定する必要があります。セッションは存在しない状態のままになる場合があります。 TAC TLVに関連する開始LSRまたはローカルLSR構成の変更を検出すると、セッションに関連するセッションセットアップバックオフ遅延をクリアして、セッション確立を再試行する必要があります。 LSRは、以前のtLDP Helloメッセージよりも構成シーケンス番号が大きいtLDP Helloメッセージを受信すると、他のLSRの構成変更を検出します。
When the initiating LSR playing the active role in LDP session establishment receives a 'Session Rejected/Targeted Application Capability Mismatch' Notification message, it MUST either (1) close the session and tear down the corresponding tLDP adjacency or (2) set its session setup retry interval to a maximum value -- that is, 0xFFFF.
LDPセッション確立でアクティブな役割を果たしている開始LSRが「セッション拒否/ターゲットアプリケーション機能の不一致」通知メッセージを受信すると、（1）セッションを閉じて、対応するtLDP隣接関係を破棄するか、（2）セッションセットアップを設定する必要があります。最大値、つまり0xFFFFまでの間隔を再試行します。
If the initiating LSR decides to tear down the associated tLDP adjacency, the session is closed on the initiating LSR as well as the responding LSR. It MAY also take appropriate actions. For instance, if an automatic session intended to support the remote LFA application is rejected by the responding LSR, the initiating LSR may inform the IGP to calculate another PQ node [RFC7490] for the route or set of routes. More specific actions are a local matter and are outside the scope of this document.
開始LSRが関連するtLDP隣接関係を破棄することを決定した場合、セッションは開始LSRと応答LSRで閉じられます。また、適切なアクションを実行する場合があります。たとえば、リモートLFAアプリケーションをサポートすることを目的とした自動セッションが応答するLSRによって拒否された場合、開始LSRはIGPにルートまたはルートセットの別のPQノード[RFC7490]を計算するよう通知する場合があります。より具体的なアクションはローカルな問題であり、このドキュメントの範囲外です。
If the initiating LSR sets the session setup retry interval to maximum, the session MAY stay in a non-existent state. When this LSR detects a change in the responding LSR configuration or its own configuration pertaining to the TAC TLV, it MUST clear the session setup backoff delay associated with the session in order to reattempt session establishment.
開始LSRがセッションセットアップの再試行間隔を最大に設定すると、セッションは存在しない状態のままになる場合があります。このLSRが、応答するLSR構成またはTAC TLVに関連する独自の構成の変更を検出すると、セッションの確立を再試行するために、セッションに関連付けられたセッションセットアップバックオフ遅延をクリアする必要があります。
After a tLDP session using the TAC mechanism has been established, the initiating and responding LSRs MUST distribute FEC label bindings for the negotiated applications only. For instance, if the tLDP session is established for a BGP auto-discovered pseudowire, only FEC 129 label bindings MUST be distributed over the session. Similarly, an LSR operating in downstream on-demand mode MUST request FEC label bindings for the negotiated applications only.
TACメカニズムを使用するtLDPセッションが確立された後、開始および応答LSRは、ネゴシエートされたアプリケーションに対してのみFECラベルバインディングを配布する必要があります。たとえば、tLDPセッションがBGP自動検出された疑似配線に対して確立されている場合、FEC 129ラベルバインディングのみがセッションを介して配布される必要があります。同様に、ダウンストリームオンデマンドモードで動作するLSRは、ネゴシエートされたアプリケーションに対してのみFECラベルバインディングを要求する必要があります。
If the TAC and the Dynamic Capability [RFC5561] are negotiated during session initialization, the TAC MAY be renegotiated after session establishment by sending an updated TAC TLV in the LDP Capability message. The updated TAC TLV carries TA-Ids with an incremental update only. The updated TLV MUST consist of one or more TAEs with the E-bit set (1) or off (0), to advertise or withdraw the new application and the old application, respectively. This may lead to advertisements or withdrawals of certain types of FEC label bindings over the session or to teardown of the tLDP adjacency and, subsequently, the session.
TACと動的機能[RFC5561]がセッションの初期化中にネゴシエートされる場合、LDP機能メッセージで更新されたTAC TLVを送信することにより、セッションの確立後にTACを再ネゴシエートできます（MAY）。更新されたTAC TLVは、増分更新のみでTA-Idを伝達します。更新されたTLVは、新しいアプリケーションと古いアプリケーションをそれぞれアドバタイズまたは撤回するために、Eビットがセット（1）またはオフ（0）の1つ以上のTAEで構成する必要があります。これにより、セッションを介した特定のタイプのFECラベルバインディングのアドバタイズまたは撤回、またはtLDP隣接関係の破棄、そしてその後のセッションにつながる可能性があります。
The TAC is advertised on the tLDP session only. If the tLDP session changes to a link session, an LSR SHOULD withdraw it with the S-bit set to 0. Similarly, if the link session changes to tLDP, an LSR SHOULD advertise it via the Capability message. If the capability negotiation fails, this may lead to destruction of the tLDP session.
TACはtLDPセッションでのみアドバタイズされます。 tLDPセッションがリンクセッションに変更された場合、LSRは、Sビットを0に設定してセッションを撤回する必要があります。機能のネゴシエーションが失敗すると、tLDPセッションが破壊される可能性があります。
By default, an LSR SHOULD accept tLDP Hellos in order to then accept or reject the tLDP session based on the application information.
デフォルトでは、LSRはアプリケーション情報に基づいてtLDPセッションを受け入れるか拒否するために、tLDP Helloを受け入れる必要があります（SHOULD）。
In addition, an LSR SHOULD allow the configuration of any TA-Id in order to facilitate the use of private TA-Ids by a network operator.
さらに、LSRは、ネットワークオペレーターによるプライベートTA-Idの使用を容易にするために、任意のTA-Idの構成を許可する必要があります（SHOULD）。
1. The S-bit of the TAC TLV MUST be set to 1 to advertise the TAC and SHOULD be ignored on receipt, as described in [RFC5561].
1. [RFC5561]で説明されているように、TAC TLVのSビットを1に設定してTACをアドバタイズし、受信時に無視する必要があります（SHOULD）。
2. The E-bit of the TAE MUST be set to 1 to enable the targeted application and SHOULD be ignored on receipt.
2. ターゲットアプリケーションを有効にするには、TAEのEビットを1に設定する必要があり、受信時に無視する必要があります。
3. An LSR MAY add the State Advertisement Control Capability by mapping the TAE to the State Advertisement Control (SAC) elements as defined in Section 4.
3. LSRは、セクション4で定義されているように、TAEをState Advertisement Control（SAC）要素にマッピングすることにより、State Advertisement Control Capabilityを追加してもよい（MAY）。
After a change to local configuration, the initiating or responding LSR may renegotiate the TAC via the Capability message.
ローカル構成への変更後、開始または応答するLSRは、機能メッセージを介してTACを再ネゴシエートする場合があります。
1. The S-bit of the TAC is set to 1 or 0 to advertise or withdraw it.
1. TACのSビットは1または0に設定され、アドバタイズまたは撤回されます。
2. After the configuration change, if there is no common TAE between its new TAE list and the peer's TAE list, the LSR MUST send a 'Session Rejected/Targeted Application Capability Mismatch' Notification message and close the session.
2. 構成変更後、新しいTAEリストとピアのTAEリストの間に共通のTAEがない場合、LSRは「セッション拒否/ターゲットアプリケーション機能の不一致」通知メッセージを送信してセッションを閉じる必要があります。
3. If there is a common TAE, an LSR MAY also update the SAC Capability based on the updated TAC, as described in Section 4, and send the updated TAC and SAC Capability in a Capability message to the peer.
3. 共通のTAEがある場合、セクション4で説明されているように、LSRは更新されたTACに基づいてSAC機能も更新し、更新されたTACおよびSAC機能を機能メッセージでピアに送信する場合があります。
4. A receiving LSR processes the Capability message with the TAC TLV. If the S-bit is set to 0, the TAC is disabled for the session.
4. 受信LSRは、TAC TLVで機能メッセージを処理します。 Sビットが0に設定されている場合、TACはセッションに対して無効になります。
5. If the S-bit is set to 1, the LSR processes a list of TAEs from the TAC's data with the E-bit set to 1 or 0 to update the peer's TAE.
5. Sビットが1に設定されている場合、LSRは、Eビットが1または0に設定されたTACのデータからのTAEのリストを処理して、ピアのTAEを更新します。
The tLDP application MUST be mapped to LDP FEC element types as follows to advertise only necessary LDP FEC label bindings over the tLDP session.
tLDPセッションで必要なLDP FECラベルバインディングのみをアドバタイズするには、次のようにtLDPアプリケーションをLDP FEC要素タイプにマップする必要があります。
Targeted Application Description FEC Mappings
+----------------------+------------------------+------------------+
|LDPv4 Tunneling | LDP IPv4 over RSVP-TE | IPv4 prefix |
| | or other MPLS tunnel | |
+----------------------+------------------------+------------------+
| | | |
|LDPv6 Tunneling | LDP IPv6 over RSVP-TE | IPv6 prefix |
| | or other MPLS tunnel | |
+----------------------+------------------------+------------------+
|mLDP Tunneling | mLDP over RSVP-TE or | P2MP |
| | other MPLS tunnel | MP2MP-up |
| | | MP2MP-down |
| | | HSMP-downstream |
| | | HSMP-upstream |
+----------------------+------------------------+------------------+
| | | |
|LDPv4 remote LFA | LDPv4 over LDPv4 or | IPv4 prefix |
| | other MPLS tunnel | |
+----------------------+------------------------+------------------+
|LDPv6 remote LFA | LDPv6 over LDPv6 or | IPv6 prefix |
| | other MPLS tunnel | |
+----------------------+------------------------+------------------+
| | | |
|LDP FEC 128 PW | LDP FEC 128 Pseudowire | PWid FEC element |
+----------------------+------------------------+------------------+
| | | |
|LDP FEC 129 PW | LDP FEC 129 Pseudowire | Generalized PWid |
| | | FEC element |
+----------------------+------------------------+------------------+
| | | FEC types as |
|LDP Session Protection| LDP session protection | per protected |
| | | session |
+----------------------+------------------------+------------------+
|LDP ICCP | LDP Inter-Chassis | |
| | Communication Protocol | None |
+----------------------+------------------------+------------------+
| | | |
|LDP P2MP PW | LDP P2MP Pseudowire | P2MP PW Upstream |
| | | FEC element |
+----------------------+------------------------+------------------+
| | | P2MP |
|mLDP Node Protection | mLDP node protection | MP2MP-up |
| | | MP2MP-down |
| | | HSMP-downstream |
| | | HSMP-upstream |
+----------------------+------------------------+------------------+
| | | |
|IPv4 intra-area FECs* | IPv4 intra-area FECs* | IPv4 prefix |
+----------------------+------------------------+------------------+
| | | |
|IPv6 intra-area FECs* | IPv6 intra-area FECs* | IPv6 prefix |
+----------------------+------------------------+------------------+
* Intra-area FECs: FECs that are on the shortest-path tree and are not leafs of the shortest-path tree.
* エリア内FEC：最短パスツリー上にあり、最短パスツリーのリーフではないFEC。
4. Interaction of Targeted Application Capabilities and State Advertisement Control Capabilities
4. ターゲットアプリケーション機能と状態アドバタイズメント制御機能の相互作用
As described in this document, the set of TAEs negotiated between two LDP peers advertising the TAC represents the willingness of both peers to advertise state information for a set of applications. The set of applications negotiated by the TAC mechanism is symmetric between the two LDP peers. In the absence of further mechanisms, two LDP peers will both advertise state information for the same set of applications.
このドキュメントで説明されているように、TACをアドバタイズする2つのLDPピア間でネゴシエートされるTAEのセットは、アプリケーションのセットの状態情報をアドバタイズする両方のピアの意欲を表します。 TACメカニズムによってネゴシエートされたアプリケーションのセットは、2つのLDPピア間で対称的です。それ以上のメカニズムがない場合、2つのLDPピアはどちらも同じアプリケーションセットの状態情報をアドバタイズします。
As described in [RFC7473], the SAC TLV can be used by an LDP speaker to communicate its interest or disinterest in receiving state information from a given peer for a particular application. Two LDP peers can use the SAC mechanism to create asymmetric advertisements of state information between the two peers.
[RFC7473]で説明されているように、LACスピーカーはSAC TLVを使用して、特定のアプリケーションの特定のピアから状態情報を受信することに関心があるか関心がないかを伝達できます。 2つのLDPピアはSACメカニズムを使用して、2つのピア間で状態情報の非対称アドバタイズを作成できます。
The TAC negotiation facilitates the awareness of targeted applications to both of the peers. It enables them to advertise only necessary LDP FEC label bindings corresponding to negotiated applications. With the SAC, the responding LSR is not aware of targeted applications. Thus, it may be unable to communicate its interest or disinterest in receiving state information from the peer. Therefore, when the responding LSR is not aware of targeted applications such as remote LFAs and BGP auto-discovered pseudowires, the TAC mechanism should be used, and when the responding LSR is aware (with appropriate configuration) of targeted applications such as FEC 128 pseudowire, the SAC mechanism should be used. Also, after the TAC mechanism makes the responding LSR aware of targeted applications, the SAC mechanism may be used to communicate its disinterest in receiving state information from the peer for a particular negotiated application, creating asymmetric advertisements.
TACネゴシエーションは、両方のピアに対するターゲットアプリケーションの認識を促進します。これにより、ネゴシエートされたアプリケーションに対応する必要なLDP FECラベルバインディングのみをアドバタイズできます。 SACを使用すると、応答するLSRはターゲットアプリケーションを認識しません。したがって、ピアから状態情報を受信することに関心や関心がないことを伝えることができない場合があります。したがって、応答するLSRがリモートLFAやBGP自動検出疑似配線などの対象アプリケーションを認識していない場合は、TACメカニズムを使用する必要があります。また、応答するLSRが（適切な構成で）FEC 128疑似配線などの対象アプリケーションを認識している場合は、 、SACメカニズムを使用する必要があります。また、TACメカニズムが応答するLSRにターゲットアプリケーションを認識させた後、SACメカニズムを使用して、ピアから特定のネゴシエートされたアプリケーションの状態情報を受信することに関心がないことを伝え、非対称のアドバタイズを作成できます。
Thus, the TAC mechanism enables two LDP peers to symmetrically advertise state information for negotiated targeted applications. Further, the SAC mechanism enables both of them to asymmetrically disable receipt of state information for some of the already-negotiated targeted applications. Collectively, the TAC mechanism and the SAC mechanism can both be used to control the FEC label bindings that are advertised over the tLDP session. For instance, suppose that the initiating LSR establishes a tLDP session, using the TAC mechanism, with the responding LSR for remote LFA and FEC 129 PW targeted applications. So, each LSR advertises the corresponding FEC label bindings. Further, suppose that the initiating LSR is not the PQ node for the responding LSR's remote LFA IGP calculations. In such a case, the responding LSR may use the SAC mechanism to convey its disinterest in receiving state information for remote LFA tLDP applications.
したがって、TACメカニズムにより、2つのLDPピアが、ネゴシエートされたターゲットアプリケーションの状態情報を対称的にアドバタイズできるようになります。さらに、SACメカニズムにより、すでにネゴシエートされた一部のターゲットアプリケーションの状態情報の受信を非対称に無効にすることができます。集合的に、TACメカニズムとSACメカニズムの両方を使用して、tLDPセッションでアドバタイズされるFECラベルバインディングを制御できます。たとえば、開始LSRが、リモートLFAおよびFEC 129 PWターゲットアプリケーションの応答LSRを使用して、TACメカニズムを使用してtLDPセッションを確立するとします。したがって、各LSRは対応するFECラベルバインディングをアドバタイズします。さらに、開始側のLSRが、応答するLSRのリモートLFA IGP計算のPQノードではないと仮定します。このような場合、応答するLSRはSACメカニズムを使用して、リモートLFA tLDPアプリケーションの状態情報を受信することに関心がないことを伝えます。
For a given tLDP session, the TAC mechanism can be used without the SAC mechanism, and the SAC mechanism can be used without the TAC mechanism. It is useful to discuss the behavior that occurs when the TAC and SAC mechanisms are used on the same tLDP session. The TAC mechanism MUST take precedence over the SAC mechanism with respect to enabling applications for which state information will be advertised. For a tLDP session using the TAC mechanism, the LDP peers MUST NOT advertise state information for an application that has not been negotiated in the most recent TAE list (referred to as a non-negotiated application). This is true even if one of the peers announces its interest in receiving state information that corresponds to the non-negotiated application by sending a SAC TLV. In other words, when the TAC mechanism is being used, the SAC mechanism cannot and should not enable state information advertisements for applications that have not been enabled by the TAC mechanism.
特定のtLDPセッションでは、TACメカニズムはSACメカニズムなしで使用でき、SACメカニズムはTACメカニズムなしで使用できます。同じtLDPセッションでTACメカニズムとSACメカニズムが使用されている場合に発生する動作について説明すると便利です。 TACメカニズムは、状態情報がアドバタイズされるアプリケーションの有効化に関して、SACメカニズムよりも優先する必要があります。 TACメカニズムを使用するtLDPセッションの場合、LDPピアは、最新のTAEリストでネゴシエートされていないアプリケーション（非ネゴシエートされたアプリケーションと呼ばれる）の状態情報を通知してはなりません（MUST NOT）。これは、ピアの1つがSAC TLVを送信することにより、ネゴシエーションされていないアプリケーションに対応する状態情報の受信への関心を発表した場合でも当てはまります。つまり、TACメカニズムが使用されている場合、SACメカニズムは、TACメカニズムによって有効にされていないアプリケーションの状態情報アドバタイズを有効にできません。
On the other hand, the SAC mechanism MUST take precedence over the TAC mechanism with respect to disabling state information advertisements. If an LDP speaker has announced its disinterest in receiving state information for a given application to a given peer using the SAC mechanism, its peer MUST NOT send state information for that application, even if the two peers have negotiated the corresponding application via the TAC mechanism.
一方、SACメカニズムは、状態情報アドバタイズを無効にすることに関して、TACメカニズムよりも優先する必要があります。 LDPスピーカーが、SACメカニズムを使用して、特定のアプリケーションの状態情報を特定のピアに受信することに関心がないことを発表した場合、2つのピアがTACメカニズムを介して対応するアプリケーションをネゴシエートしても、そのピアはそのアプリケーションの状態情報を送信してはなりません（MUST NOT）。 。
For the purposes of determining the correspondence between targeted applications defined in this document and application state as defined in [RFC7473], an LSR MUST use the following mappings:
このドキュメントで定義されている対象のアプリケーションと[RFC7473]で定義されているアプリケーションの状態との間の対応を決定するために、LSRは次のマッピングを使用する必要があります。
LDPv4 Tunneling - IPv4 Prefix-LSPs LDPv6 Tunneling - IPv6 Prefix-LSPs LDPv4 Remote LFA - IPv4 Prefix-LSPs LDPv6 Remote LFA - IPv6 Prefix-LSPs LDP FEC 128 PW - FEC 128 P2P-PW LDP FEC 129 PW - FEC 129 P2P-PW
LDPv4トンネリング-IPv4 Prefix-LSP LDPv6トンネリング-IPv6 Prefix-LSPs LDPv4リモートLFA-IPv4 Prefix-LSPs LDPv6リモートLFA-IPv6 Prefix-LSPs LDP FEC 128 PW-FEC 128 P2P-PW LDP FEC 129 PW-FECP 129 PW
An LSR MUST map the targeted application to the LDP capability as follows:
LSRは、次のようにターゲットアプリケーションをLDP機能にマップする必要があります。
mLDP Tunneling - P2MP Capability, MP2MP Capability, and HSMP LSP Capability TLV
mLDPトンネリング-P2MP機能、MP2MP機能、およびHSMP LSP機能TLV
mLDP Node Protection - P2MP Capability, MP2MP Capability, and HSMP LSP Capability TLV
mLDPノード保護-P2MP機能、MP2MP機能、およびHSMP LSP機能TLV
The LSR determines that it needs to form an automatic tLDP session with a remote LSR based on IGP calculation as described in [RFC7490] or some other mechanism outside the scope of this document. The LSR forms the tLDP adjacency and constructs an Initialization message with the TAC TLV consisting of the TAE as the remote LFA during session establishment. The receiver LSR processes the LDP Initialization message and verifies whether it is configured to accept a remote LFA tLDP session. If it is, it may further verify that establishing such a session does not exceed the configured limit for remote LFA sessions. If all of these conditions are met, the receiver LSR may respond back with an Initialization message with the TAC corresponding to the remote LFA, and subsequently the session may be established.
LSRは、[RFC7490]で説明されているIGP計算またはこのドキュメントの範囲外のその他のメカニズムに基づいて、リモートLSRとの自動tLDPセッションを形成する必要があると判断します。 LSRはtLDP隣接関係を形成し、セッション確立中にリモートLFAとしてTAEで構成されるTAC TLVで初期化メッセージを構築します。レシーバーLSRはLDP初期化メッセージを処理し、リモートLFA tLDPセッションを受け入れるように構成されているかどうかを確認します。そうである場合、そのようなセッションの確立がリモートLFAセッションに構成された制限を超えていないことをさらに検証する場合があります。これらの条件がすべて満たされている場合、レシーバーLSRは初期化メッセージでリモートLFAに対応するTACで応答し、その後セッションが確立されます。
After the session using the TAC mechanism has been established, the sender and receiver LSRs distribute IPv4 or IPv6 FEC label bindings over the session. Further, the receiver LSR may determine that it does not need these FEC label bindings. So, it may disable the receipt of these FEC label bindings by mapping the TAE to the State Advertisement Control Capability as described in Section 4.
TACメカニズムを使用するセッションが確立された後、送信側と受信側のLSRは、IPv4またはIPv6のFECラベルバインディングをセッションに配信します。さらに、受信機LSRは、これらのFECラベルバインディングが不要であると判断する場合があります。したがって、セクション4で説明されているように、TAEを状態通知制御機能にマッピングすることにより、これらのFECラベルバインディングの受信を無効にする場合があります。
BGP auto-discovery may determine whether the LSR needs to initiate an auto-discovery tLDP session with a border LSR. Multiple LSRs may try to form an auto-discovered tLDP session with a border LSR. So, a service provider may want to limit the number of auto-discovered tLDP sessions that a border LSR can accept. As described in Section 2, LDP may convey targeted applications with the TAC TLV to a border LSR. A border LSR may establish or reject the tLDP session based on local administrative policy. Also, as the receiver LSR becomes aware of targeted applications, it can also employ an administrative policy for security. For instance, it can employ a policy to accept all auto-discovered sessions from a source addresses list.
BGP自動検出は、LSRがボーダーLSRとの自動検出tLDPセッションを開始する必要があるかどうかを決定します。複数のLSRが、境界LSRとの自動検出されたtLDPセッションを形成しようとする場合があります。そのため、サービスプロバイダーは、ボーダーLSRが受け入れることができる自動検出されたtLDPセッションの数を制限したい場合があります。セクション2で説明したように、LDPは、ターゲットアプリケーションをTAC TLVとともに境界LSRに伝達できます。ボーダーLSRは、ローカルの管理ポリシーに基づいてtLDPセッションを確立または拒否できます。また、受信側のLSRがターゲットアプリケーションを認識するようになると、セキュリティのための管理ポリシーを採用することもできます。たとえば、ポリシーを使用して、送信元アドレスリストから自動検出されたすべてのセッションを受け入れることができます。
Moreover, the sender and receiver LSRs must exchange FEC 129 label bindings only over the tLDP session.
さらに、送信側と受信側のLSRは、tLDPセッションでのみFEC 129ラベルバインディングを交換する必要があります。
An LSR may want to establish a tLDP session with a remote LSR for LDP-over-RSVP tunneling and remote LFA applications. The sender LSR may add both of these applications as a unique TAE in the TAC data of a TAC TLV. The receiver LSR may have reached a configured limit for accepting remote LFA automatic tLDP sessions, but it may have been configured to accept LDP-over-RSVP tunneling. In such a case, the tLDP session is formed for both LDP-over-RSVP tunneling and remote LFA applications, as both need the same FECs -- IPv4, IPv6, or both.
LSRは、LDP-over-RSVPトンネリングおよびリモートLFAアプリケーションのために、リモートLSRとのtLDPセッションを確立したい場合があります。送信側LSRは、これらのアプリケーションの両方をTAC TLVのTACデータに一意のTAEとして追加できます。レシーバーLSRは、リモートLFA自動tLDPセッションを受け入れるように構成された制限に達した可能性がありますが、LDP-over-RSVPトンネリングを受け入れるように構成された可能性があります。そのような場合、両方が同じFEC（IPv4、IPv6、または両方）を必要とするため、LDP-over-RSVPトンネリングとリモートLFAアプリケーションの両方に対してtLDPセッションが形成されます。
A Merge Point (MPT) LSR may determine that it needs to form an automatic tLDP session with the upstream point of local repair (PLR) LSR for MP2P and MP2MP LSP [RFC6388] node protection as described in [RFC7715]. The MPT LSR may add a new tLDP application -- mLDP protection -- as a unique TAE in the TAC data of a TAC TLV and send it in the Initialization message to the PLR. If the PLR is configured for mLDP node protection and establishing this session does not exceed the limit of either mLDP node protection sessions or automatic tLDP sessions, the PLR may decide to accept this session. Also, the PLR may respond back with the Initialization message with a TAC TLV that has one of the TAEs as mLDP protection, and the session proceeds to establishment as per [RFC5036].
マージポイント（MPT）LSRは、[RFC7715]で説明されているように、MP2PおよびMP2MP LSP [RFC6388]ノード保護のローカル修復（PLR）LSRのアップストリームポイントとの自動tLDPセッションを形成する必要があると判断する場合があります。 MPT LSRは、新しいtLDPアプリケーション（mLDP保護）をTAC TLVのTACデータ内の一意のTAEとして追加し、初期化メッセージでPLRに送信します。 PLRがmLDPノード保護用に構成され、このセッションの確立がmLDPノード保護セッションまたは自動tLDPセッションの制限を超えない場合、PLRはこのセッションを受け入れることを決定する場合があります。また、PLRは、初期化メッセージで、TAEの1つをmLDP保護として持つTAC TLVを使用して応答する場合があり、セッションは[RFC5036]に従って確立に進みます。
The procedures described in this document do not introduce any changes to LDP security considerations as described in [RFC5036].
このドキュメントで説明されている手順では、[RFC5036]で説明されているLDPセキュリティの考慮事項に変更は導入されていません。
As described in [RFC5036], DoS attacks via Extended Hellos, which are required to establish a tLDP session, can be addressed by filtering Extended Hellos using access lists that define addresses with which Extended Discovery is permitted. Further, as described in Section 5.2 of this document, an LSR can employ a policy to accept all auto-discovered Extended Hellos from the configured source addresses list.
[RFC5036]で説明されているように、tLDPセッションの確立に必要なExtended Helloを介したDoS攻撃は、Extended Discoveryを許可するアドレスを定義するアクセスリストを使用してExtended Helloをフィルタリングすることで対処できます。さらに、このドキュメントのセクション5.2で説明されているように、LSRはポリシーを使用して、構成された送信元アドレスリストから自動検出されたすべての拡張Helloを受け入れることができます。
Also, for the two LSRs supporting the TAC, the tLDP session is only established after successful negotiation of the TAC. The initiating and receiving LSRs MUST only advertise TA-Ids that they support -- in other words, what they are configured for over the tLDP session.
また、TACをサポートする2つのLSRの場合、tLDPセッションは、TACのネゴシエーションが成功した後にのみ確立されます。開始および受信LSRは、それらがサポートするTA-Idのみ、つまり、tLDPセッションで何が構成されているかを通知する必要があります。
IANA has assigned the following code point for the new Capability Parameter TLV defined in this document. The code point has been assigned from the "TLV Type Name Space" sub-registry of the "Label Distribution Protocol (LDP) Parameters" registry.
IANAは、このドキュメントで定義されている新しい機能パラメータTLVに次のコードポイントを割り当てました。コードポイントは、「Label Distribution Protocol（LDP）Parameters」レジストリの「TLV Type Name Space」サブレジストリから割り当てられています。
Value Description Reference
------ ------------------------------- ---------
0x050F Targeted Application Capability RFC 8223
IANA has assigned a new status code from the "Status Code Name Space" sub-registry of the "Label Distribution Protocol (LDP) Parameters" registry.
IANAは、「Label Distribution Protocol（LDP）Parameters」レジストリの「Status Code Name Space」サブレジストリから新しいステータスコードを割り当てました。
Value E Description Reference
---------- --- ----------------------------------- ---------
0x0000004C 1 Session Rejected/Targeted
Application Capability Mismatch RFC 8223
IANA has created a new registry called "LDP Targeted Application Identifier" in the "Label Distribution Protocol (LDP) Parameters" registry. The range is 0x0001-0xFFFE. Values in the range 0x0001-0x1FFF in this registry shall be allocated according to the "IETF Review" procedure [RFC8126]; values in the range 0x2000-0xF7FF shall be allocated according to the "First Come First Served" procedure [RFC8126]. The initial values are as follows.
IANAは、「Label Distribution Protocol（LDP）Parameters」レジストリに「LDP Targeted Application Identifier」と呼ばれる新しいレジストリを作成しました。範囲は0x0001-0xFFFEです。このレジストリの0x0001-0x1FFFの範囲の値は、「IETFレビュー」手順[RFC8126]に従って割り当てられます。 0x2000-0xF7FFの範囲の値は、「先着順」手順[RFC8126]に従って割り当てられます。初期値は以下の通りです。
Value Description Reference
--------------- ------------------------------- ---------
0x0000 Reserved RFC 8223
0x0001 LDPv4 Tunneling RFC 8223
0x0002 LDPv6 Tunneling RFC 8223
0x0003 mLDP Tunneling RFC 8223
0x0004 LDPv4 Remote LFA RFC 8223
0x0005 LDPv6 Remote LFA RFC 8223
0x0006 LDP FEC 128 PW RFC 8223
0x0007 LDP FEC 129 PW RFC 8223
0x0008 LDP Session Protection RFC 8223
0x0009 LDP ICCP RFC 8223
0x000A LDP P2MP PW RFC 8223
0x000B mLDP Node Protection RFC 8223
0x000C LDPv4 Intra-area FECs RFC 8223
0x000D LDPv6 Intra-area FECs RFC 8223
0x000E-0xF7FF Unassigned
0xF800-0xFBFF Available for Private Use
0xFC00-0xFFFE Available for Experimental Use
0xFFFF Reserved RFC 8223
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、DOI 10.17487 / RFC5036、October 2007、<https：// www。 rfc-editor.org/info/rfc5036>。
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, DOI 10.17487/RFC5561, July 2009, <https://www.rfc-editor.org/info/rfc5561>.
[RFC5561]トーマス、B。、ラザ、K。、アガーワル、S。、アガーワル、R。、およびJL。 Le Roux、「LDP Capabilities」、RFC 5561、DOI 10.17487 / RFC5561、2009年7月、<https://www.rfc-editor.org/info/rfc5561>。
[RFC7473] Raza, K. and S. Boutros, "Controlling State Advertisements of Non-negotiated LDP Applications", RFC 7473, DOI 10.17487/RFC7473, March 2015, <https://www.rfc-editor.org/info/rfc7473>.
[RFC7473] Raza、K。およびS. Boutros、「Controlling State Advertisements of Non-negotiated LDP Applications」、RFC 7473、DOI 10.17487 / RFC7473、2015年3月、<https://www.rfc-editor.org/info/ rfc7473>。
[RFC7715] Wijnands, IJ., Ed., Raza, K., Atlas, A., Tantsura, J., and Q. Zhao, "Multipoint LDP (mLDP) Node Protection", RFC 7715, DOI 10.17487/RFC7715, January 2016, <https://www.rfc-editor.org/info/rfc7715>.
[RFC7715] Wijnands、IJ。、Ed。、Raza、K.、Atlas、A.、Tantsura、J。、およびQ. Zhao、「Multipoint LDP（mLDP）Node Protection」、RFC 7715、DOI 10.17487 / RFC7715、January 2016、<https://www.rfc-editor.org/info/rfc7715>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011, <https://www.rfc-editor.org/info/rfc6074>.
[RFC6074]ローゼン、E。、デイビー、B。、ラドアカ、V。、およびW.ルオ、「プロビジョニング、自動検出、およびレイヤー2仮想プライベートネットワーク（L2VPN）でのシグナリング」、RFC 6074、DOI 10.17487 / RFC6074 、2011年1月、<https://www.rfc-editor.org/info/rfc6074>。
[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, DOI 10.17487/RFC6388, November 2011, <https://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、DOI 10.17487 / RFC6388、2011年11月、<https://www.rfc-editor.org/info/rfc6388>。
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, DOI 10.17487/RFC7490, April 2015, <https://www.rfc-editor.org/info/rfc7490>.
[RFC7490]ブライアント、S。、フィルスフィルス、C。、プレビディ、S。、シャンド、M。、およびN.したがって、「リモートループフリー代替（LFA）高速再ルーティング（FRR）」、RFC 7490、DOI 10.17487 / RFC7490、2015年4月、<https://www.rfc-editor.org/info/rfc7490>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
Acknowledgments
謝辞
The authors wish to thank Nischal Sheth, Hassan Hosseini, Kishore Tiruveedhula, Loa Andersson, Eric Rosen, Yakov Rekhter, Thomas Beckhaus, Tarek Saad, Lizhong Jin, and Bruno Decraene for their detailed reviews. Thanks to Manish Gupta and Martin Ehlers for their input to this work and many helpful suggestions.
著者は、詳細なレビューを提供してくれたNischal Sheth、Hassan Hosseini、Kishore Tiruveedhula、Loa Andersson、Eric Rosen、Yakov Rekhter、Thomas Beckhaus、Tarek Saad、Lizhong Jin、およびBruno Decraeneに感謝します。この作業へのインプットと多くの役立つ提案をしてくれたManish GuptaとMartin Ehlersに感謝します。
Contributors
貢献者
The following people contributed substantially to the content of this document and should be considered co-authors:
次の人々はこのドキュメントの内容に実質的に貢献し、共著者と見なされるべきです：
Chris Bowers Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America Email: cbowers@juniper.net
Chris Bowers Juniper Networks 1133 Innovation Way Sunnyvale、CA 94089アメリカ合衆国メール：cbowers@juniper.net
Zhenbin Li Huawei Bldg. No. 156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com
Zは非常にビンl IH UAはビル番号156はiqing RDです。北京100095中国のメール：李振彬@ Huawei.com
Authors' Addresses
著者のアドレス
Santosh Esale Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America
Santosh Esale Juniper Networks 1133 Innovation Way Sunnyvale、CA 94089アメリカ合衆国
Email: sesale@juniper.net
Raveendra Torvi Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States of America
Raveendra Torvi Juniper Networks 10 Technology Park Drive Westford、MA 01886アメリカ合衆国
Email: rtorvi@juniper.net
Luay Jalil Verizon 1201 East Arapaho Road Richardson, TX 75081 United States of America
Luay Jalil Verizon 1201 East Arapaho Road Richardson、TX 75081アメリカ合衆国
Email: luay.jalil@verizon.com
Uma Chunduri Huawei 2330 Central Expressway Santa Clara, CA 95050 United States of America
Uma Chunduri Huawei 2330 Central Expressway Santa Clara、CA 95050アメリカ合衆国
Email: uma.chunduri@huawei.com
Kamran Raza Cisco Systems, Inc. 2000 Innovation Drive Ottawa, ON K2K-3E8 Canada
Kamran Raza Cisco Systems、Inc. 2000 Innovation Drive Ottawa、ON K2K-3E8 Canada
Email: skraza@cisco.com