[要約] RFC 5561は、Label Distribution Protocol（LDP）の機能とその目的について説明しています。LDPは、MPLSネットワークでラベルの配布と制御を行うためのプロトコルです。このRFCは、LDPの機能とその利点を理解するためのガイドラインを提供しています。
Network Working Group B. Thomas
Request for Comments: 5561 K. Raza
Updates: 5036 Cisco Systems, Inc.
Category: Standards Track S. Aggarwal
R. Aggarwal
Juniper Networks
JL. Le Roux
France Telecom
July 2009
LDP Capabilities
LDP機能
Abstract
概要
A number of enhancements to the Label Distribution Protocol (LDP) have been proposed. Some have been implemented, and some are advancing toward standardization. It is likely that additional enhancements will be proposed in the future. This document defines a mechanism for advertising LDP enhancements at session initialization time, as well as a mechanism to enable and disable enhancements after LDP session establishment.
ラベル分布プロトコル（LDP）の多くの拡張機能が提案されています。いくつかは実装されており、一部は標準化に向けて前進しています。将来、追加の機能強化が提案される可能性があります。このドキュメントでは、セッションの初期化時間にLDPの拡張を広告するためのメカニズムと、LDPセッションの確立後に強化を有効にして無効にするメカニズムを定義します。
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. The LDP Capability Mechanism ....................................3
2.1. Capability Document ........................................4
3. Specifying Capabilities in LDP Messages .........................4
3.1. Backward Compatibility TLVs ................................6
4. Capability Message ..............................................6
5. Note on Terminology .............................................7
6. Procedures for Capability Parameters in Initialization
Messages ........................................................7
7. Procedures for Capability Parameters in Capability Messages .....8
8. Extensions to Error Handling ....................................9
9. Dynamic Capability Announcement TLV .............................9
10. Backward Compatibility ........................................10
11. Security Considerations .......................................10
12. IANA Considerations ...........................................11
13. Acknowledgments ...............................................11
14. References ....................................................11
14.1. Normative References .....................................11
14.2. Informative References ...................................11
A number of enhancements to LDP as specified in [RFC5036] have been proposed. These include LDP Graceful Restart [RFC3478], Fault Tolerant LDP [RFC3479], multicast extensions [MLDP], signaling for Layer 2 circuits [RFC4447], a method for learning labels advertised by next-next-hop routers in support of fast reroute node protection [NNHOP], upstream label allocation [UPSTREAM_LDP], and extensions for signaling inter-area Label Switched Paths (LSPs) [RFC5283]. Some have been implemented, and some are advancing toward standardization. It is also likely that additional enhancements will be implemented and deployed in the future.
[RFC5036]で指定されているLDPの多くの強化が提案されています。これらには、LDP Graceful Restart [RFC3478]、フォールトトレラントLDP [RFC3479]、マルチキャストエクステンション[MLDP]、レイヤー2回路[RFC4447]のシグナリング、Fast Reroute Node Nodeをサポートする次ネックスホップルーターによって宣伝されているラベルが宣伝されているラベルを学習する方法が含まれます。保護[nnhop]、上流のラベル割り当て[upstream_ldp]、およびシグナリング間領域ラベルスイッチ付きパス（LSP）[RFC5283]の拡張。いくつかは実装されており、一部は標準化に向けて前進しています。また、追加の拡張機能が将来実装および展開される可能性があります。
This document proposes and defines a mechanism for advertising LDP enhancements at session initialization time. It also defines a mechanism to enable and disable these enhancements after LDP session establishment.
このドキュメントは、セッションの初期化時間にLDPの拡張を広告するためのメカニズムを提案および定義します。また、LDPセッションの確立後にこれらの拡張機能を有効にして無効にするメカニズムを定義します。
LDP capability advertisement provides means for an LDP speaker to announce what it can receive and process. It also provides means for a speaker to inform peers of deviations from behavior specified by [RFC5036]. An example of such a deviation is LDP Graceful Restart, where a speaker retains MPLS forwarding state for LDP-signaled LSPs when its LDP control plane goes down. It is important to point out that not all LDP enhancements require capability advertisement. For example, upstream label allocation requires capability advertisement, but inbound label filtering, where a speaker installs forwarding state for only certain Forwarding Equivalence Classes (FECs), does not.
LDP機能広告は、LDPスピーカーが受け取って処理できるものを発表する手段を提供します。また、スピーカーが[RFC5036]によって指定された行動からの逸脱を仲間に通知する手段も提供します。このような偏差の例は、LDPの優雅な再起動です。この場合、スピーカーはLDPコントロールプレーンがダウンするとLDP署名LSPのMPLS転送状態を保持します。すべてのLDP強化が機能広告を必要とするわけではないことを指摘することが重要です。たとえば、上流のラベル割り当てには機能広告が必要ですが、スピーカーが特定の転送等価クラス（FEC）のみに転送状態をインストールするインバウンドラベルフィルタリングは必要ありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This document uses the terms "LDP speaker" and "speaker" interchangeably.
このドキュメントでは、「LDPスピーカー」と「スピーカー」という用語を交換可能に使用します。
Enhancements are likely to be announced during LDP session establishment as each LDP speaker advertises capabilities corresponding to the enhancements it desires.
各LDPスピーカーは、それが望む拡張機能に対応する機能を宣伝するため、LDPセッションの確立中に拡張機能が発表される可能性があります。
Beyond that, capability advertisements may be used to dynamically modify the characteristics of the session to suit the changing conditions. For example, an LSR capable of a particular enhancement in support of some "feature" may not have advertised the corresponding capability to its peers at session establishment time because the feature was disabled at that time. Later, an operator may enable the feature, at which time the LSR would react by advertising the corresponding capability to its peers. Similarly, when an operator disables a feature associated with a capability, the LSR reacts by withdrawing the capability advertisement from its peers.
それを超えて、機能広告を使用して、セッションの特性を動的に変更して、変化する条件に合わせてください。たとえば、いくつかの「機能」をサポートする特定の強化が可能なLSRは、その時点で機能が無効になっていたため、セッションの確立時間に同僚に対応する機能を宣伝していない場合があります。その後、オペレーターが機能を有効にする場合があります。その時点で、LSRは、同僚に対応する機能を宣伝することで反応します。同様に、オペレーターが機能に関連する機能を無効にすると、LSRは同僚から機能広告を撤回することで反応します。
The LDP capability advertisement mechanism operates as follows:
LDP機能広告メカニズムは次のように動作します。
- Each LDP speaker is assumed to implement a set of enhancements, each of which has an associated capability. At any time, a speaker may have none, one, or more of those enhancements "enabled". When an enhancement is enabled, the speaker advertises the associated capability to its peers. By advertising the capability to a peer, the speaker asserts that it shall perform the protocol actions specified for the associated enhancement. For example, the actions may require the LDP speaker to receive and process enhancement-specific messages from its peer. Unless the capability has been advertised, the speaker will not perform protocol actions specified for the corresponding enhancement.
- 各LDPスピーカーは、一連の拡張機能を実装すると想定されており、それぞれに関連する機能があります。いつでも、スピーカーには、これらの機能強化が「有効」されていない、またはそれ以上のスピーカーにはありません。強化が有効になっている場合、スピーカーは同僚に関連する機能を宣伝します。スピーカーは、ピアに機能を宣伝することにより、関連する強化に対して指定されたプロトコルアクションを実行すると主張します。たとえば、アクションでは、LDPスピーカーがピアから強化固有のメッセージを受信および処理する必要がある場合があります。機能が宣伝されていない限り、スピーカーは対応する拡張に指定されたプロトコルアクションを実行しません。
- At session establishment time, an LDP speaker MAY advertise a particular capability by including an optional parameter associated with the capability in its Initialization message.
- セッションの確立時間に、LDPスピーカーは、初期化メッセージの機能に関連付けられたオプションのパラメーターを含めることにより、特定の機能を宣伝する場合があります。
- There is a well-known capability called Dynamic Capability Announcement that an LDP speaker MAY advertise in its Initialization message to indicate that it is capable of processing capability announcements following a session establishment.
- LDPスピーカーが初期化メッセージで宣伝して、セッション施設に続いて能力アナウンスを処理できることを示すことができるというダイナミック機能アナウンスと呼ばれる有名な機能があります。
If a peer had advertised the Dynamic Capability Announcement capability in its Initialization message, then at any time following session establishment, an LDP speaker MAY announce changes in its advertised capabilities to that peer. To do this, the LDP speaker sends the peer a Capability message that specifies the capabilities being advertised or withdrawn.
ピアが初期化メッセージで動的能力アナウンス機能を宣伝していた場合、セッションの設立後いつでもLDPスピーカーがそのピアに宣伝された機能の変更を発表することができます。これを行うために、LDPスピーカーは、宣伝または撤回されている機能を指定する機能をピアに送信します。
When the capability advertisement mechanism is in place, an LDP enhancement requiring LDP capability advertisement will be specified by a document that:
機能広告メカニズムが導入されている場合、LDP機能広告を必要とするLDP強化が、次のドキュメントによって指定されます。
- Describes the motivation for the enhancement;
- 強化の動機について説明します。
- Specifies the behavior of LDP when the enhancement is enabled. This includes the procedures, parameters, messages, and TLVs required by the enhancement;
- 強化が有効になっているときにLDPの動作を指定します。これには、強化に必要な手順、パラメーター、メッセージ、およびTLVが含まれます。
- Includes an IANA considerations section that requests IANA assignment of a code point (from TLV Type namespace) for the optional capability parameter corresponding to the enhancement.
- 強化に対応するオプションの機能パラメーターに対して、コードポイント（TLVタイプ名空間から）のIANA割り当てを要求するIANAの考慮事項セクションが含まれています。
The capability document MUST also describe the interpretation and processing of associated capability data, if present.
機能ドキュメントは、存在する場合は、関連する機能データの解釈と処理も記述する必要があります。
This document uses the term "Capability Parameter" to refer to an optional parameter that may be included in Initialization and Capability messages to advertise a capability.
このドキュメントでは、「機能パラメーター」という用語を使用して、初期化と機能メッセージに含まれるオプションのパラメーターを参照して、機能を宣伝します。
The format of a "Capability Parameter" TLV is as follows:
「機能パラメーター」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| TLV Code Point | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |
+-+-+-+-+-+-+-+-+ Capability Data |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
U-bit: Unknown TLV bit, as described in [RFC5036]. The value could be either 0 or 1 as specified in the Capability document associated with the given capability.
Uビット：[RFC5036]で説明されているように、不明なTLVビット。値は、指定された機能に関連付けられた機能ドキュメントで指定されている0または1のいずれかである可能性があります。
F-bit: Forward unknown TLV bit, as described in [RFC5036]. The value of this bit MUST be 0 since a Capability Parameter TLV is sent only in Initialization and Capability messages, which are not forwarded.
f-bit：[RFC5036]で説明されているように、フォワード不明のTLVビット。機能パラメーターTLVは、転送されていない初期化と機能メッセージでのみ送信されるため、このビットの値は0でなければなりません。
TLV Code Point: The TLV type that identifies a specific capability. This is an IANA-assigned code point (from TLV Type namespace) for a given capability as requested in the associated capability document.
TLVコードポイント：特定の機能を識別するTLVタイプ。これは、関連する機能ドキュメントで要求されている特定の機能のIANAが割り当てられたコードポイント（TLVタイプ名空間から）です。
S-bit: The State Bit. It indicates whether the sender is advertising or withdrawing the capability corresponding to the TLV code point. The State Bit value is used as follows:
s-bit：状態ビット。これは、送信者が広告しているのか、TLVコードポイントに対応する機能を撤回しているのかを示します。状態ビット値は次のように使用されます。
1 - The TLV is advertising the capability specified by the TLV code point.
1 -TLVは、TLVコードポイントで指定された機能を宣伝しています。
0 - The TLV is withdrawing the capability specified by the TLV code point.
0 -TLVは、TLVコードポイントで指定された機能を撤回しています。
Capability Data: Information, if any, about the capability in addition to the TLV code point required to fully specify the capability.
機能データ：機能を完全に指定するために必要なTLVコードポイントに加えて、機能があれば、もしあれば、情報があれば。
The method for interpreting and processing this data is specific to the TLV code point and MUST be described in the document specifying the capability.
このデータを解釈および処理する方法は、TLVコードポイントに固有であり、機能を指定するドキュメントで説明する必要があります。
An LDP speaker MUST NOT include more than one instance of a Capability Parameter (as identified by the same TLV code point) in an Initialization or Capability message. If an LDP speaker receives more than one instance of the same Capability Parameter type in a message, it SHOULD send a Notification message to the peer before terminating the session with the peer. The Status Code in the Status TLV of the Notification message MUST be Malformed TLV value, and the message SHOULD contain the second Capability Parameter TLV of the same type (code point) that is received in the message.
LDPスピーカーには、初期化または機能メッセージに機能パラメーター（同じTLVコードポイントで識別される）のインスタンスを1つ以上含めることはできません。LDPスピーカーがメッセージ内の同じ機能パラメータータイプの複数のインスタンスを受信した場合、ピアとのセッションを終了する前に、ピアに通知メッセージを送信する必要があります。通知メッセージのステータスTLVのステータスコードは、TLV値を奇形している必要があり、メッセージにはメッセージで受信された同じタイプ（コードポイント）の2番目の機能パラメーターTLVを含める必要があります。
LDP extensions that require advertisement or negotiation of some capability at session establishment time typically use TLVs that are included in an Initialization message. To ensure backward compatibility with existing implementations, such TLVs continue to be supported in an Initialization message and are known in this document as "Backward Compatibility TLVs". A Backward Compatibility TLV plays the role of a "Capability Parameter" TLV; that is, the presence of a Backward Compatibility TLV has the same meaning as a Capability Parameter TLV with the S-bit set for the same capability.
セッションの確立時に何らかの機能の広告または交渉を必要とするLDP拡張機能は、通常、初期化メッセージに含まれるTLVを使用します。既存の実装との逆方向の互換性を確保するために、このようなTLVは初期化メッセージで引き続きサポートされており、このドキュメントでは「後方互換性TLV」として知られています。後方互換性TLVは、「機能パラメーター」TLVの役割を果たします。つまり、後方互換性TLVの存在は、同じ機能のSビットセットを使用して、機能パラメーターTLVと同じ意味を持ちます。
One example of a Backward Capability TLV is the "FT Session TLV" that is exchanged in an Initialization message between peers to announce LDP Fault Tolerance [RFC3479] capability.
後方機能TLVの1つの例は、LDPフォールトトレランス[RFC3479]機能を発表するためにピア間の初期化メッセージで交換される「FTセッションTLV」です。
The LDP Capability message is used by an LDP speaker to announce changes in the state of one or more of its capabilities subsequent to session establishment.
LDP機能メッセージは、LDPスピーカーによって使用され、セッション確立後の1つ以上の機能の状態の変更を発表します。
The format of the Capability message is as follows:
機能メッセージの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Capability (0x0202) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV_1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV_N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where TLV_1 through TLV_N are Capability Parameter TLVs. The S-bit of each of the TLVs specifies the new state for the corresponding capability.
ここで、TLV_1からTLV_Nを介して機能パラメーターTLVです。各TLVのsビットは、対応する機能の新しい状態を指定します。
Note that Backward Compatibility TLVs (see Section 3.1) MUST NOT be included in Capability messages. An LDP speaker that receives a Capability message from a peer that includes Backward Compatibility TLVs SHOULD silently ignore these Backward Compatibility TLVs and continue processing the rest of the message.
後方互換性TLV（セクション3.1を参照）は、機能メッセージに含めてはなりません。後方互換性TLVを含むピアから機能メッセージを受信するLDPスピーカーは、これらの後方互換性TLVを静かに無視し、メッセージの残りの部分を処理し続ける必要があります。
The following sections in this document talk about enabling and disabling capabilities. The terminology "enabling (or disabling) a capability" is short hand for "advertising (or withdrawing) a capability associated with an enhancement". Bear in mind that it is an LDP enhancement that is being enabled or disabled, and that it is the corresponding capability that is being advertised or withdrawn.
このドキュメントの次のセクションでは、機能の有効化と無効化に関する説明について説明しています。「機能を有効にする（または無効にする）能力」という用語は、「拡張に関連する機能を広告（または撤回する）」のための短い手です。有効化または無効にされているのはLDP強化であり、宣伝または撤回されているのは対応する能力であることに注意してください。
The S-bit of a Capability Parameter in an Initialization message MUST be 1 and SHOULD be ignored on receipt. This ensures that any Capability Parameter in an Initialization message enables the corresponding capability.
初期化メッセージ内の機能パラメーターのsビットは1でなければならず、受信時に無視する必要があります。これにより、初期化メッセージ内の機能パラメーターが対応する機能を有効にすることが保証されます。
An LDP speaker determines the capabilities of a peer by examining the set of Capability Parameters present in the Initialization message received from the peer.
LDPスピーカーは、ピアから受信した初期化メッセージに存在する一連の機能パラメーターを調べることにより、ピアの機能を決定します。
An LDP speaker MAY use a particular capability with its peer after the speaker determines that the peer has enabled that capability.
LDPスピーカーは、スピーカーがピアがその機能を有効にしたと判断した後、ピアで特定の機能を使用する場合があります。
These procedures enable an LDP speaker S1, that advertises a specific LDP capability C, to establish an LDP session with speaker S2 that does not advertise C. In this situation, whether or not capability C may be used for the session depends on the semantics of the enhancement associated with C. If the semantics do not require both S1 and S2, advertise C to one another, then S2 could use it; i.e., S1's advertisement of C permits S2 to send messages to S1 used by the enhancement.
これらの手順により、特定のLDP機能Cを宣伝するLDPスピーカーS1が、Cを宣伝しないスピーカーS2とのLDPセッションを確立することができます。Cに関連付けられた強化により、セマンティクスがS1とS2の両方を必要としない場合、Cを互いに宣伝し、S2はそれを使用できます。つまり、S1のCの広告により、S2は拡張で使用されるS1にメッセージを送信できます。
It is the responsibility of the capability designer to specify the behavior of an LDP speaker that has enabled a certain enhancement, advertised its capability and determines that its peer has not advertised the corresponding capability. The document specifying procedures for the capability MUST describe the behavior in this situation. If the specified procedure is to terminate the session, then the LDP speaker SHOULD send a Notification message to the peer before terminating the session. The Status Code in the Status TLV of the Notification message MUST be Unsupported Capability, and the message SHOULD contain the unsupported capability (see Section 8 for more details).
特定の強化を可能にし、その能力を宣伝し、そのピアが対応する能力を宣伝していないと判断したLDPスピーカーの動作を指定することは、能力設計者の責任です。機能の手順を指定するドキュメントでは、この状況での動作を説明する必要があります。指定された手順がセッションを終了する場合、セッションを終了する前に、LDPスピーカーはピアに通知メッセージを送信する必要があります。通知メッセージのステータスTLVのステータスコードは、サポートされていない機能でなければならず、メッセージにはサポートされていない機能が含まれている必要があります（詳細についてはセクション8を参照）。
An LDP speaker that supports capability advertisement and includes a Capability Parameter in its Initialization message MUST set the TLV U-bit to 0 or 1, as specified by Capability document. The LDP speaker should set the U-bit to 1 if the capability document allows it to continue with a peer that does not understand the enhancement, and set the U-bit to 0 otherwise. If a speaker receives a message containing unsupported capability, it responds according to the U-bit setting in the TLV. If the U-bit is 1, then the speaker MUST silently ignore the Capability Parameter and allow the session to be established. However, if the U-bit is 0, then speaker SHOULD send a Notification message to the peer before terminating the session. The Status Code in the Status TLV of the Notification message MUST be Unsupported Capability, and the message SHOULD contain the unsupported capability (see Section 8 for more details).
機能広告をサポートし、初期化メッセージに機能パラメーターを含むLDPスピーカーは、機能文書で指定されているように、TLV Uビットを0または1に設定する必要があります。LDPスピーカーは、機能ドキュメントで強化を理解していないピアを続行し、それ以外の場合はUビットを0に設定することができる場合、UビットをUビットを1に設定する必要があります。スピーカーがサポートされていない機能を含むメッセージを受信した場合、TLVのUビット設定に応じて応答します。Uビットが1の場合、スピーカーは静かに機能パラメーターを無視し、セッションの確立を許可する必要があります。ただし、Uビットが0の場合、スピーカーはセッションを終了する前にピアに通知メッセージを送信する必要があります。通知メッセージのステータスTLVのステータスコードは、サポートされていない機能でなければならず、メッセージにはサポートされていない機能が含まれている必要があります（詳細についてはセクション8を参照）。
An LDP speaker MUST NOT send a Capability message to a peer unless its peer advertised the Dynamic Capability Announcement capability in its session Initialization message. An LDP speaker MAY send a Capability message to a peer if its peer advertised the Dynamic Capability Announcement capability in its session Initialization message (see Section 9).
LDPスピーカーは、ピアがセッションの初期化メッセージで動的能力アナウンス機能を宣伝しない限り、ピアに機能メッセージを送信してはなりません。LDPスピーカーは、ピアがセッションの初期化メッセージで動的能力アナウンス機能を宣伝した場合、ピアに機能メッセージを送信する場合があります（セクション9を参照）。
An LDP speaker determines the capabilities enabled by a peer by determining the set of capabilities enabled at session initialization (as specified in Section 6) and tracking changes to that set made by Capability messages from the peer.
LDPスピーカーは、セッションの初期化（セクション6で指定）で有効な一連の機能を決定し、ピアからの機能メッセージによって作成されたセットの変更を追跡することにより、ピアによって有効な機能を決定します。
An LDP speaker that has enabled a particular capability MAY use the enhancement corresponding to the capability with a peer after the speaker determines that the peer has enabled the capability.
特定の機能を有効にしたLDPスピーカーは、スピーカーがピアが機能を有効にしたと判断した後、ピアとの機能に対応する拡張機能を使用する場合があります。
This document defines a new LDP status code named Unsupported Capability. The E-bit of the Status TLV carried in a Notification message that includes this status code MUST be set to 0.
このドキュメントは、サポートされていない機能という名前の新しいLDPステータスコードを定義します。このステータスコードを含む通知メッセージに掲載されたステータスTLVのeビットは、0に設定する必要があります。
In addition, this document defines a new LDP TLV, named Returned TLVs, that MAY be carried in a Notification message as an Optional Parameter. The U-bit setting for a Returned TLVs TLV in a Notification message SHOULD be 1, and the F-bit setting SHOULD be 0.
さらに、このドキュメントでは、returned TLVSという名前の新しいLDP TLVを定義します。これは、オプションのパラメーターとして通知メッセージに伝達される場合があります。通知メッセージの返されたTLVS TLVのUビット設定は1で、Fビット設定は0である必要があります。
When the Status Code in a Notification message is Unsupported Capability, the message SHOULD specify the capabilities that are unsupported. When the Notification message specifies the unsupported capabilities, it MUST include a Returned TLVs TLV. The Returned TLVs TLV MUST include only the Capability Parameters for unsupported capabilities, and the Capability Parameter for each such capability SHOULD be encoded as received from the peer.
通知メッセージのステータスコードがサポートされていない機能である場合、メッセージはサポートされていない機能を指定する必要があります。通知メッセージがサポートされていない機能を指定する場合、返されたTLVS TLVを含める必要があります。返されたTLVS TLVには、サポートされていない機能の機能パラメーターのみを含める必要があり、各そのような機能の機能パラメーターは、ピアから受信したとおりにエンコードする必要があります。
When the Status Code in a Notification Message is Unknown TLV, the message SHOULD specify the TLV that was unknown. When the Notification message specifies the TLV that was unknown, it MUST include the unknown TLV in a Returned TLVs TLV.
通知メッセージのステータスコードが不明なTLVである場合、メッセージは不明なTLVを指定する必要があります。通知メッセージが不明なTLVを指定する場合、返されたTLVS TLVに不明なTLVを含める必要があります。
The Dynamic Capability Announcement TLV is a Capability Parameter defined by this document with following format:
動的能力アナウンス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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| DynCap Ann. (0x0506) | Length (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved |
+-+-+-+-+-+-+-+-+
The value of the U-bit for the Dynamic Capability Announcement Parameter 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. There is no "Capability Data" associated with this TLV and hence the TLV length MUST be set to 1.
ダイナミック機能アナウンスパラメーターTLVのUビットの値は1に設定する必要があります。これにより、受信者は、このTLVが不明な場合は静かに無視し、メッセージの残りの部分を処理し続ける必要があります。このTLVに関連付けられた「機能データ」はないため、TLVの長さは1に設定する必要があります。
The Dynamic Capability Announcement Parameter MAY be included by an LDP speaker in an Initialization message to signal its peer that the speaker is capable of processing Capability messages.
ダイナミック機能アナウンスパラメーターは、LDPスピーカーが初期化メッセージに含めて、スピーカーが機能メッセージを処理できることを同業者に示すことができます。
An LDP speaker MUST NOT include the Dynamic Capability Announcement Parameter in Capability messages sent to its peers. Once enabled during session initialization, the Dynamic Capability Announcement capability cannot be disabled. This implies that the S-bit is always 1 for the Dynamic Capability Announcement.
LDPスピーカーには、ピアに送信された機能メッセージに動的能力アナウンスパラメーターを含めてはなりません。セッションの初期化中に有効になったら、動的能力アナウンス機能を無効にすることはできません。これは、動的能力アナウンスのS-BITが常に1であることを意味します。
An LDP speaker that receives a Capability message from a peer that includes the Dynamic Capability Announcement Parameter SHOULD silently ignore the parameter and process any other Capability Parameters in the message.
動的機能アナウンスパラメーターを含むピアから機能メッセージを受信するLDPスピーカーは、パラメーターを静かに無視し、メッセージ内の他の機能パラメーターを処理する必要があります。
From the point of view of the LDP capability advertisement mechanism, an [RFC5036]-compliant peer has label distribution for IPv4 enabled by default. To ensure compatibility with an [RFC5036]-compliant peer, LDP implementations that support capability advertisement have label distribution for IPv4 enabled until it is explicitly disabled and MUST assume that their peers do as well.
LDP機能広告メカニズムの観点から見ると、[RFC5036] -pliant Peerは、デフォルトで有効になっているIPv4のラベル分布を持っています。[RFC5036]を統合するピアとの互換性を確保するために、機能広告をサポートするLDP実装により、IPv4が明示的に無効になり、同業者も同様に行うと想定する必要があるIPv4のラベル分布があります。
Section 3.1 introduces the concept of Backward Compatibility TLVs that may appear in an Initialization message in the role of a Capability Parameter. This permits existing LDP enhancements that use an ad hoc mechanism for enabling capabilities at session initialization time to continue to do so.
セクション3.1では、機能パラメーターの役割の初期化メッセージに表示される可能性のある後方互換性TLVの概念を紹介します。これにより、セッションの初期化時間で機能を可能にするためにアドホックメカニズムを使用する既存のLDP強化が可能になります。
[MPLS_SEC] describes the security framework for MPLS networks, whereas [RFC5036] describes the security considerations that apply to the base LDP specification. The same security framework and considerations apply to the capability mechanism described in this document.
[MPLS_SEC]は、MPLSネットワークのセキュリティフレームワークを説明しますが、[RFC5036]は、ベースLDP仕様に適用されるセキュリティの考慮事項を説明します。同じセキュリティフレームワークと考慮事項は、このドキュメントで説明されている機能メカニズムに適用されます。
This document specifies the following code points assigned by IANA:
このドキュメントは、IANAによって割り当てられた次のコードポイントを指定します。
- LDP message code point for the Capability message (0x0202).
- 機能メッセージのLDPメッセージコードポイント（0x0202）。
- LDP TLV code point for the Dynamic Capability Announcement TLV (0x0506).
- 動的能力アナウンスTLV（0x0506）のLDP TLVコードポイント。
- LDP TLV code point for the Returned TLVs TLV (0x0304).
- 返されたTLVS TLV（0x0304）のLDP TLVコードポイント。
- LDP Status Code code point for the Unsupported Capability Status Code (0x0000002E).
- サポートされていない機能ステータスコード（0x0000002E）のLDPステータスコードコードポイント。
The authors wish to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo, Yakov Rekhter, and Eric Rosen for their comments.
著者は、エンケ・チェン、ヴァンソン・リム、イナ・ミネイ、ビン・モー、ヤコフ・レクター、エリック・ローゼンのコメントに感謝したいと考えています。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、ed。、Minei、I.、ed。、およびB. Thomas、ed。、「LDP仕様」、RFC 5036、2007年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3479] Farrel, A., Ed., "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.
[RFC3479] Farrel、A.、ed。、「ラベル分布プロトコル（LDP）のフォールトトレランス」、RFC 3479、2003年2月。
[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", RFC 5283, July 2008.
[RFC5283] Decraene、B.、Le Roux、Jl。、およびI. Misei、「エリア間ラベルスイッチドパス（LSP）のLDP拡張」、RFC 5283、2008年7月。
[MLDP] Minei, I., Ed., Kompella, K., Wijnands, I., Ed., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Work in Progress, April 2009.
[MLDP] Misei、I.、ed。、Kompella、K.、Wijnands、I.、Ed。、およびB. Thomas、「ポイントツーマルチポイントおよびマルチポイントツーマルチポイントラベルスイッチパスのラベル分布プロトコル拡張」」、作業中の2009年4月。
[NNHOP] Shen, N., Chen, E., and A. Tian, "Discovery LDP Next-Nexthop Labels", Work in Progress, May 2005.
[Nnhop] Shen、N.、Chen、E。、およびA. Tian、「Discovery LDP Next-Nexthop Labels」、2005年5月、進行中の作業。
[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.
[RFC4447] Martini、L.、Ed。、Ed。、Rosen、E.、El-Aawar、N.、Smith、T。、およびG. Heron、「擬似ワイヤー分布プロトコル（LDP）を使用した擬似ワイヤーのセットアップとメンテナンス」、RFC 4447、2006年4月。
[RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003.
[RFC3478] Leelanivas、M.、Rekhter、Y。、およびR. Aggarwal、「ラベル分布プロトコルの優雅な再起動メカニズム」、RFC 3478、2003年2月。
[UPSTREAM_LDP] Aggarwal R., and J.L. Le Roux, "MPLS Upstream Label Assignment for LDP" Work in Progress, July 2008.
[upstream_ldp] Aggarwal R.、およびJ.L. Le Roux、「MPLS上流ラベルのLDPの割り当て」が2008年7月に進行中の作業。
[MPLS_SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, March 2009.
[MPLS_SEC] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、2009年3月、Work in Progress。
Authors' Addresses
著者のアドレス
Bob Thomas Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 EMail: bobthomas@alum.mit.edu
Bob Thomas Cisco Systems、Inc。1414 Massachusetts Ave. Boxborough、MA 01719メール：bobthomas@alum.mit.edu
Shivani Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: shivani@juniper.net
Shivani Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale、CA 94089メール：shivani@juniper.net
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: rahul@juniper.net
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale、CA 94089メール：rahul@juniper.net
Jean-Louis Le Roux France Telecom 2, Avenue Pierre-Marzin 22307 Lannion Cedex, France EMail: jeanlouis.leroux@orange-ftgroup.com
Jean-Louis Le Roux France Telecom 2、Avenue Pierre-Marzin 22307 Lannion Cedex、France Email：jeanlouis.leroux@orange-ftgroup.com
Kamran Raza Cisco Systems, Inc. 2000 Innovation Dr. Kanata, ON K2K 3E8, Canada EMail: skraza@cisco.com
Kamran Raza Cisco Systems、Inc。2000 Innovation Dr. Kanata、K2K 3E8、Canada Email：skraza@cisco.com