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
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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の拡張機能の数が提案されています。これらは、レイヤ2つの回路[RFC4447]、高速リルートノードをサポートするために次の次ホップルータによって通知ラベルを学習する方法のためのシグナリング、LDPグレースフルリスタート[RFC3478]、フォールトトレラントLDP [RFC3479]、マルチキャスト拡張[MLDP]を含みます保護は[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機能広告は、それが受信して処理することができますどのような発表する自民党のスピーカーのための手段を提供します。また、[RFC5036]で指定された行動からの逸脱の仲間に知らせるために、スピーカーのための手段を提供します。そのような偏差の例は、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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:
次のように自民党の能力広告機構で動作します。
- 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.
- 自民党のスピーカーは、それがセッションの確立、次の処理能力の発表が可能であることを示すために、その初期化メッセージに広告を出すかもしれないことにダイナミックな能力発表と呼ばれるよく知られた機能があります。
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.
ピアは、その初期化メッセージでダイナミックな能力お知らせ機能を宣伝していた場合は、その後、セッション確立、次のいずれかの時点で、自民党のスピーカーは、そのピアへのアドバタイズされた機能の変更を発表するかもしれません。これを行うには、自民党のスピーカーがアドバタイズまたは撤回された機能を指定したピア能力メッセージを送信します。
When the capability advertisement mechanism is in place, an LDP enhancement requiring LDP capability advertisement will be specified by a document that:
機能広告メカニズムが所定の位置にあるときは、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ビット：不明TLVのビット、[RFC5036]に記載されているように。所定の機能に関連付けられた機能のドキュメントで指定された値は、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ビット：[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タイプ。これは、関連する機能文書で要求として与えられる機能のため（TLVタイプの名前空間から）IANAによって割り当てられたコード・ポイントです。
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ビット：状態ビット。これは、送信者がTLVコードポイントに対応する機能を広告するか撤退するかどうかを示します。次のように状態ビットの値が使用されます。
1 - The TLV is advertising the capability specified by the TLV
code point.
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コードポイントによって識別される）の複数のインスタンスを含めることはできません。 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.
セッション確立時にいくつかの能力の広告または交渉を必要とする自民党の拡張子は、通常の初期化メッセージに含まれている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の一例は、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能力メッセージは、セッションの確立に続いて、その機能のうちの1つまたは複数の状態の変化を通知するLDPスピーカーによって使用されます。
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を無視して、メッセージの残りの部分の処理を続行すべきで下位互換性TLVを含んピアから能力メッセージを受信したLDPスピーカー。
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.
このドキュメントの次のセクションでは、有効化や能力を無効について話しています。用語「有効化（または無効）機能」とは、「広告（又は吸引）拡張に関連付けられた能力」の短い手です。それが有効または無効にしている自民党の強化であり、それがアドバタイズまたは撤回され、対応する能力のあることことに注意してください。
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.
スピーカーは、ピアがその機能を有効にしていることを決定した後、自民党のスピーカーは、そのピアと特定の機能を使用するかもしれません。
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.
これらの手順は、の意味論に依存する機能Cは、セッションのために使用することができるかどうか、このような状況でC.をアドバタイズしないスピーカS2とLDPセッションを確立するために、特定のLDP能力CをアドバタイズLDPスピーカS1を、有効C.関連付けられたエンハンスメントセマンティクスがS1とS2の両方を必要としない場合、相互にCをアドバタイズし、S2がそれを使用することができます。すなわち、CのS1の広告が強調によって使用S1へメッセージを送信するS2を可能にします。
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スピーカは、セッションを終了する前にピアに通知メッセージを送信するべきです。通知メッセージのステータス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スピーカーは、0または1にTLV Uビットを設定しなければなりません。 LDPスピーカー能力文書は、それが拡張を理解していないピアを続行することを可能にする場合に1にUビットを設定し、それ以外の場合は0にUビットを設定しなければなりません。話者がサポートされていない機能を含むメッセージを受信すると、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スピーカーがピアに能力メッセージを送信することができる（セクション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.
また、この文書は、オプションのパラメータとして、通知メッセージで運ばれることが、返されるのTLVという名前の新しいLDP TLVを定義します。通知メッセージで返されるTLVの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.
通知メッセージにステータスコードがサポートされていない機能がある場合は、メッセージがサポートされない機能を指定する必要があります。通知メッセージがサポートされていない機能を指定すると、それが返されるのTLV TLVを含まなければなりません。返さTLVの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を指定すると、それが返されるのTLV 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を無視して、メッセージの残りの処理を継続しなければならないように動的能力発表パラメータTLVのためのUビットの値を1に設定しなければなりません。この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.
自民党のスピーカーは、そのピアに送信された機能メッセージの動的能力発表パラメータを含んではいけません。一度セッション初期化時に有効になって、ダイナミックな能力お知らせ機能は無効にすることはできません。これは、Sビットは、常に動的な機能アナウンスのための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.
自民党の能力広告機構の観点からは、[RFC5036]に準拠したピアはデフォルトで有効にIPv4のラベル配布しています。 [RFC5036]準拠のピアとの互換性を確保するために、能力の広告をサポートする自民党の実装は、それが明示的に無効になり、仲間が同様に行うと仮定しなければなりませんまで、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.
[RFC5036]はベースLDP仕様に適用されるセキュリティ上の考慮事項を記載し、一方[MPLS_SEC]、MPLSネットワークのセキュリティフレームワークを記述する。同じセキュリティフレームワークと考慮事項は、この文書で説明する機能機構に適用されます。
This document specifies the following code points assigned by IANA:
この文書は、IANAによって割り当てられた次のコード・ポイントを指定します。
- LDP message code point for the Capability message (0x0202).
- 能力メッセージ（0x0202）用のLDPメッセージコードポイント。
- 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).
- 返さTLVのTLV（0x0304）用LDP TLVコードポイント。
- LDP Status Code code point for the Unsupported Capability Status Code (0x0000002E).
- サポートされていない機能のステータスコードのためのLDPステータスコードコードポイント（0x0000002E）。
The authors wish to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo, Yakov Rekhter, and Eric Rosen for their comments.
作者は彼らのコメントのためにエンケ陳、バンソン・リム、伊那Minei、ビンのMo、ヤコフ・レックター、およびエリックローゼンに感謝したいです。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]アンデション、L.、エド。、Minei、I.、エド。、およびB.トーマス、エド。、 "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3479] Farrel, A., Ed., "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.
[RFC3479]ファレル、A.編、 "ラベル配布プロトコル（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.、ル・ルー、JL。、およびI. Mineiは、RFC 5283、2008年7月、 "エリア間のラベルのためのLDP拡張は、スイッチパス（LSP）"。
[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] Minei、I.、エド。、Kompella、K.、Wijnands、I.、エド。、およびB.トーマス、「ラベル配布プロトコルの拡張ポイント・ツー・マルチポイントおよびマルチポイント・ツー・マルチポイントラベルは、パスの交換しました」 、進捗状況、2009年4月に作業。
[NNHOP] Shen, N., Chen, E., and A. Tian, "Discovery LDP Next-Nexthop Labels", Work in Progress, May 2005.
[NNHOP]シェン、N.、チェン、E.、およびA.天、 "ディスカバリーLDP次-ネクストホップラベル"、進歩、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]、RFC 4447マティーニ、L.、エド。、ローゼン、E.、エルAawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（LDP）を使用して疑似回線の設定とメンテナンス" 、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.アガルワル、 "ラベル配布プロトコルのためのグレースフルリスタートメカニズム"、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]アガルワルR.、およびJ.L.ル・ルー、進歩、2008年7月に仕事「LDPのためのMPLS上流のラベルの割り当て」。
[MPLS_SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, March 2009.
[MPLS_SEC]牙、L.、エド。、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク" が進歩、2009年3月での作業。
Authors' Addresses
著者のアドレス
Bob Thomas Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 EMail: bobthomas@alum.mit.edu
ボブトーマスシスコシステムズ株式会社1414年マサチューセッツアベニュー。ボックスボロー、MA 01719 Eメール：bobthomas@alum.mit.edu
Shivani Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: shivani@juniper.net
シヴァーニアガルワルジュニパーネットワークスの1194北マチルダアベニュー。サニーベール、CA 94089 Eメール：shivani@juniper.net
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: rahul@juniper.net
ラウール・アガーウォールジュニパーネットワークスの1194北マチルダアベニュー。サニーベール、CA 94089 Eメール：rahul@juniper.net
Jean-Louis Le Roux France Telecom 2, Avenue Pierre-Marzin 22307 Lannion Cedex, France EMail: jeanlouis.leroux@orange-ftgroup.com
ジャン=ルイ・ルーフランステレコム2、アベニューピエールMarzin 22307ラニオンセデックス、フランスEメール：jeanlouis.leroux@orange-ftgroup.com
Kamran Raza Cisco Systems, Inc. 2000 Innovation Dr. Kanata, ON K2K 3E8, Canada EMail: skraza@cisco.com
K2K 3E8 ONカムラン・ラザシスコシステムズ株式会社2000年イノベーション博士カナタ、、カナダEメール：skraza@cisco.com