[要約] RFC 3472は、GMPLSのCR-LDP拡張に関する規格であり、制約ベースの経路ラベル配布プロトコルに関する拡張機能を提供します。このRFCの目的は、GMPLSネットワークでの制約ベースの経路制御をサポートするための拡張を定義することです。
Network Working Group P. Ashwood-Smith, Editor
Request for Comments: 3472 Nortel Networks
Category: Standards Track L. Berger, Editor
Movaz Networks
January 2003
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions
一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング制約ベースのルーティングラベル分布プロトコル（CR-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) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes extensions to Multi-Protocol Label Switching (MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. A generic functional description can be found in separate documents.
このドキュメントでは、一般化されたMPLSをサポートするために必要なマルチプロトコルラベルスイッチング（MPLS）制約ベースのルーティングラベル分布プロトコル（CR-LDP）シグナル伝達への拡張について説明します。一般化されたMPLSは、MPLSコントロールプレーンを拡張して、時間帯（例えば、同期光ネットワークと同期デジタル階層、SONET/SDH）、波長（光lambdas）および空間スイッチング（たとえば、出力ポートまたは発信ポートまたはファイバーへの繊維）を包含します。このドキュメントでは、拡張機能のCR-LDP固有の説明を示します。一般的な機能的説明は、個別のドキュメントに記載されています。
Table of Contents
目次
1. Introduction .............................................. 2
2. Label Related Formats .................................... 3
2.1 Generalized Label Request ............................... 3
2.2 Generalized Label ....................................... 4
2.3 Waveband Switching ...................................... 5
2.4 Suggested Label ......................................... 6
2.5 Label Set ............................................... 6
3. Bidirectional LSPs ........................................ 8
3.1 Procedures .............................................. 8
4. Notification on Label Error ............................... 9
5. Explicit Label Control .................................. 9
5.1 Procedures .............................................. 9
6. Protection TLV ............................................ 10
6.1 Procedures .............................................. 11
7. Administrative Status Information ......................... 11
7.1 Admin Status TLV ........................................ 11
7.2 REQUEST and MAPPING Message Procedures .................. 12
7.3 Notification Message Procedures ......................... 13
8. Control Channel Separation ................................ 14
8.1 Interface Identification ................................ 14
8.2 Errored Interface Identification ........................ 15
9. Fault Handling ......................................... 17
10 Acknowledgments ........................................... 17
11. Security Considerations ................................... 17
12. IANA Considerations ....................................... 17
13. Intellectual Property Considerations ...................... 18
14. References ................................................ 18
14.1 Normative References ................................... 18
14.2 Informative References ................................. 19
15. Contributors .............................................. 19
16. Editors' Addresses ........................................ 22
17. Full Copyright Statement ................................... 23
Generalized MPLS extends MPLS from supporting packet (PSC) interfaces and switching to include support of three new classes of interfaces and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and Fiber-Switch (FSC). A functional description of the extensions to MPLS signaling needed to support the new classes of interfaces and switching is provided in [RFC3471]. This document presents CR-LDP specific formats and mechanisms needed to support all four classes of interfaces. RSVP-TE extensions can be found in [RFC3473].
一般化されたMPLSは、サポートパケット（PSC）インターフェイスからMPLSを拡張し、3つの新しいクラスのインターフェイスとスイッチングのサポートを含めるために、タイムディビジョンマルチプレックス（TDM）、LAMBDAスイッチ（LSC）、ファイバースイッチ（FSC）をサポートします。[RFC3471]には、新しいクラスのインターフェイスとスイッチングをサポートするために必要なMPLSシグナル伝達への拡張の機能的説明が[RFC3471]に提供されています。このドキュメントでは、4つのクラスのインターフェイスすべてをサポートするために必要なCR-LDP固有の形式とメカニズムを示しています。RSVP-TE拡張機能は[RFC3473]にあります。
[RFC3471] should be viewed as a companion document to this document. The format of this document parallels [RFC3471]. It should be noted that the RSVP-TE specific version of Generalized MPLS includes RSVP specific support for rapid failure notification, see Section 4 [RFC3473]. For CR-LDP there is not currently a similar mechanism. When a failure is detected it will be propagated with RELEASE/WITHDRAW messages radially outward from the point of failure. Resources are to be released in this phase and actual resource information may be fed back to the source using a feedback mechanisms.
[RFC3471]は、このドキュメントのコンパニオンドキュメントとして見る必要があります。このドキュメントの形式は類似しています[RFC3471]。一般化されたMPLSのRSVP-TE固有のバージョンには、迅速な障害通知のためのRSVP固有のサポートが含まれていることに注意する必要があります。セクション4 [RFC3473]を参照してください。CR-LDPの場合、現在同様のメカニズムはありません。障害が検出されると、障害の時点から放射状のメッセージが放射状に外側に向かって伝播されます。このフェーズでリソースをリリースし、実際のリソース情報は、フィードバックメカニズムを使用してソースに供給される場合があります。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
This section defines formats for a generalized label request, a generalized label, support for waveband switching, suggested label and label sets.
このセクションでは、一般化されたラベルリクエストのフォーマット、一般化されたラベル、ウェーブバンドスイッチングのサポート、提案されたラベルセット、ラベルセット。
A REQUEST message SHOULD contain as specific an LSP (Label Switched Path) Encoding Type as possible to allow the maximum flexibility in switching by transit LSRs. A Generalized Label Request Type, Length, and Value (TLV) is set by the ingress node, transparently passed by transit nodes, and used by the egress node. The Switching Type field may also be updated hop-by-hop.
リクエストメッセージには、特定のLSP（ラベルスイッチ付きパス）エンコードタイプとして、トランジットLSRによる切り替えの最大の柔軟性を可能にする必要があります。一般化されたラベル要求の種類、長さ、および値（TLV）は、イングレスノードによって設定され、トランジットノードで透過的に通過し、出口ノードで使用されます。スイッチングタイプフィールドは、ホップバイホップを更新することもできます。
The format of a Generalized Label Request is:
一般化されたラベル要求の形式は次のとおりです。
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| Type (0x0824) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
パラメーターの説明については、[RFC3471]を参照してください。
A node processing a REQUEST message containing a Generalized Label Request must verify that the requested parameters can be satisfied by the incoming interface, the node and by the outgoing interface. The node may either directly support the LSP or it may use a tunnel (FA), i.e., another class of switching. In either case, each parameter must be checked.
一般化されたラベル要求を含むノード処理要求メッセージは、リクエストされたパラメーターが着信インターフェイス、ノード、および発信インターフェイスによって満たされることを確認する必要があります。ノードは、LSPを直接サポートするか、トンネル（FA）、つまり別のクラスの切り替えを使用する場合があります。どちらの場合でも、各パラメーターをチェックする必要があります。
Note that local node policy dictates when tunnels may be used and when they may be created. Local policy may allow for tunnels to be dynamically established or may be solely administratively controlled. For more information on tunnels and processing of ER (Explicit Route) hops when using tunnels see [MPLS-HIERARCHY].
ローカルノードポリシーは、トンネルがいつ使用されるか、いつ作成されるかを決定することに注意してください。ローカルポリシーは、トンネルを動的に確立することを可能にする場合があります。また、管理上管理されている場合もあります。トンネルとER（明示的なルート）の処理の詳細については、トンネルを使用する場合は[MPLS-階層]を参照してください。
Transit and egress nodes MUST verify that the node itself and, where appropriate, that the outgoing interface or tunnel can support the requested LSP Encoding Type. If encoding cannot be supported, the node MUST generate a NOTIFICATION message, with a "Routing problem/Unsupported Encoding" indication.
トランジットノードと出口ノードは、ノード自体と、必要に応じて、発信インターフェイスまたはトンネルが要求されたLSPエンコードタイプをサポートできることを確認する必要があります。エンコードをサポートできない場合、ノードは「ルーティングの問題/サポートされていないエンコード」表示を備えた通知メッセージを生成する必要があります。
Nodes MUST verify that the type indicated in the Switching Type parameter is supported on the corresponding incoming interface. If the type cannot be supported, the node MUST generate a NOTIFICATION message with a "Routing problem/Switching Type" indication.
ノードは、スイッチングタイプパラメーターに示されているタイプが、対応する着信インターフェイスでサポートされていることを確認する必要があります。タイプをサポートできない場合、ノードは「ルーティングの問題/スイッチングタイプ」の表示で通知メッセージを生成する必要があります。
The G-PID parameter is normally only examined at the egress. If the indicated G-PID cannot be supported then the egress MUST generate a NOTIFICATION message, with a "Routing problem/Unsupported G-PID" indication. In the case of PSC and when penultimate hop popping (PHP) is requested, the penultimate hop also examines the (stored) G-PID during the processing of the MAPPING message. In this case if the G-PID is not supported, then the penultimate hop MUST generate a NOTIFICATION message with a "Routing problem/Unacceptable label value" indication. The generated NOTIFICATION message MAY include an Acceptable Label Set, see Section 4.
G-PIDパラメーターは通常、出口でのみ調べられます。示されたG-PIDをサポートできない場合、出力は「ルーティングの問題/サポートされていないG-PID」表示を備えた通知メッセージを生成する必要があります。PSCの場合、最後から2番目のホップポップ（PHP）が要求される場合、最後から2番目のホップは、マッピングメッセージの処理中に（保存された）G-PIDも調べます。この場合、G-PIDがサポートされていない場合、最後から2番目のホップは、「ルーティングの問題/容認できないラベル値」の表示を持つ通知メッセージを生成する必要があります。生成された通知メッセージには、許容可能なラベルセットが含まれる場合があります。セクション4を参照してください。
When an error message is not generated, normal processing occurs. In the transit case this will typically result in a REQUEST message being propagated. In the egress case and PHP special case this will typically result in a MAPPING message being generated.
エラーメッセージが生成されない場合、通常の処理が発生します。トランジットの場合、これは通常、リクエストメッセージが伝播されます。出口の場合とPHPの特別なケースでは、これは通常、マッピングメッセージが生成されます。
Bandwidth encodings are carried in the CR-LDP Traffic Parameters TLV. See [RFC3471] for a definition of values to be used for specific signal types. These values are set in the Peak and Committed Data Rate fields of the Traffic Parameters TLV. Other bandwidth/service related parameters in the TLV are ignored and carried transparently.
帯域幅エンコーディングは、CR-LDPトラフィックパラメーターTLVで実施されます。特定の信号タイプに使用する値の定義については、[RFC3471]を参照してください。これらの値は、トラフィックパラメーターTLVのピークおよびコミットされたデータレートフィールドに設定されています。TLVの他の帯域幅/サービス関連のパラメーターは無視され、透過的に運ばれます。
The format of a Generalized Label is:
一般化されたラベルの形式は次のとおりです。
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| Type (0x0825) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters and encoding of labels.
ラベルのパラメーターとエンコードの説明については、[RFC3471]を参照してください。
The Generalized Label travels in the upstream direction in MAPPING messages.
一般化されたラベルは、マッピングメッセージで上流の方向に移動します。
The presence of both a generalized and normal label TLV in a MAPPING message is a protocol error and should treated as a malformed message by the recipient.
マッピングメッセージに一般化されたラベルTLVと通常のラベルTLVの両方が存在することは、プロトコルエラーであり、受信者による奇形のメッセージとして扱われる必要があります。
The recipient of a MAPPING message containing a Generalized Label verifies that the values passed are acceptable. If the label is unacceptable then the recipient MUST generate a NOTIFICATION message with a "Routing problem/MPLS label allocation failure" indication. The generated NOTIFICATION message MAY include an Acceptable Label Set, see Section 4.
一般化されたラベルを含むマッピングメッセージの受信者は、渡された値が許容できることを確認します。ラベルが受け入れられない場合、受信者は「ルーティング問題/MPLSラベル割り当て障害」の表示を持つ通知メッセージを生成する必要があります。生成された通知メッセージには、許容可能なラベルセットが含まれる場合があります。セクション4を参照してください。
Waveband switching uses the same format as the generalized label, see section 2.2. The type 0x0828 is assigned for the Waveband Label.
WaveBand Switchingは、一般化されたラベルと同じ形式を使用します。セクション2.2を参照してください。タイプ0x0828は、ウェーブバンドラベルに割り当てられています。
In the context of waveband switching, the generalized label has the following format:
波形スイッチングのコンテキストでは、一般化されたラベルには次の形式があります。
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| Type (0x0828) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waveband Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
パラメーターの説明については、[RFC3471]を参照してください。
The procedures defined in Section 2.2.1 apply to waveband switching. This includes generating a NOTIFICATION message with a "Routing problem/MPLS label allocation failure" indication if any of the label fields are unrecognized or unacceptable.
セクション2.2.1で定義されている手順は、波帯バンドスイッチングに適用されます。これには、ラベルフィールドのいずれかが認識されていないか容認できない場合の「ルーティング問題/MPLSラベル割り当て障害」の表示を備えた通知メッセージの生成が含まれます。
Additionally, when a waveband is switched to another waveband, it is possible that the wavelengths within the waveband will be mirrored about a center frequency. When this type of switching is employed, the start and end label in the waveband label TLV MUST be swapped before forwarding the label TLV with the new waveband Id. In this manner an egress/ingress LSR that receives a waveband label which has these values inverted, knows that it must also invert its egress association to pick up the proper wavelengths. Without this mechanism and with an odd number of mirrored switching operations, the egress LSRs will not know that an input wavelength of say L1 will emerge from the waveband tunnel as L100.
さらに、波形が別の波帯に切り替えられると、波帯内の波長が中心周波数についてミラーリングされる可能性があります。このタイプのスイッチングを使用する場合、ラベルTLVを新しいWaveBand IDで転送する前に、WaveBandラベルTLVのスタートおよびエンドラベルを交換する必要があります。このようにして、これらの値を反転させる波路帯域ラベルを受け取る出力/侵入LSRは、出口の関連性を反転して適切な波長を拾う必要があることを知っています。このメカニズムがなく、奇数のミラー化されたスイッチング操作がなければ、Egress LSRSは、L1の入力波長がL100としてWaveBandトンネルから出現することを知りません。
This operation MUST be performed in both directions when a bidirectional waveband tunnel is being established.
この操作は、双方向の波路帯域トンネルが確立されている場合、両方向に実行する必要があります。
The format of a suggested label is identical to a generalized label. It is used in REQUEST messages. Suggested Label uses type = 0x904.
提案されたラベルの形式は、一般化されたラベルと同じです。リクエストメッセージで使用されます。提案されたラベルはタイプ= 0x904を使用します。
Errors in received Suggested Labels MUST be ignored. This includes any received inconsistent or unacceptable values.
受信した推奨ラベルのエラーは無視する必要があります。これには、受け取った一貫性のないまたは容認できない値が含まれます。
Per [RFC3471], if a downstream node passes a label value that differs from the suggested label upstream, the upstream LSR MUST either reconfigure itself so that it uses the label specified by the downstream node or generate a NOTIFICATION message with a "Routing problem/Unacceptable label value" indication. Furthermore, an ingress node SHOULD NOT transmit data traffic using a suggested label until the downstream node passes corresponding a label upstream.
[RFC3471]ごとに、下流ノードが提案されたラベル上流とは異なるラベル値を渡す場合、上流のLSRは、下流ノードで指定されたラベルを使用するか、「ルーティングの問題/」で通知メッセージを生成するように自体を再構成する必要があります。受け入れられないラベル値 "指標。さらに、イングレスノードは、下流のノードが上流のラベルに対応するラベルを通過するまで、提案されたラベルを使用してデータトラフィックを送信してはなりません。
The format of a Label Set is:
ラベルセットの形式は次のとおりです。
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| Type (0x0827) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label Type: 14 bits
Indicates the type and format of the labels carried in the TLV. Values match the TLV type of the appropriate Label TLV.
TLVで運ばれるラベルのタイプと形式を示します。値は、適切なラベルTLVのTLVタイプと一致します。
See [RFC3471] for a description of other parameters.
他のパラメーターの説明については、[RFC3471]を参照してください。
A Label Set is defined via one or more Label Set TLVs. Specific labels/subchannels can be added to or excluded from a Label Set via Action zero (0) and one (1) TLVs respectively. Ranges of labels/subchannels can be added to or excluded from a Label Set via Action two (2) and three (3) TLVs respectively. When the Label Set TLVs only list labels/subchannels to exclude, this implies that all other labels are acceptable.
ラベルセットは、1つ以上のラベルセットTLVを介して定義されます。特定のラベル/サブチャネルは、それぞれアクションゼロ（0）と1つのTLVを介してセットされたラベルに追加または除外できます。ラベル/サブチャネルの範囲は、それぞれアクション2（2）と3つのTLVを使用して、ラベルセットに追加または除外できます。ラベルセットTLVSが除外するラベル/サブチャネルのみをリストする場合、これは他のすべてのラベルが許容できることを意味します。
The absence of any Label Set TLVs implies that all labels are acceptable. A Label Set is included when a node wishes to restrict the label(s) that may be used downstream.
ラベルセットTLVがないことは、すべてのラベルが許容できることを意味します。ノードが下流で使用できるラベルを制限したい場合、ラベルセットが含まれています。
On reception of a REQUEST message, the receiving node will restrict its choice of labels to one, which is in the Label Set. Nodes capable of performing label conversion may also remove the Label Set prior to forwarding the REQUEST message. If the node is unable to pick a label from the Label Set or if there is a problem parsing the Label Set TLVs, then the request is terminated and a NOTIFICATION message with a "Routing problem/Label Set" indication MUST be generated. It is a local matter if the Label Set is stored for later selection on the MAPPING message or if the selection is made immediately for propagation in the MAPPING message.
リクエストメッセージを受信すると、受信ノードはラベルの選択をラベルセットに制限します。ラベル変換を実行できるノードは、リクエストメッセージを転送する前にラベルセットを削除する場合があります。ノードがラベルセットからラベルを選択できない場合、またはラベルセットTLVを解析する問題がある場合、リクエストが終了し、「ルーティング問題/ラベルセット」表示を備えた通知メッセージを生成する必要があります。ラベルセットが後でマッピングメッセージで選択するために保存されている場合、またはマッピングメッセージの伝播のために選択がすぐに作成されるかどうかはローカルな問題です。
On reception of a REQUEST message, the Label Set represented in the message is compared against the set of available labels at the downstream interface and the resulting intersecting Label Set is forwarded in a REQUEST message. When the resulting Label Set is empty, the REQUEST must be terminated, and a NOTIFICATION message, and a "Routing problem/Label Set" indication MUST be generated. Note that intersection is based on the physical labels (actual wavelength/band values) which may have different logical values on different links, as a result it is the responsibility of the node to map these values so that they have a consistent physical meaning, or to drop the particular values from the set if no suitable logical label value exists.
リクエストメッセージを受信すると、メッセージに表示されるラベルセットは、ダウンストリームインターフェイスで利用可能なラベルのセットと比較され、結果の交差するラベルセットはリクエストメッセージに転送されます。結果のラベルセットが空の場合、リクエストを終了し、通知メッセージを終了する必要があり、「ルーティングの問題/ラベルセット」表示を生成する必要があります。交差点は、異なるリンクで異なる論理値を持つ可能性のある物理ラベル（実際の波長/バンド値）に基づいていることに注意してください。適切な論理ラベル値が存在しない場合、セットから特定の値をドロップします。
When processing a MAPPING message at an intermediate node, the label propagated upstream MUST fall within the Label Set.
中間ノードでマッピングメッセージを処理する場合、上流に伝播したラベルはラベルセット内に分類する必要があります。
Note, on reception of a MAPPING message a node that is incapable of performing label conversion has no other choice than to use the same physical label (wavelength/band) as received in the MAPPING message. In this case, the use and propagation of a Label Set will significantly reduce the chances that this allocation will fail.
マッピングメッセージの受信時に、ラベル変換を実行できないノードは、マッピングメッセージで受信したのと同じ物理ラベル（波長/帯域）を使用する以外の選択肢はありません。この場合、ラベルセットの使用と伝播は、この割り当てが失敗する可能性を大幅に減らします。
Bidirectional LSP setup is indicated by the presence of an Upstream Label in the REQUEST message. An Upstream Label has the same format as the generalized label, see Section 2.2. Upstream Label uses type = 0x0826.
双方向LSPセットアップは、リクエストメッセージに上流ラベルが存在することによって示されます。上流のラベルは、一般化されたラベルと同じ形式を持っています。セクション2.2を参照してください。アップストリームラベルでは、タイプ= 0x0826を使用します。
The process of establishing a bidirectional LSP follows the establishment of a unidirectional LSP with some additions. To support bidirectional LSPs an Upstream Label is added to the REQUEST message. The Upstream Label MUST indicate a label that is valid for forwarding at the time the REQUEST message is sent.
双方向LSPを確立するプロセスは、いくつかの追加を伴う単方向LSPの確立に続きます。双方向LSPをサポートするために、リクエストメッセージに上流ラベルが追加されます。上流ラベルは、要求メッセージが送信された時点で転送に有効なラベルを示す必要があります。
When a REQUEST message containing an Upstream Label is received, the receiver first verifies that the upstream label is acceptable. If the label is not acceptable, the receiver MUST issue a NOTIFICATION message with a "Routing problem/Unacceptable label value" indication. The generated NOTIFICATION message MAY include an Acceptable Label Set, see Section 4.
アップストリームラベルを含むリクエストメッセージが受信されると、レシーバーは最初にアップストリームラベルが許容できることを確認します。ラベルが受け入れられない場合、受信者は「ルーティングの問題/容認できないラベル値」の表示を備えた通知メッセージを発行する必要があります。生成された通知メッセージには、許容可能なラベルセットが含まれる場合があります。セクション4を参照してください。
An intermediate node must also allocate a label on the outgoing interface and establish internal data paths before filling in an outgoing Upstream Label and propagating the REQUEST message. If an intermediate node is unable to allocate a label or internal resources, then it MUST issue a NOTIFICATION message with a "Routing problem/Label allocation failure" indication.
また、中間ノードは、発信アップストリームラベルに記入してリクエストメッセージを伝播する前に、発信インターフェイスにラベルを割り当て、内部データパスを確立する必要があります。中間ノードがラベルまたは内部リソースを割り当てることができない場合、「ルーティングの問題/ラベル割り当て障害」の表示で通知メッセージを発行する必要があります。
Terminator nodes process REQUEST messages as usual, with the exception that the upstream label can immediately be used to transport data traffic associated with the LSP upstream towards the initiator.
ターミネーターノードは、上流のラベルをすぐに使用して、LSPに関連するデータトラフィックをイニシエーターに向けて輸送できることを除いて、通常どおりリクエストメッセージを処理します。
When a bidirectional LSP is removed, both upstream and downstream labels are invalidated and it is no longer valid to send data using the associated labels.
双方向LSPが削除されると、上流ラベルとダウンストリームラベルの両方が無効になり、関連するラベルを使用してデータを送信することはもはや有効です。
This section defines the Acceptable Label Set TLV to support Notification on Label Error per [RFC3471]. An Acceptable Label Set TLV uses a type value of 0x082a. The remaining contents of the TLV have the identical format as the Label Set TLV, see Section 2.5.
このセクションでは、許容可能なラベルセットTLVを定義して、[RFC3471]あたりのラベルエラーに関する通知をサポートします。許容可能なラベルセットTLVは、0x082aのタイプ値を使用します。TLVの残りのコンテンツには、ラベルセットTLVと同一の形式があります。セクション2.5を参照してください。
Acceptable Label Set TLVs may be carried in NOTIFICATION messages. The procedures for defining an Acceptable Label Set follow the procedures for defining a Label Set, see Section 2.5.1. Specifically, an Acceptable Label Set is defined via one or more Acceptable Label Set TLVs. Specific labels/subchannels can be added to or excluded from an Acceptable Label Set via Action zero (0) and one (1) TLVs respectively. Ranges of labels/subchannels can be added to or excluded from an Acceptable Label Set via Action two (2) and three (3) TLVs respectively. When the Acceptable Label Set TLVs only list labels/subchannels to exclude, this implies that all other labels are acceptable.
許容可能なラベルセットTLVは、通知メッセージに携帯する場合があります。許容可能なラベルセットを定義する手順は、ラベルセットを定義するための手順に従ってください。セクション2.5.1を参照してください。具体的には、許容可能なラベルセットは、1つ以上の許容可能なラベルセットTLVを介して定義されます。特定のラベル/サブチャネルは、それぞれアクションゼロ（0）および1つのTLVを介して許容可能なラベルセットに追加または除外できます。ラベル/サブチャネルの範囲は、それぞれアクション2（2）および3（3）TLVを使用して、許容可能なラベルセットに追加または除外できます。許容可能なラベルセットTLVが除外するラベル/サブチャネルのみをリストする場合、これは他のすべてのラベルが許容できることを意味します。
The inclusion of Acceptable Label Set TLVs is optional. If included, the NOTIFICATION message SHOULD contain a "Routing problem/Unacceptable label value" indication. The absence of Acceptable Label Set TLVs does not have any specific meaning.
許容可能なラベルセットTLVを含めることはオプションです。含まれている場合、通知メッセージには「ルーティングの問題/容認できないラベル値」の表示を含める必要があります。許容可能なラベルセットTLVの欠如には、特定の意味がありません。
The Label ER-Hop TLV is defined as follows:
ラベルER-HOP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type (0x0829) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|U| Reserved | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label (continued) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of L, U and Label parameters.
L、U、およびラベルパラメーターの説明については、[RFC3471]を参照してください。
The Label ER-Hop follows a ER-Hop containing the IP address, or the interface identifier [MPLS-UNNUM], associated with the link on which it is to be used. Up to two label ER-Hops may be present, one for the downstream label and one for the upstream label. The following SHOULD result in "Bad EXPLICIT_ROUTE" errors: o If the first label ER-Hop is not preceded by a ER-Hop containing an IP address, or a interface identifier [MPLS-UNNUM], associated with an output link. o For a label ER-Hop to follow a ER-Hop that has the L-bit set. o On unidirectional LSP setup, for there to be a label ER-Hop with the U-bit set. o For there to be two label ER-Hops with the same U-bit values.
ラベルER-HOPは、IPアドレスを含むER-HOP、または使用するリンクに関連付けられたインターフェイス識別子[MPLS-UNNUM]に従います。最大2つのラベルER-HOPSが存在する場合があります。1つは下流ラベル用、もう1つはアップストリームラベル用です。以下は、「bad reblicit_route」エラーになります。o最初のラベルER-HOPの前に、出力リンクに関連付けられたインターフェイス識別子[MPLS-UNNUM]を含むER-HOPが含まれていない場合。oラベルER-HOPの場合、Lビットセットを持つER-HOPに従うこと。o単方向LSPセットアップでは、Uビットセットを備えたラベルER-HOPがあるためです。o同じUビット値を持つ2つのラベルER-HOPSがあります。
To support the label ER-Hop, a node must check to see if the ER-Hop following its associate address/interface is a label ER-Hop. If it is, one ER-Hop is examined for unidirectional LSPs and two ER-Hops for bidirectional LSPs. If the U-bit of the ER-Hop being examined is clear (0), then value of the label is copied into a new Label Set TLV. This Label Set TLV MUST be included on the corresponding outgoing REQUEST message.
ラベルER-HOPをサポートするには、ノードをチェックして、アソシエイトアドレス/インターフェイスに続くER-HOPがラベルER-HOPであるかどうかを確認する必要があります。もしそうなら、1つのER-HOPは、単方向LSPと双方向LSPの2つのER-HOPについて調べられます。検査されているER-HOPのUビットが明確である場合（0）、ラベルの値は新しいラベルセットTLVにコピーされます。このラベルセットTLVは、対応する発信要求メッセージに含める必要があります。
If the U-bit of the ER-Hop being examined is set (1), then value of the label is label to be used for upstream traffic associated with the bidirectional LSP. If this label is not acceptable, a "Bad EXPLICIT_ROUTE" error SHOULD be generated. If the label is acceptable, the label is copied into a new Upstream Label TLV. This Upstream Label TLV MUST be included on the corresponding outgoing REQUEST message.
調査対象のER-HOPのUビットが設定されている場合（1）、ラベルの値は、双方向LSPに関連する上流トラフィックに使用されるラベルです。このラベルが受け入れられない場合は、「bad reblicit_route」エラーを生成する必要があります。ラベルが許容される場合、ラベルは新しいアップストリームラベルTLVにコピーされます。このアップストリームラベルTLVは、対応する発信要求メッセージに含める必要があります。
After processing, the label ER-Hops are removed from the ER.
処理後、ラベルER-HOPSはERから削除されます。
Note an implication of the above procedures is that the label ER-Hop should never be the first ER-Hop in a newly received message. If the label ER-Hop is the first ER-Hop an a received ER, then it SHOULD be treated as a "Bad strict node" error.
上記の手順の意味は、ラベルER-HOPが新しく受け取ったメッセージの最初のERホップではないことです。ラベルER-HOPが最初のER-HOP A a受信ERである場合、「悪い厳格なノード」エラーとして扱う必要があります。
Procedures by which an LSR at the head-end of an LSP obtains the information needed to construct the Label ER-Hop are outside the scope of this document.
LSPのヘッドエンドにあるLSRが、ラベルER-HOPを構築するために必要な情報を取得する手順は、このドキュメントの範囲外です。
The use of the Protection TLV is optional. The TLV is included to indicate specific protection attributes of an LSP.
保護TLVの使用はオプションです。TLVは、LSPの特定の保護属性を示すために含まれています。
The format of Protection Information TLV is:
保護情報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| Type (0x0835) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
パラメーターの説明については、[RFC3471]を参照してください。
Transit nodes processing a REQUEST message containing a Protection TLV MUST verify that the requested protection can be satisfied by the outgoing interface or tunnel (FA). If it cannot, the node MUST generate a NOTIFICATION message, with a "Routing problem/Unsupported Link Protection" indication.
TLVを含むリクエストメッセージの処理TLVを処理するトランジットノードは、発信インターフェイスまたはトンネル（FA）によって要求された保護が満たされる可能性があることを確認する必要があります。できない場合は、ノードが「ルーティングの問題/サポートされていないリンク保護」を備えた通知メッセージを生成する必要があります。
Administrative Status Information is carried in the Admin Status TLV. The TLV provides information related to the administrative state of a particular LSP. The information is used in two ways. In the first, the TLV is carried in REQUEST and MAPPING messages to indicate the administrative state of an LSP. In the second, the TLV is carried in Notification message to request a change to the administrative state of an LSP.
管理ステータス情報は、管理者ステータスTLVで伝えられます。TLVは、特定のLSPの管理状態に関連する情報を提供します。情報は2つの方法で使用されます。最初に、TLVはリクエストとマッピングメッセージに携帯されており、LSPの管理状態を示します。2番目に、TLVは通知メッセージに携帯されており、LSPの管理状態への変更を要求します。
The use of the Admin Status TLV is optional. It uses Type = 0x082b. The format of the TLV is:
Admin Status TLVの使用はオプションです。type = 0x082bを使用します。TLVの形式は次のとおりです。
The format of Admin Status TLV in REQUEST, MAPPING and Notification Messages is:
リクエスト、マッピング、通知メッセージの管理ステータス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| Type (0x082b) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
パラメーターの説明については、[RFC3471]を参照してください。
The Admin Status TLV is used to notify each node along the path of the status of the LSP. Each node processes status information based on local policy and then propagated in the corresponding outgoing messages. The TLV is inserted in REQUEST messages at the discretion of the ingress node. The absence of the TLV is the equivalent to receiving a TLV containing values all set to zero.
管理ステータスTLVは、LSPのステータスのパスに沿った各ノードに通知するために使用されます。各ノードは、ローカルポリシーに基づいてステータス情報を処理し、対応する発信メッセージに伝播します。TLVは、イングレスノードの裁量でリクエストメッセージに挿入されます。TLVの欠如は、すべてゼロに設定されたTLVを含む値を受信することと同等です。
Transit nodes receiving a REQUEST message containing an Admin Status TLV, update their local state, take any appropriate local action based on the indicated status and then propagate the received Admin Status TLV in the outgoing REQUEST message.
管理ステータスTLVを含む要求メッセージを受信するトランジットノード、ローカル状態を更新し、指定されたステータスに基づいて適切なローカルアクションを実行し、発信リクエストメッセージで受信した管理者ステータスTLVを伝播します。
Edge nodes receiving a REQUEST message containing an Admin Status TLV, also update their local state and take any appropriate local action based on the indicated status. When the ADMIN Status TLV is received with the R bit set, the receiving edge node should reflect the received values in a corresponding MAPPING message. Specifically, if an egress node receives a Request message with the R bit of the Admin_Status TLV set and the node the node SHOULD send a Mapping message containing an Admin_Status TLV with the same values set, with the exception of the R bit, as received in the corresponding Request message.
Admin Status TLVを含む要求メッセージを受信するエッジノードは、現地の状態を更新し、指定されたステータスに基づいて適切なローカルアクションを実行します。Admin Status TLVがRビットセットで受信されると、受信エッジノードは、対応するマッピングメッセージの受信値を反映する必要があります。具体的には、出力ノードがAdmin_Status TLVセットのRビットを使用してリクエストメッセージを受信し、ノードはノードが同じ値を除いて、同じ値を除いてAdmin_Status TLVを含むマッピングメッセージを送信する必要があります。対応するリクエストメッセージ。
In some circumstances, particularly optical networks, it is useful to set the administrative status of an LSP before tearing it down.
状況によっては、特に光学ネットワークでは、LSPの管理ステータスを引き裂く前に設定すると便利です。
In such circumstances the procedure SHOULD be followed when deleting an LSP from the ingress:
このような状況では、入り口からLSPを削除するときに手順に従う必要があります。
o The ingress node precedes an LSP deletion by inserting an Admin Status TLV in a Notification Message setting the Reflect (R) and Delete (D) bits.
o Ingressノードは、refferm（r）と削除（d）ビットを設定する通知メッセージに管理者ステータスTLVを挿入することにより、LSP削除の前にあります。
o Transit nodes process the Admin Status TLV by passing the Notification message. The egress node May respond with a Notification message with the Admin Status TLV.
o トランジットノード通知メッセージを渡すことにより、管理者ステータスTLVを処理します。出力ノードは、管理者ステータスTLVを使用して通知メッセージで応答する場合があります。
o Upon receiving the Admin Status TLV with the Delete (D) bit set in the Notification message, the egress SHOULD respond with a LABEL WITHDRAW message and normal CR-LDP processing takes place.
o 通知メッセージにdelete（d）ビットが設定された管理ステータスTLVを受信すると、出力はラベルの引き出しメッセージで応答する必要があり、通常のCR-LDP処理が行われます。
In such circumstances the procedure SHOULD be followed when deleting an LSP from the egress: o The egress node indicates its desire for deletion by inserting an Admin Status TLV in a Notification message and setting Delete (D) bit.
このような状況では、出力からLSPを削除するときに手順に従う必要があります。O出力ノードは、通知メッセージに管理ステータスTLVを挿入し、削除（d）ビットを設定することにより、削除の要望を示します。
o Transit nodes process the Admin Status TLV as described above.
o トランジットノードは、上記のように管理者ステータスTLVを処理します。
o Upon receiving the Admin Status TLV with the Delete (D) bit set in the Notification message, the ingress node sends a LABEL RELEASE message downstream to remove the LSP and normal CR-LDP processing takes place.
o 通知メッセージにdelete（d）ビットが設定された管理ステータスTLVを受信すると、IngressノードはLSPを削除するためにラベルリリースメッセージを下流に送信し、通常のCR-LDP処理が行われます。
Subsequent messaging Admin Status messaging may be performed by Notification Messages. The ingress may begin the propagation of a Notification Message with an Admin Status TLV. Each subsequent node propagates the Notification with the Admin Status TLV from the ingress to the egress and then the egress node returns the Notification messages back Upstream carrying the Admin Status TLV.
後続のメッセージング管理者ステータスメッセージは、通知メッセージによって実行される場合があります。侵入は、管理者ステータスTLVを使用して通知メッセージの伝播を開始する場合があります。後続の各ノードは、侵入から出口への管理者ステータスTLVで通知を伝播し、Egressノードは、管理者ステータスTLVを運ぶ通知メッセージを上流に戻します。
Intermediate and egress nodes may trigger the setting of administrative status via the use of Notification messages. To accomplish this, an intermediate or egress node generates a Notification message with the corresponding upstream notify session information. The Admin Status TLV MUST be included in the session information, with the appropriate bit or bits set. The Reflect (R) bit MUST NOT be set.
中間ノードと出口ノードは、通知メッセージを使用して管理ステータスの設定をトリガーする場合があります。これを達成するために、中間または出口ノードは、対応する上流の通知セッション情報を使用して通知メッセージを生成します。管理ステータスTLVは、適切なビットまたはビットが設定されたセッション情報に含める必要があります。反射（r）ビットを設定してはなりません。
An ingress or egress node receiving a Notification message containing an Admin Status TLV with the Delete (D) bit set, SHOULD initiate the deletion procedure described in the previous section.
delete（d）ビットセットを使用して管理者ステータスTLVを含む通知メッセージを受信するイングレスまたは出力ノードは、前のセクションで説明した削除手順を開始する必要があります。
Some special processing is required in order to cover the case of nodes that do not support the Admin Status TLV and other error conditions. Specifically, a node that sends a Notification message containing an Admin Status TLV with the Down (D) bit set MUST verify that it receives a corresponding LABEL RELEASE message within a configurable period of time. By default this period of time SHOULD be 30 seconds. If the node does not receive such a LABEL RELEASE message, it SHOULD send a Label Release message downstream and a LABEL WITHDRAW message upstream.
管理者ステータスTLVおよびその他のエラー条件をサポートしていないノードのケースをカバーするために、いくつかの特別な処理が必要です。具体的には、down（d）ビット設定を使用して管理者ステータスTLVを含む通知メッセージを送信するノードは、構成可能な期間内に対応するラベルリリースメッセージを受信することを確認する必要があります。デフォルトでは、この期間は30秒でなければなりません。ノードがそのようなラベルリリースメッセージを受信しない場合、ラベルリリースメッセージを下流に送信し、ラベルを上流に撤回する必要があります。
This section provides the protocol specific formats and procedures to required support a control channel not being in-band with a data channel.
このセクションでは、データチャネルを使用して帯域内にないことをサポートする必要があるコントロールチャネルをサポートするためのプロトコル固有の形式と手順を提供します。
The choice of the data interface to use is always made by the sender of the REQUEST message. The choice of the data interface is indicated by the sender of the REQUEST message by including the data channel's interface identifier in the message using a new Interface TLV type. For bidirectional LSPs, the sender chooses the data interface in each direction. In all cases but bundling, the upstream interface is implied by the downstream interface. For bundling, the REQUEST sender explicitly identifies the component interface used in each direction.
使用するデータインターフェイスの選択は、常にリクエストメッセージの送信者によって行われます。データインターフェイスの選択は、新しいインターフェイスTLVタイプを使用してメッセージにデータチャネルのインターフェイス識別子をメッセージに含めることにより、リクエストメッセージの送信者によって示されます。双方向LSPの場合、送信者は各方向にデータインターフェイスを選択します。バンドリング以外のすべての場合、上流のインターフェイスはダウンストリームインターフェイスによって暗示されます。バンドリングの場合、リクエスト送信者は、各方向で使用されるコンポーネントインターフェイスを明示的に識別します。
The format of IPV4 Interface ID in REQUEST, MAPPING Messages is:
リクエストのIPv4インターフェイスIDの形式、マッピングメッセージは次のとおりです。
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| Type (0x082d) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID TLVS see [RFC3471] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of IPV6 Interface ID TLV in REQUEST, MAPPING Messages is:
リクエストのIPv6インターフェイスID 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| Type (0x082e) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID TLVS see [RFC3471] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
See [RFC3212] for a description of signaling address. See [RFC3471] for a description of parameters and encoding of TLVs.
信号アドレスの説明については、[RFC3212]を参照してください。TLVのパラメーターとエンコードの説明については、[RFC3471]を参照してください。
An IF_ID TLV is used on links where there is not a one-to-one association of a control channel to a data channel, see [RFC3471].
IF_ID TLVは、コントロールチャネルとデータチャネルとの1対1の関連性がないリンクで使用されます。[RFC3471]を参照してください。
The LDP session uses the IF_ID TLV to identify the data channel(s) associated with the LSP. For a unidirectional LSP, a downstream data channel MUST be indicated. For bidirectional LSPs, a common downstream and upstream data channel is normally indicated. In the special case where a bidirectional LSP that traverses a bundled link, it is possible to specify a downstream data channel that differs from the upstream data channel. Data channels are specified from the viewpoint of the sender of a REQUEST message. The IF_ID TLV SHOULD NOT be used when no TLVs are needed.
LDPセッションでは、IF_ID TLVを使用して、LSPに関連付けられたデータチャネルを識別します。単方向LSPの場合、下流のデータチャネルを示す必要があります。双方向LSPの場合、一般的に下流および上流のデータチャネルが通常示されています。バンドルされたリンクを通過する双方向LSPが、上流のデータチャネルとは異なる下流のデータチャネルを指定する特別なケースでは。データチャネルは、リクエストメッセージの送信者の視点から指定されています。IF_ID TLVは、TLVが不要な場合は使用しないでください。
A node receiving one or more IF_ID TLVs in a REQUEST message saves their values and returns them in the subsequent MAPPING message sent to the node that originated the TLVs.
要求メッセージで1つ以上のif_id TLVを受信するノードは、値を保存し、TLVを発信するノードに送信される後続のマッピングメッセージでそれらを返します。
Note, the node originating an IF_ID TLV MUST ensure that the selected outgoing interface, as specified in the IF_ID TLV, is consistent with an ERO. A node that receives an IF_ID TLV SHOULD check whether the information carried in this TLV is consistent with the information carried in a received ERO, and if not it MUST send a LABEL ABORT Message with the error code "Routing Error" and error value of "Bad Explicit Routing TLV Error" toward the sender. This check CANNOT be performed when the initial ERO subobject is not the incoming interface.
IF_ID TLVを発信するノードは、IF_ID TLVで指定されているように、選択した発信インターフェイスがEROと一致していることを確認する必要があります。IF_ID TLVを受信するノードは、このTLVで伝えられる情報が受信したEROで伝えられる情報と一致しているかどうかを確認する必要があります。Senderに向けて、悪い明示的なルーティングTLVエラー」。このチェックは、最初のEROサブオブジェクトが着信インターフェイスではない場合に実行できません。
There are cases where it is useful to indicate a specific interface associated with an error. To support these cases the IF_ID Status TLV are defined.
エラーに関連付けられた特定のインターフェイスを示すことが有用な場合があります。これらのケースをサポートするために、IF_IDステータスTLVが定義されています。
The format of the IPv4 IF_ID Status TLV is:
IPv4 if_id status 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| Type (0x082f) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 IF_ID Status TLV is:
IPv6 if_id status 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| Type (0x0830) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Error Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3036] for a description of status code value fields. See [RFC3471] for a description of parameters and encoding of TLVs.
ステータスコード値フィールドの説明については、[RFC3036]を参照してください。TLVのパラメーターとエンコードの説明については、[RFC3471]を参照してください。
Nodes wishing to indicate that an error is related to a specific interface SHOULD use the appropriate IF_ID Status TLV in the corresponding LABEL WITHDRAW or LABEL RELEASE message. IF_ID Status TLV SHOULD be generated and processed as any other Status TLV, see [RFC3036].
エラーが特定のインターフェイスに関連していることを示したいノードは、対応するラベルの撤回またはラベルのリリースメッセージで適切なif_idステータスTLVを使用する必要があります。IF_IDステータスTLVは、他のステータスTLVとして生成および処理する必要があります。[RFC3036]を参照してください。
In optical transport networks, failures in the out-of-fiber signaling communication or optical control plane should not have service impact on the existing optical connections. Under such circumstances, a mechanism MUST exist to detect a signaling communication failure and a recovery procedure SHALL guarantee connection integrity at both ends of the signaling channel.
光学輸送ネットワークでは、ファイバー外シグナリング通信または光学制御プレーンの障害は、既存の光接続にサービスに影響を与えるべきではありません。このような状況では、シグナル伝達通信の障害を検出するためのメカニズムが存在する必要があり、回復手順は、シグナリングチャネルの両端で接続の完全性を保証するものとします。
The LDP Fault tolerant document [LDP-FT] specifies the procedures for recovering LDP and CR-LDP sessions under failure. Please refer to his document for procedures on recovering optical connections. Currently the Fault tolerant document covers many of the common failure modes for a separated control and data plane.
LDPフォールトトレラントドキュメント[LDP-FT]は、障害下でLDPおよびCR-LDPセッションを回復する手順を指定します。光接続の回復に関する手順については、彼の文書を参照してください。現在、フォールトトレラントドキュメントは、分離された制御およびデータプレーンの一般的な障害モードの多くをカバーしています。
This document is the work of numerous authors and consists of a composition of a number of previous documents in this area.
このドキュメントは多くの著者の作品であり、この分野の多くの以前のドキュメントの構成で構成されています。
Valuable comments and input were received from a number of people, notably Adrian Farrel.
貴重なコメントと意見は、多くの人々、特にエイドリアン・ファレルから受け取られました。
This document introduces no new security considerations to [RFC3212].
このドキュメントでは、[RFC3212]に新しいセキュリティ上の考慮事項を紹介しません。
This document uses the LDP [RFC3036] name spaces, see http://www.iana.org/assignments/ldp-namespaces, which lists the assignments for the following TLVs:
このドキュメントでは、LDP [RFC3036]名前スペースを使用しています。http://www.iana.org/assignments/ldp-namespacesを参照してください。次のTLVの割り当てをリストします。
o Generalized Label Request (TLV 0x0824) o Generalized Label (TLV 0x0825) o Upstream Label (TLV 0x0826) o Label Set (TLV 0x0827) o Waveband Label (TLV 0x0828) o ER-Hop (TLV 0x0829) o Acceptable Label Set (TLV 0x082a) o Admin Status (TLV 0x082b) o Interface ID (TLV 0x082c) o IPV4 Interface ID (TLV 0x082d) o IPV6 Interface ID (TLV 0x082e) o IPv4 IF_ID Status (TLV 0x082f) o IPv6 IF_ID Status (TLV 0x0830) o Protection (TLV 0x0835)
o 一般化ラベル要求（TLV 0x0824）o一般化ラベル（TLV 0x0825）oアップストリームラベル（TLV 0x0826）oラベルセット（TLV 0x0827）o波路ラベル（TLV 0x0828）o er-Hop（TLV 0x0829）o許容ラベルセット（TLV 0x082A）o管理ステータス（TLV 0x082B）oインターフェイスID（TLV 0x082C）o IPv4インターフェイスID（TLV 0x082D）o IPv6インターフェイスID（TLV 0x082E）o IPv4 IF_IDステータス（TLV 0x082F）o IPv6 if_id（TLV 0x0830）TLV 0x0835）
This section is taken from Section 10.4 of [RFC2026].
このセクションは、[RFC2026]のセクション10.4から取得されます。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実践するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待します。情報をIETFエグゼクティブディレクターに宛ててください。
[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、RFC2119。1997年3月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。and B. Thomas、「LDP仕様」、RFC 3036、2001年1月。
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[RFC3212] Jamoussi、B.、Andersson、L.、Callon、R.、Dantu、R.、Wu、L.、Doolan、P.、Worster、T.、Feldman、N.、Fredette、A.、Girish、M.、Gray、E.、Heinanen、J.、Kilty、T。、およびA. Malis、「LDPを使用した制約ベースのLSPセットアップ」、RFC 3212、2002年1月。
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、編集者、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[LDP-FT] Farrel, A., et al, "Fault Tolerance for LDP and CR-LDP", Work in Progress.
[LDP-FT] Farrel、A.、et al、「LDPおよびCR-LDPに対するフォールトトレランス」は、進行中の作業。
[MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with MPLS TE", Work in Progress.
[MPLS-Hierarchy] Kompella、K。およびY. Rekhter、「MPLS TEとのLSP階層」、進行中の作業。
[MPLS-UNNUM] Kompella, K., Rekhter, Y. and A. Kullberg, "Signalling Unnumbered Links in CR-LDP", Work in Progress.
[MPLS-UNNUM] Kompella、K.、Rekhter、Y。およびA. Kullberg、「CR-LDPでの数のリンクのシグナリング」、進行中の作業。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、編集者、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達 - リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
Peter Ashwood-Smith Nortel Networks Corp. P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7 Canada
Peter Ashwood-Smith Nortel Networks Corp. P.O.ボックス3511ステーションC、オタワ、K1Y 4H7カナダ
Phone: +1 613 763 4534
EMail: petera@nortelnetworks.com
Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose, CA 95138
Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose、CA 95138
Phone: +1 408 972-3645 EMail: abanerjee@calient.net Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
電話：1 408 972-3645メール：abanerjee@calient.netルーバーガーMovaz Networks、Inc。7926 Jones Branch Drive Suite 615 McLean VA、22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Greg Bernstein EMail: gregb@grotto-networking.com
Greg Bernsteinメール：gregb@grotto-networking.com
Yanhe Fan Axiowave Networks, Inc. 200 Nickerson Road Marlborough, MA 01752
YanheファンAxiowave Networks、Inc。200 Nickerson Road Marlborough、MA 01752
Phone: + 1 774 348 4627
EMail: yfan@axiowave.com
Don Fedyk Nortel Networks Corp. 600 Technology Park Billerica MA 01821
Don Fedyk Nortel Networks Corp. 600 Technology Park Billerica MA 01821
Phone: +1 978 288 3041
Fax: +1 978 288 0620
EMail: dwfedyk@nortelnetworks.com
Jonathan P. Lang EMail: jplang@ieee.org
Jonathan P. Langメール：jplang@ieee.org
Eric Mannie Independent Consultant 2 Avenue de la Folle Chanson 1050 Brussels Belgium
エリックマニー独立コンサルタント2アベニューデラフォルチャンソン1050ブリュッセルベルギー
EMail: eric_mannie@hotmail.com
Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Phone: +1 732 923 4237
Fax: +1 732 923 9804
EMail: braja@tellium.com
Debanjan Saha EMail: debanjan@acm.org
Debanjan Sahaメール：debanjan@acm.org
Vishal Sharma Metanoia, Inc. 1600 Villa Street, Unit 352 Mountain View, CA 94041-1174
Vishal Sharma Metanoia、Inc。1600 Villa Street、Unit 352 Mountain View、CA 94041-1174
Phone: +1 650-386-6723
EMail: v.sharma@ieee.org
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824
George Swallow Cisco Systems、Inc。250 Apollo Drive Chelmsford、MA 01824
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Z. Bo Tang EMail: botang01@yahoo.com
Z. Bo Tang Email：botang01@yahoo.com
Peter Ashwood-Smith Nortel Networks Corp. P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7 Canada
Peter Ashwood-Smith Nortel Networks Corp. P.O.ボックス3511ステーションC、オタワ、K1Y 4H7カナダ
Phone: +1 613 763 4534
EMail: petera@nortelnetworks.com
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
Lou Berger Movaz Networks、Inc。7926 Jones Branch Drive Suite 615 McLean VA、22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。