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.
著作権（C）インターネット協会（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は時分割（例えば、同期光ネットワークと同期デジタル・ハイアラーキ、SONET / SDH）、波長（光ラムダ）と空間スイッチング（出力ポートまたはファイバ例えば、着信ポートまたはファイバ）を包含するMPLSコントロールプレーンを拡張します。このドキュメントは、拡張子の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].
時分割多重（TDM）、ラムダ・スイッチ（LSC）およびファイバ・スイッチ（FSC）：一般MPLSは、パケット（PSC）インタフェースをサポートし、インタフェースおよびスイッチングの3つの新しいクラスのサポートが含まれるように切り替えからMPLSを拡張します。インターフェイスと切り替えの新しいクラスをサポートするために必要な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特定のバージョンは、セクション4 [RFC3473]を参照して、迅速な障害通知用のRSVP特定のサポートを含むことに留意すべきです。 CR-LDPのための同様の機構は現在存在しません。故障が検出された場合には、RELEASE /障害の点から半径方向外向きメッセージを撤回して伝播されるであろう。リソースは、この段階で放出されるように、実際のリソース情報は、フィードバック機構を使用してソースに供給することができるされています。
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 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.
要求メッセージは、トランジットのLSRによってスイッチングに最大限の柔軟性を可能にするためにできるだけ特定LSP（ラベルスイッチパス）、符号化タイプを含むべきです。一般化ラベル要求タイプ、長さ、および値（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とき最後から二番目のホップのポッピング（PHP）が要求された場合に、最後から二番目のホップはまた、マッピングメッセージの処理中（記憶）G-PIDを調べます。 G-PIDがサポートされていない場合この場合には、次に最後から二番目のホップは、「ルーティング問題/許可されないラベル値」表示と通知メッセージを生成しなければなりません。生成された通知メッセージは、セクション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の両方の存在は、プロトコルエラーであり、受信者によって不正なメッセージとして扱わなければなりません。
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.
波長群スイッチングは、セクション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での開始と終了ラベルが新しい波長帯のIDでラベルTLVを転送する前に入れ替えなければなりません。このようにして反転し、これらの値を持つ波長帯のラベルを受け取る出口/入口LSRは、それはまた、適切な波長をピックアップして、その出口の関連を反転しなければならないことを知っています。この機構なしでミラースイッチング動作の奇数と、出口LSRsは、たとえばL1の入力波長がL100として波長帯トンネルから出てくることを知らないであろう。
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.
提案されたラベルの形式は、一般的なラベルと同じです。それは、REQUESTメッセージに使用されています。推奨ラベルは、タイプ= 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
ラベルタイプ：14ビット
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を介して設定されたラベルから除外することができます。ラベル設定のTLVのみを除外するためのラベル/サブチャネルのリストを表示する場合、これは他のすべてのラベルが許容されていることを意味します。
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.
REQUESTメッセージを受信すると、受信ノードは、ラベルセットである1へのラベルのその選択を、制限されます。また、REQUESTメッセージを転送する前に設定ラベルを除去することができるラベル変換を行うことが可能なノード。ノードは、ラベルセットからラベルを選択することができないか、ラベルの設定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.
REQUESTメッセージを受信すると、メッセージに示さラベルセットは、ダウンストリームインターフェースで利用可能なラベルと設定要求メッセージで転送され得交差ラベルのセットと比較されます。結果としてラベルのセットが空の場合は、要求が終了しなければならない、と通知メッセージ、および「ルーティング問題/ラベルセット」表示が生成されなければなりません。結果として、それらが一貫した物理的意味を有するようにこれらの値をマッピングするノードの責任であり、その交差点が異なるリンク上の異なる論理値を有することができる物理的ラベル（実際の波長/帯域値）に基づいている（注）、またはいかなる適切な論理ラベル値が存在しない場合のセットから特定の値を削除します。
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.
中間ノードは、発信インターフェイス上でラベルを割り当て、発信上流のラベルに記入し、REQUESTメッセージを伝播する前に、内部データ経路を確立しなければなりません。中間ノードは、ラベルまたは内部リソースを割り当てることができない場合、それは「ルーティング問題/ラベル割り当て失敗」表示と通知メッセージを発行しなければなりません。
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.
このセクションでは、[RFC3471]あたりのラベルエラーの通知をサポートするために許容可能なラベル設定TLVを定義します。許容可能なラベルを設定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つの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ホップ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ホップIPアドレス、またはそれが使用されるのリンクに関連付けられたインタフェース識別子[MPLS-UNNUM]を含むERホップに従います。 2ラベルER-ホップまで、下流のラベル用と上流のラベルのための1つの存在することができます。 「悪いEXPLICIT_ROUTE」エラーをもたらすはずである次の最初のラベルERホップを出力リンクに関連付けられたIPアドレス、またはインタフェース識別子[MPLS-UNNUM]を含むERホップによって先行されていない場合はO・OラベルERホップのためにLビットがセットされているERホップに従います。 O単方向LSP設定では、そこのラベルERホップUビットのセットであることを。そこについては同一のUビット値を有する2つのラベルERホップすることがO。
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ホップをサポートするために、ノードはERホップはその仲間アドレスを以下かどうかを確認する必要があります/インタフェースは、ラベルERホップです。もしそうであれば、1つのERホップは、単方向のLSPと双方向のLSP用の2つのER-ホップを調べています。検査されているERホップの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ホップが検査されるのUビットは、（1）設定されている場合、ラベルの値は、双方向LSPに関連付けられたアップストリームトラフィックに使用されるラベルです。このラベルが受け入れられない場合は、「悪いEXPLICIT_ROUTE」エラーが生成されるべきです。ラベルが許容される場合は、ラベルが新しい上流のラベルTLVにコピーされます。この上流のラベルTLVは、対応する発信要求メッセージに含まれなければなりません。
After processing, the label ER-Hops are removed from the ER.
処理の後、ラベルER-ホップは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ホップは、新たに受信したメッセージの最初のERホップしてはいけませんということです。ラベルERホップは最初のERホップ受け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ホップを構築するために必要な情報を取得することにより、手順は、このドキュメントの範囲外です。
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を含む要求メッセージを処理するトランジットノードは、要求された保護は、発信インターフェースまたはトンネル（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の管理状態を示すためにREQUESTおよびマッピングメッセージで運ばれます。第二に、TLVは、LSPの管理状態の変更を要求する通知メッセージで搬送されます。
The use of the Admin Status TLV is optional. It uses Type = 0x082b. The format of the TLV is:
管理ステータスTLVの使用はオプションです。これは、Type = 0x082bを使用しています。 TLVの形式は次のとおりです。
The format of Admin Status TLV in REQUEST, MAPPING and Notification Messages is:
REQUEST、マッピングおよび通知メッセージのAdminステータス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.
管理ステータスTLVを含む要求メッセージを受信したエッジノードは、また、それらのローカル状態を更新し、指示された状態に基づいて、任意の適切なローカルアクションを取ります。 ADMIN状態TLVはRビットがセットで受信された場合、受信エッジノードは、対応するマッピング・メッセージで受信された値を反映すべきです。出口ノードがADMIN_STATUS TLVセットとノードのRビットを有するリクエストメッセージを受信した場合に受信されるよう具体的には、ノードは、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（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削除（D）で管理状態TLVを受信すると、通知メッセージに設定されたビット、出力メッセージと正常CR-LDP処理が行わWITHDRAW LABELで応答すべきです。
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を削除する場合、このような状況の手順に従う必要があり：出口ノードは、通知メッセージに管理ステータスTLVを挿入し、削除（D）ビットを設定することにより、削除のためにその要望を示しO・
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削除（D）で管理状態TLVを受信すると、通知メッセージに設定されたビット、入口ノードは、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で通知を伝播した後、出口ノードは、上流の管理ステータス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.
削除（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や他のエラー状態をサポートしていないノードの場合をカバーするために必要とされます。具体的には、設定可能な期間内に対応するラベル解放メッセージを受信することを確認しなければならないダウン（D）ビットが設定された管理状態TLVを含む通知メッセージを送信するノード。デフォルトでは、この時間は30秒であるべきです。ノードは、このようなラベル解放メッセージを受信しない場合、下流のラベル解放メッセージを送るべきであるとLABELは、メッセージを上流WITHDRAW。
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.
使用するデータ・インタフェースの選択は、常にREQUESTメッセージの送信者によって行われます。データインタフェースの選択は、新しいインターフェースTLVのタイプを使用して、メッセージ内のデータチャネルのインタフェース識別子を含めることによって、リクエストメッセージの送信者によって示されています。双方向のLSPのために、送信者は、各方向のデータインタフェースを選択します。全ての場合しかし結束において、上流インターフェースは、下流インタフェースによって暗示されています。束ねるため、リクエスト送信者が明示的に各方向に使用されるコンポーネント・インタフェースを識別する。
The format of IPV4 Interface ID in REQUEST, MAPPING Messages is:
REQUEST、マッピング・メッセージ内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:
REQUEST、マッピングメッセージで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.
パラメータの説明については、[RFC3471]を参照してください。
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は、データチャネルに対する制御チャネルの一対一の関連がない、[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セッションがLSPに関連するデータ・チャネル（複数可）を識別するためにIF_ID TLVを使用します。一方向LSPのため、下りデータチャネルが示されなければなりません。双方向のLSPのために、共通のダウンストリームおよびアップストリームデータチャネルが正常に示されています。バンドルリンクを横断する双方向LSP特別な場合には、上りデータチャネルとは異なる下りデータチャネルを指定することが可能です。データチャネルは、要求メッセージの送信者の観点から規定されています。何のTLVが必要とされていない場合IF_ID 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.
REQUESTメッセージ内の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で運ばれた情報と一致しているかどうかを確認する必要があり、そうでない場合には、「エラーコード「ルーティングエラー」と誤差値とLABELのABORTメッセージを送信しなければなりません送信者の方へ悪い明示的なルーティング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ステータス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ステータス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].
エラーは、特定のインタフェースに関連していることを示すことを望むノードは、WITHDRAW対応するラベルに適切なIF_ID状態TLVを使用するか、ラベル解放メッセージべきです。 IF_ID状態TLVは、[RFC3036]を参照して生成され、他のステータスTLVとして処理されるべきです。
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:
この文書は、次のTLVのための割り当てを示しており、http://www.iana.org/assignments/ldp-namespacesを参照してくださいLDP [RFC3036]名前空間を使用しています。
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 ERホップ（TLV 0x0829）O一般化ラベル〇〇一般化ラベル要求（TLV 0x0824）（TLV 0x0825）O上流ラベル（TLV 0x0826）Oラベルセット（TLV 0x0827）O波帯ラベル（TLV 0x0828）（TLV 0x082a）保護O IPv6のIF_IDステータスOのIPv4 IF_IDステータス（TLVの0x082f）O IPv6インタフェースID（TLVの0x082e）O IPV4インタフェースID（TLVの0x082d）O管理ステータス（TLV 0x082b）OインタフェースID（TLVの0x082c）（TLV 0x0830）O （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]ブラドナーの、S.、 "要件レベルを示すためのRFCsにおける使用のためのキーワード、" BCP 14、RFC 2119 1997年3月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.およびB.トーマス、 "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.、アンダーソン、L.、Callon、R.、Dantu、R.、ウー、L.、Doolan、P.、Worster、T.、フェルドマン、N.、Fredette、A.、Girish、 M.、グレー、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]バーガー、L.、エディタ、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。
[LDP-FT] Farrel, A., et al, "Fault Tolerance for LDP and CR-LDP", Work in Progress.
[LDP-FT]ファレル、A.、ら、 "LDPやCR-LDPのためのフォールトトレランス"、ProgressのWork。
[MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with MPLS TE", Work in Progress.
[MPLS階層] Kompella、K.、およびY. Rekhter、 "MPLS TE LSPと階層"、ProgressのWork。
[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]ブラドナーの、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]バーガー、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
ピーター・アッシュウッド・スミスノーテルネットワークス株式会社の私書箱K1Y 4H7カナダONボックス3511駅のC、オタワ、
Phone: +1 613 763 4534 EMail: petera@nortelnetworks.com
電話：+1 613 763 4534 Eメール：petera@nortelnetworks.com
Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose, CA 95138
アヤンバネルジーCalientネットワーク5853ルーフェラーリカリフォルニア州サンノゼ95138
Phone: +1 408 972-3645 EMail: abanerjee@calient.net
電話：+1 408 972-3645 Eメール：abanerjee@calient.net
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
ルー・バーガーMovazネットワークス株式会社7926ジョーンズ支店ドライブスイート615マクリーンVA、22102
Phone: +1 703 847-1801 EMail: lberger@movaz.com
電話：+1 703 847-1801 Eメール：lberger@movaz.com
Greg Bernstein EMail: gregb@grotto-networking.com
グレッグバーンスタインEメール：gregb@grotto-networking.com
Yanhe Fan Axiowave Networks, Inc. 200 Nickerson Road Marlborough, MA 01752
YanheファンAxiowaveネットワークス株式会社200ニッカーソン道路マールボロ、MA 01752
Phone: + 1 774 348 4627 EMail: yfan@axiowave.com
電話：+ 1 774 348 4627 Eメール：yfan@axiowave.com
Don Fedyk Nortel Networks Corp. 600 Technology Park Billerica MA 01821
ドン・ルブランノーテルネットワークス株式会社600テクノロジーパークビレリカMA 01821
Phone: +1 978 288 3041 Fax: +1 978 288 0620 EMail: dwfedyk@nortelnetworks.com
電話：+1 978 288 3041ファックス：+1 978 288 0620 Eメール：dwfedyk@nortelnetworks.com
Jonathan P. Lang EMail: jplang@ieee.org
ジョナサンP.ラングEメール：jplang@ieee.org
Eric Mannie Independent Consultant 2 Avenue de la Folle Chanson 1050 Brussels Belgium
エリック・マニー独立コンサルタントマッドソング1050ブリュッセルベルギーの2アベニュー
EMail: eric_mannie@hotmail.com
メールアドレス：eric_mannie@hotmail.com
Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901
バラRajagopalan Tellium、Inc.の2クレセント置き私書箱ボックス901 Oceanport、NJ 07757から0901
Phone: +1 732 923 4237 Fax: +1 732 923 9804 EMail: braja@tellium.com
電話：+1 732 923 4237ファックス：+1 732 923 9804 Eメール：braja@tellium.com
Debanjan Saha EMail: debanjan@acm.org
DebanjanサハEメール：debanjan@acm.org
Vishal Sharma Metanoia, Inc. 1600 Villa Street, Unit 352 Mountain View, CA 94041-1174
ヴィシャル・シャルマMetanoia、Inc.の1600ヴィラ・ストリート、ユニット352マウンテンビュー、カリフォルニア州94041から1174
Phone: +1 650-386-6723 EMail: v.sharma@ieee.org
電話：+1 650-386-6723電子メール：v.sharma@ieee.org
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824
ジョージツバメシスコシステムズ社250アポロドライブチェルムズフォード、MA 01824
Phone: +1 978 244 8143 EMail: swallow@cisco.com
電話：+1 978 244 8143 Eメール：swallow@cisco.com
Z. Bo Tang EMail: botang01@yahoo.com
Z.ボー唐Eメール：botang01@yahoo.com
Peter Ashwood-Smith Nortel Networks Corp. P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7 Canada
ピーター・アッシュウッド・スミスノーテルネットワークス株式会社の私書箱K1Y 4H7カナダONボックス3511駅のC、オタワ、
Phone: +1 613 763 4534 EMail: petera@nortelnetworks.com
電話：+1 613 763 4534 Eメール：petera@nortelnetworks.com
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
ルー・バーガーMovazネットワークス株式会社7926ジョーンズ支店ドライブスイート615マクリーンVA、22102
Phone: +1 703 847-1801 EMail: lberger@movaz.com
電話：+1 703 847-1801 Eメール：lberger@movaz.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。