Network Working Group L. Berger, Editor
Request for Comments: 3473 Movaz Networks
Category: Standards Track January 2003
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions
一般マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）の拡張
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) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) 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 RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents.
この文書では、マルチプロトコルラベルスイッチングに拡張を記述する（MPLS）リソース予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を一般化MPLSをサポートするために必要なシグナリング。一般MPLSは時分割（例えば、同期光ネットワークと同期デジタル・ハイアラーキ、SONET / SDH）、波長（光ラムダ）と空間スイッチング（出力ポートまたはファイバ例えば、着信ポートまたはファイバ）を包含するMPLSコントロールプレーンを拡張します。このドキュメントは、拡張子のRSVP-TE具体的な説明を提示しています。一般的な機能の説明は別の文書に記載されています。
Table of Contents
目次
1. Introduction .............................................. 2
2. Label Related Formats .................................... 3
2.1 Generalized Label Request Object ........................ 3
2.2 Bandwidth Encoding ...................................... 4
2.3 Generalized Label Object ................................ 5
2.4 Waveband Switching ...................................... 5
2.5 Suggested Label ......................................... 6
2.6 Label Set ............................................... 7
3. Bidirectional LSPs ........................................ 8
3.1 Procedures .............................................. 9
3.2 Contention Resolution ................................... 9
4. Notification .............................................. 9
4.1 Acceptable Label Set Object ............................. 10
4.2 Notify Request Objects .................................. 10
4.3 Notify Message .......................................... 12
4.4 Removing State with a PathErr message ................... 14
5. Explicit Label Control .................................... 15
5.1 Label ERO subobject ..................................... 15
5.2 Label RRO subobject ..................................... 16
6. Protection Object ......................................... 17
6.1 Procedures .............................................. 18
7. Administrative Status Information ......................... 18
7.1 Admin Status Object ..................................... 18
7.2 Path and Resv Message Procedures ........................ 18
7.3 Notify Message Procedures ............................... 20
8. Control Channel Separation ................................ 21
8.1 Interface Identification ................................ 21
8.2 Errored Interface Identification ........................ 23
9. Fault Handling ............................................ 25
9.1 Restart_Cap Object ...................................... 25
9.2 Processing of Restart_Cap Object ........................ 26
9.3 Modification to Hello Processing to Support
State Recovery .......................................... 26
9.4 Control Channel Faults .................................. 27
9.5 Nodal Faults ............................................ 27
10. RSVP Message Formats and Handling ......................... 30
10.1 RSVP Message Formats ................................... 30
10.2 Addressing Path and PathTear Messages ................. 32
11. Acknowledgments ........................................... 32
12. Security Considerations ................................... 33
13. IANA Considerations ....................................... 34
13.1 IANA Assignments ....................................... 35
14. Intellectual Property Considerations ...................... 36
15. References ................................................ 37
15.1 Normative References ................................... 37
15.2 Informative References ................................. 38
16. Contributors .............................................. 38
17. Editor's Address .......................................... 41
18. Full Copyright Statement .................................. 42
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 RSVP-TE specific formats and mechanisms needed to support all four classes of interfaces.
時分割多重（TDM）、ラムダ・スイッチ（LSC）およびファイバ・スイッチ（FSC）：一般MPLSは、パケット（PSC）インタフェースをサポートし、インタフェースおよびスイッチングの3つの新しいクラスのサポートが含まれるように切り替えからMPLSを拡張します。インターフェイスと切り替えの新しいクラスをサポートするために必要なMPLSシグナリングの拡張機能の機能説明は、[RFC3471]に提供されます。この文書では、インタフェースのすべての4つのクラスをサポートするために必要なRSVP-TE固有の形式とメカニズムを提示します。
[RFC3471] should be viewed as a companion document to this document. The format of this document parallels [RFC3471]. In addition to the other features of Generalized MPLS, this document also defines RSVP-TE specific features to support rapid failure notification, see Sections 4.2 and 4.3.
[RFC3471]は、この文書に仲間ドキュメントとして見るべきです。この文書のフォーマットは、[RFC3471]を並行します。一般MPLSの他の機能に加えて、この文書はまた、セクション4.2と4.3を参照して、迅速な障害通知をサポートするために、RSVP-TE固有の機能を定義します。
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 Path 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 object 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.
Pathメッセージには、トランジットのLSRによってスイッチングに最大限の柔軟性を可能にするためにできるだけ特定LSP（ラベルスイッチパス）、符号化タイプを含むべきです。一般化ラベルリクエストオブジェクトは、入口ノードで設定された透過的にトランジットノードによって渡され、出口ノードによって使用されます。切換タイプフィールドもホップバイホップを更新することができます。
The format of a Generalized Label Request object is:
一般ラベルRequestオブジェクトの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (19)| C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
パラメータの説明については、[RFC3471]を参照してください。
A node processing a Path message containing a Generalized Label Request must verify that the requested parameters can be satisfied by the interface on which the incoming label is to be allocated, the node itself, and by the interface on which the traffic will be transmitted. 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.
一般化ラベル要求を含むPathメッセージを処理するノードは、要求されたパラメータが入ってくるラベルを割り当てるされたインタフェース、ノード自体によって、トラフィックが送信されるインターフェイスによって満たすことができることを確認しなければなりません。ノードは、直接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 hops when using tunnels see [MPLS-HIERARCHY].
トンネルを使用することができるとき、それらが作成することができるときに、ローカルノードの方針が決まることに注意してください。ローカルポリシーは、トンネルが動的に確立されるか、単に管理上制御することができる可能にすることができます。 ERのトンネルと処理の詳細については、使用してトンネルが[MPLS階層]を見るとホップ。
Transit and egress nodes MUST verify that the node itself and, where appropriate, that the interface or tunnel on which the traffic will be transmitted can support the requested LSP Encoding Type. If encoding cannot be supported, the node MUST generate a PathErr message, with a "Routing problem/Unsupported Encoding" indication.
トランジットと出口ノードは、トラフィックが送信されるインターフェイスまたはトンネルが要求されたLSP符号化タイプをサポートできることを、適切な場合、ノード自体こととを確認しなければなりません。エンコーディングはサポートできない場合、ノードは、「ルーティング問題/サポートされていないエンコーディング」表示と、のPathErrメッセージを生成しなければなりません。
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 PathErr message with a "Routing problem/Switching Type" indication.
ノードは、スイッチングタイプパラメータで示されるタイプは、対応する着信インターフェイス上でサポートされていることを確認しなければなりません。タイプがサポートすることができない場合、ノードは表示を「ルーティング問題/切換タイプ」とのPathErrメッセージを発生させなければなりません。
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 PathErr message, with a "Routing problem/Unsupported L3PID" 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 Resv message. In this case if the G-PID is not supported, then the penultimate hop MUST generate a ResvErr message with a "Routing problem/Unacceptable label value" indication. The generated ResvErr message MAY include an Acceptable Label Set, see Section 4.1.
G-PIDパラメータは、通常のみ出力で調べられます。示されたG-PIDをサポートすることができない場合、出力は「ルーティング問題/サポートされていないL3PID」表示と、のPathErrメッセージを生成しなければなりません。 PSCとき最後から二番目のホップのポッピング（PHP）が要求された場合に、最後から二番目のホップはまた、Resvメッセージの処理中（記憶）G-PIDを調べます。 G-PIDがサポートされていない場合この場合には、次に最後から二番目のホップは、「ルーティング問題/許可されないラベル値」表示とResvErrメッセージを生成しなければなりません。生成されたResvErrメッセージはセクション4.1を参照してください、受け入れ可能なラベルのセットを含んでいてもよいです。
When an error message is not generated, normal processing occurs. In the transit case this will typically result in a Path message being propagated. In the egress case and PHP special case this will typically result in a Resv message being generated.
エラーメッセージが生成されない場合、通常の処理が発生します。トランジットケースでは、これは一般的に伝搬されるPathメッセージになります。出口ケースとPHP特殊なケースでは、これは、典型的には、Resvメッセージが生成されることになります。
Bandwidth encodings are carried in the SENDER_TSPEC and FLOWSPEC objects. See [RFC3471] for a definition of values to be used for specific signal types. These values are set in the Peak Data Rate field of Int-Serv objects, see [RFC2210]. Other bandwidth/service related parameters in the object are ignored and carried transparently.
帯域幅のエンコーディングがSENDER_TSPECとFLOWSPECオブジェクトで運ばれます。特定の信号タイプのために使用される値の定義については、[RFC3471]を参照。これらの値は、[RFC2210]を参照してください、のInt-Servのオブジェクトのピークデータレートフィールドに設定されています。オブジェクトの他の帯域幅/サービス関連のパラメータは無視され、透過的に実行されています。
The format of a Generalized Label object 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (16)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters and encoding of labels.
ラベルのパラメータの記述および符号化のために[RFC3471]を参照。
The Generalized Label travels in the upstream direction in Resv messages.
一般化ラベルは、RESVメッセージ上流方向に移動します。
The presence of both a generalized and normal label object in a Resv message is a protocol error and should treated as a malformed message by the recipient.
Resvメッセージに一般化し、通常のラベルオブジェクトの両方の存在は、プロトコルエラーであり、受信者によって不正なメッセージとして扱わなければなりません。
The recipient of a Resv message containing a Generalized Label verifies that the values passed are acceptable. If the label is unacceptable then the recipient MUST generate a ResvErr message with a "Routing problem/MPLS label allocation failure" indication.
一般化された標識を含むResvメッセージの受信者は、渡された値が許容可能であることを検証します。ラベルが許容できない場合、受信者は、「ルーティング問題/ MPLSラベル割り当て失敗」指示とResvErrメッセージを生成しなければなりません。
Waveband switching uses the same format as the generalized label, see section 2.2. Waveband Label uses C-Type (3),
波長群スイッチングは、セクション2.2を参照して、一般的なラベルと同じ形式を使用しています。波長バンド・ラベルは、C型（3）を使用し
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (16)| C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waveband Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
パラメータの説明については、[RFC3471]を参照してください。
The procedures defined in Section 2.3.1 apply to waveband switching. This includes generating a ResvErr message with a "Routing problem/MPLS label allocation failure" indication if any of the label fields are unrecognized or unacceptable.
2.3.1項で定義された手順は、スイッチングを波長帯に適用されます。ラベルフィールドのいずれかが認識できない、または許容されない場合、これは「ルーティング問題/ MPLSラベル割り当て失敗」指示とResvErrメッセージを生成することを含みます。
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 object MUST be flipped before forwarding the label object with the new waveband Id. In this manner an egress/ingress LSR which receives a waveband label which has these values inverted, knows that it must also invert its egress association to pick up the proper wavelengths.
波長帯が他の帯に切り替えられた場合に加えて、波長帯内の波長は、中心周波数の周りにミラーリングされることが可能です。スイッチングのこのタイプを採用した場合、波長帯ラベルオブジェクト内の開始と終了ラベルが新しい波長帯のIDを持つラベルオブジェクトを転送する前に反転しなければなりません。このようにして反転し、これらの値を持つ波長帯のラベルを受け取る出口/入口LSRは、それはまた、適切な波長をピックアップして、その出口の関連を反転しなければならないことを知っています。
This operation MUST be performed in both directions when a bidirectional waveband tunnel is being established.
双方向波長帯トンネルが確立されている場合、この動作は、両方向で行われなければなりません。
The format of a Suggested_Label object is identical to a generalized label. It is used in Path messages. A Suggested_Label object uses Class-Number 129 (of form 10bbbbbb) and the C-Type of the label being suggested.
Suggested_Labelオブジェクトの形式は、一般的なラベルと同じです。これは、Pathメッセージに使用されています。 Suggested_Labelオブジェクトは、（フォーム10bbbbbbの）クラス番号129を使用し、ラベルのC-Typeが提案されています。
Errors in received Suggested_Label objects MUST be ignored. This includes any received inconsistent or unacceptable values.
受信Suggested_Labelオブジェクトのエラーは無視しなければなりません。これは、任意の受信した一貫性のないまたは許容できない値を含みます。
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 ResvErr 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 a corresponding label upstream.
下流ノードは、上流提案ラベルと異なるラベル値を通過した場合につき[RFC3471]は、アップストリームLSRは/それは下流のノードによって指定されたラベルを使用するようにそれ自体を再構成または「ルーティング問題にResvErrメッセージを生成しなければならないのいずれかで容認できないラベル値」表示。また、入口ノードは、下流ノードが上流の対応するラベルを通過するまで提案ラベルを使用してデータトラフィックを送信すべきではありません。
The Label_Set object uses Class-Number 36 (of form 0bbbbbbb) and the C-Type of 1. It is used in Path messages.
Label_Setオブジェクトは、（フォーム0bbbbbbbはの）クラス番号36を使用し、1のC型は、それは、Pathメッセージに使用されます。
The format of a Label_Set is:
Label_Setの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (36)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label Type: 14 bits
ラベルタイプ：14ビット
Indicates the type and format of the labels carried in the object. Values match the C-Type of the appropriate RSVP_LABEL object. Only the low order 8 bits are used in this field.
オブジェクトで運ばれたラベルの種類や形式を示します。値は、適切なRSVP_LABELオブジェクトのC型と一致します。唯一の下位8ビットはこの分野で使用されています。
See [RFC3471] for a description of other parameters.
その他のパラメータについては、[RFC3471]を参照。
A Label Set is defined via one or more Label_Set objects. Specific labels/subchannels can be added to or excluded from a Label Set via Action zero (0) and one (1) objects respectively. Ranges of labels/subchannels can be added to or excluded from a Label Set via Action two (2) and three (3) objects respectively. When the Label_Set objects only list labels/subchannels to exclude, this implies that all other labels are acceptable.
ラベルセットは、一つ以上のLabel_Setオブジェクトによって定義されます。特定の標識/サブチャネルが追加またはアクションゼロ（0）を介して設定されたラベルから除外することができ、一方は、（1）それぞれのオブジェクト。ラベル/サブチャネルの範囲に追加またはアクション2つ（2）を介して設定されたラベルから除外することができ、3つのそれぞれのオブジェクト。 Label_Setを除外するための唯一のリストのラベル/サブチャネルオブジェクトと、これは他のすべてのラベルが許容されていることを意味します。
The absence of any Label_Set objects 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.
任意のLabel_Setオブジェクトが存在しない場合は、すべてのラベルが許容されることを意味します。ノードが下流に使用することができるラベル（複数可）を制限することを望むときにラベルセットが含まれています。
On reception of a Path 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 Path message. If the node is unable to pick a label from the Label Set or if there is a problem parsing the Label_Set objects, then the request is terminated and a PathErr 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 Resv or if the selection is made immediately for propagation in the Resv.
Pathメッセージを受信すると、受信ノードは、ラベルセットである1にラベルのその選択を制限します。また、Pathメッセージを転送する前に設定してラベルを削除することができるラベル変換を行うことが可能なノード。ノードは、ラベルセットからラベルを選択することができないかLabel_Setオブジェクトの解析に問題がある場合、その要求は終了し、「ルーティング問題/ラベルセット」表示とのPathErrメッセージが生成する必要がある場合。セットはのResv上または選択をしたResvで伝播のためにすぐに行われた場合、後の選択のために保存されているラベルの場合はローカルの問題です。
On reception of a Path 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 Path message. When the resulting Label Set is empty, the Path must be terminated, and a PathErr 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.
Pathメッセージを受信すると、Pathメッセージで転送されたメッセージに示さラベルセットが下流インタフェースにおいて利用可能なラベルのセットと、得られた交差ラベルセットと比較されます。結果としてラベルのセットが空の場合、パスが終了しなければならない、とのPathErrメッセージ、および「ルーティング問題/ラベルセット」表示が生成されなければなりません。結果として、それらが一貫した物理的意味を有するようにこれらの値をマッピングするノードの責任であり、その交差点が異なるリンク上の異なる論理値を有することができる物理的ラベル（実際の波長/帯域値）に基づいている（注）、またはいかなる適切な論理ラベル値が存在しない場合のセットから特定の値を削除します。
When processing a Resv message at an intermediate node, the label propagated upstream MUST fall within the Label Set.
中間ノードにおけるResvメッセージを処理するとき、上流の伝播ラベルは、ラベルセット内に入らなければなりません。
Note, on reception of a Resv 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 Resv message. In this case, the use and propagation of a Label Set will significantly reduce the chances that this allocation will fail.
Resvメッセージの受信にラベル変換を行うことができないノードは、Resvメッセージ中で受信した同一の物理的ラベル（波長/バンド）を使用するよりも、他の選択肢を持っていない、注意してください。この場合、ラベルセットを使用すると、伝播が大幅にこの割り当てが失敗する可能性が減少します。
Bidirectional LSP setup is indicated by the presence of an Upstream Label in the Path message. An Upstream_Label object has the same format as the generalized label, see Section 2.3. The Upstream_Label object uses Class-Number 35 (of form 0bbbbbbb) and the C-Type of the label being used.
双方向LSPセットアップは、Pathメッセージで上流のラベルの存在によって示されます。 UPSTREAM_LABELオブジェクトは、一般的なラベルと同じフォーマットを持っている、セクション2.3を参照してください。 UPSTREAM_LABELオブジェクトは、（フォーム0bbbbbbbはの）クラス番号35を使用し、ラベルのC-Typeが使用されています。
The process of establishing a bidirectional LSP follows the establishment of a unidirectional LSP with some additions. To support bidirectional LSPs an Upstream_Label object is added to the Path message. The Upstream_Label object MUST indicate a label that is valid for forwarding at the time the Path message is sent.
双方向LSPを確立するプロセスは、いくつかの添加とともに、単方向LSPの確立を以下。双方向LSPをサポートするためにUPSTREAM_LABELオブジェクトは、Pathメッセージに追加されます。 UPSTREAM_LABELオブジェクトは、Pathメッセージが送信された時点で転送するための有効なラベルを指定する必要があります。
When a Path message containing an Upstream_Label object is received, the receiver first verifies that the upstream label is acceptable. If the label is not acceptable, the receiver MUST issue a PathErr message with a "Routing problem/Unacceptable label value" indication. The generated PathErr message MAY include an Acceptable Label Set, see Section 4.1.
UPSTREAM_LABELオブジェクトを含むPathメッセージを受信すると、受信機は、最初の上流のラベルが許容可能であることを検証します。ラベルは許容できない場合、受信機は、「ルーティング問題/許容できないラベル値」表示とのPathErrメッセージを発行しなければなりません。生成されたPathErrメッセージは、セクション4.1を参照してください、受け入れ可能なラベルのセットを含んでいてもよいです。
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 Path message. If an intermediate node is unable to allocate a label or internal resources, then it MUST issue a PathErr message with a "Routing problem/MPLS label allocation failure" indication.
中間ノードは、発信インターフェイス上でラベルを割り当て、発信上流のラベルに記入し、Pathメッセージを伝播する前に、内部データ経路を確立しなければなりません。中間ノードは、ラベルまたは内部リソースを割り当てることができない場合、それは「ルーティング問題/ MPLSラベル割り当て失敗」表示とのPathErrメッセージを発行しなければなりません。
Terminator nodes process Path 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に関連するデータトラフィックを転送するために使用することができることを除いて、通常どおり処理Pathメッセージをノード。
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が除去されると、上流および下流の両方のラベルが無効化され、それがもはや有効関連付けられたラベルを使用してデータを送信するようにされていません。
There are two additional contention resolution related considerations when controlling bidirectional LSP setup via RSVP-TE. The first is that for the purposes of RSVP contention resolution, the node ID is the IP address used in the RSVP_HOP object. The second is that a neighbor's node ID might not be known when sending an initial Path message. When this case occurs, a node should suggest a label chosen at random from the available label space.
RSVP-TEを介した双方向LSP設定を制御するときに、2つの追加の競合解決関連の考慮事項があります。最初は、RSVPの競合解決の目的のために、ノードIDがRSVP_HOPオブジェクトで使用されるIPアドレスであることです。第二は、最初のPathメッセージを送信する際に、近隣のノードのIDが知られていない可能性がありますということです。この場合は、発生した場合、ノードは、利用可能なラベルスペースからランダムに選ばれたラベルを提案すべきです。
This section covers several notification related extensions. The first extension defines the Acceptable Label Set object to support Notification on Label Error, per [RFC3471]. The second and third extensions enable expedited notification of failures and other events to nodes responsible for restoring failed LSPs. (The second extension, the Notify Request object, identifies where event notifications are to be sent. The third extension, the Notify message, provides for general event notification.) The final notification related extension allows for the removal of Path state on handling of PathErr messages.
このセクションでは、いくつかの通知関連の拡張機能をカバーしています。最初の拡張は、[RFC3471]あたりに、ラベルエラーの通知をサポートするための許容可能なラベルセットオブジェクトを定義します。第二と第三の拡張が失敗したLSPを復元する責任ノードに障害や他のイベントの迅速な通知を可能にします。 （イベント通知が送信される場合に第二の拡張、通知要求オブジェクトは、識別される。第三の拡張を、メッセージを通知し、一般的なイベント通知を提供する。）最終的な通知に関連する拡張はのPathErrの取り扱い上のパス状態の除去を可能にしますメッセージ。
Acceptable_Label_Set objects use a Class-Number 130 (of form 10bbbbbb). The remaining contents of the object, including C-Type, have the identical format as the Label_Set object, see Section 2.6.
Acceptable_Label_Setオブジェクトは、（フォーム10bbbbbbの）クラス番号130を使用します。 C型を含むオブジェクトの残りの内容は、セクション2.6を参照して、Label_Setオブジェクトと同じフォーマットを有します。
Acceptable_Label_Set objects may be carried in PathErr and ResvErr messages. The procedures for defining an Acceptable Label Set follow the procedures for defining a Label Set, see Section 2.6.1. Specifically, an Acceptable Label Set is defined via one or more Acceptable_Label_Set objects. Specific labels/subchannels can be added to or excluded from an Acceptable Label Set via Action zero (0) and one (1) objects respectively. Ranges of labels/subchannels can be added to or excluded from an Acceptable Label Set via Action two (2) and three (3) objects respectively. When the Acceptable_Label_Set objects only list labels/subchannels to exclude, this implies that all other labels are acceptable.
Acceptable_Label_SetオブジェクトはのPathErrとResvErrメッセージで搬送することができます。許容可能なラベルの設定を定義するための手順は、ラベルセットを定義するための手順に従って、2.6.1項を参照してください。具体的には、許容可能なラベルセットは、一つ以上のAcceptable_Label_Setオブジェクトによって定義されます。特定の標識/サブチャネルが追加またはアクションゼロ（0）を介して設定された許容可能なラベルから除外することができ、一方は、（1）それぞれのオブジェクト。ラベル/サブチャネルの範囲に追加またはアクション2つ（2）を介して設定された許容可能なラベルから除外することができ、3つ（3）それぞれのオブジェクト。 Acceptable_Label_Setを除外するための唯一のリストのラベル/サブチャネルオブジェクトと、これは他のすべてのラベルが許容されていることを意味します。
The inclusion of Acceptable_Label_Set objects is optional. If included, the PathErr or ResvErr message SHOULD contain a "Routing problem/Unacceptable label value" indication. The absence of Acceptable_Label_Set objects does not have any specific meaning.
Acceptable_Label_Setオブジェクトの包含は任意です。含まれている場合、のPathErrかResvErrメッセージは、「ルーティング問題/許容できないラベル値」の表示を含むべきです。 Acceptable_Label_Setオブジェクトが存在しない場合は、任意の特定の意味を持っていません。
Notifications may be sent via the Notify message defined below. The Notify Request object is used to request the generation of notifications. Notifications, i.e., the sending of a Notify message, may be requested in both the upstream and downstream directions.
通知は以下に定義される通知メッセージを介して送信されてもよいです。通知Requestオブジェクトは、通知の生成を要求するために使用されます。通知、すなわち、通知メッセージの送信、両方の上流及び下流方向で要求されてもよいです。
The Notify Request Object may be carried in Path or Resv Messages, see Section 7. The Notify_Request Class-Number is 195 (of form 11bbbbbb). The format of a Notify Request is:
通知リクエストオブジェクトは、参照セクション7. Notify_Requestクラス数（フォーム11bbbbbbの）195で、パスまたはRESVメッセージで行うことができます。通知リクエストの形式は次のとおりです。
o IPv4 Notify Request Object
O IPv4がリクエストオブジェクトに通知します
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (1) | C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Notify Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Notify Node Address: 32 bits
ノードアドレスを通知IPV4：32ビット
The IP address of the node that should be notified when generating an error message.
エラーメッセージを生成するときに通知されるべきノードのIPアドレス。
o IPv6 Notify Request Object
O IPv6はリクエストオブジェクトに通知します
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (2) | C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Notify Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Notify Node Address: 16 bytes
16バイト：IPv6はノードアドレスを通知します
The IP address of the node that should be notified when generating an error message.
エラーメッセージを生成するときに通知されるべきノードのIPアドレス。
If a message contains multiple Notify_Request objects, only the first object is meaningful. Subsequent Notify_Request objects MAY be ignored and SHOULD NOT be propagated.
メッセージが複数Notify_Requestオブジェクトが含まれている場合、唯一の第一の目的は、有意義です。後続のNotify_Requestオブジェクトは無視してもよいし、伝播されるべきではありません。
A Notify Request object may be inserted in Path or Resv messages to indicate the address of a node that should be notified of an LSP failure. As previously mentioned, notifications may be requested in both the upstream and downstream directions. Upstream notification is indicated via the inclusion of a Notify Request Object in the corresponding Path message. Downstream notification is indicated via the inclusion of a Notify Request Object in the corresponding Resv message.
通知要求オブジェクトは、LSPの障害を通知しなければならないノードのアドレスを示すために、パスまたはRESVメッセージに挿入することができます。先に述べたように、通知が上流及び下流方向の両方に要求されてもよいです。上流の通知は、対応するPathメッセージで通知リクエストオブジェクトの包含を介して示されています。下流通知は、対応するResvメッセージで通知リクエストオブジェクトの包含を介して示されています。
A node receiving a message containing a Notify Request object SHOULD store the Notify Node Address in the corresponding state block. If the node is a transit node, it SHOULD also included a Notify Request object in the outgoing Path or Resv message. The outgoing Notify Node Address MAY be updated based on local policy.
対応する状態ブロック内のノードアドレスを通知格納する必要が通知要求オブジェクトを含むメッセージを受信するノード。ノードが中継ノードである場合、それはまた、送信パスまたはResvメッセージで通知リクエストオブジェクトを含めるべきです。送信通知ノードアドレスは、ローカルポリシーに基づいて更新されてもよいです。
Note that the inclusion of a Notify Request object does not guarantee that a Notify message will be generated.
通知Requestオブジェクトを含めることが通知メッセージが生成されることを保証するものではないことに注意してください。
The Notify message provides a mechanism to inform non-adjacent nodes of LSP related events. Notify messages are normally generated only after a Notify Request object has been received. The Notify message differs from the currently defined error messages (i.e., PathErr and ResvErr messages) in that it can be "targeted" to a node other than the immediate upstream or downstream neighbor and that it is a generalized notification mechanism. The Notify message does not replace existing error messages. The Notify message may be sent either (a) normally, where non-target nodes just forward the Notify message to the target node, similar to ResvConf processing in [RFC2205]; or (b) encapsulated in a new IP header whose destination is equal to the target IP address. Regardless of the transmission mechanism, nodes receiving a Notify message not destined to the node forward the message, unmodified, towards the target.
通知メッセージは、LSPに関連するイベントの非隣接ノードに通知するためのメカニズムを提供します。通知メッセージは、通常、通知Requestオブジェクトが受信された後にのみ生成されます。通知メッセージが即時上流または下流の隣接以外のノードに、それが一般的な通知メカニズムであることを「標的化」することができるという点で、現在定義されたエラーメッセージ（すなわち、のPathErrとResvErrメッセージ）とは異なります。通知メッセージは、既存のエラーメッセージに代わるものではありません。通知メッセージは、非ターゲットノードがちょうど[RFC2205]にResvConf処理と同様に、ターゲット・ノードに通知メッセージを転送する場合、いずれかの（a）は通常送信されてもよいです。または（b）宛先目標IPアドレスと等しい新しいIPヘッダでカプセル化されました。かかわらず、変速機構の、標的に対する修飾されていないメッセージを、転送ノード宛ではないメッセージを通知を受信ノード。
To support reliable delivery of the Notify message, an Ack Message [RFC2961] is used to acknowledge the receipt of a Notify Message. See [RFC2961] for details on reliable RSVP message delivery.
通知メッセージの信頼できる配信をサポートするために、肯定応答メッセージ[RFC2961]はNOTIFYメッセージの受信を確認するために使用されます。信頼できるRSVPメッセージ配信の詳細については、[RFC2961]を参照してください。
The Notify message is a generalized notification message. The IP destination address is set to the IP address of the intended receiver. The Notify message is sent without the router alert option. A single Notify message may contain notifications being sent, with respect to each listed session, both upstream and downstream.
通知メッセージは、一般的な通知メッセージです。 IP宛先アドレスは、意図受信機のIPアドレスに設定されています。通知メッセージは、ルータ警戒オプションなしで送信されます。単一の通知メッセージは、通知は、上流及び下流の両方、リストされた各セッションに対して、送信されて含まれていてもよいです。
The Notify message has a Message Type of 21. The Notify message format is as follows:
通知メッセージは、21.通知メッセージ形式のメッセージ・タイプを有する以下の通りであります：
<Notify message> ::= <Common Header> [<INTEGRITY>]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<ERROR_SPEC> <notify session list>
<notify session list> ::= [ <notify session list> ]
<upstream notify session> |
<downstream notify session>
<upstream notify session> ::= <SESSION> [ <ADMIN_STATUS> ]
[<POLICY_DATA>...]
<sender descriptor>
<downstream notify session> ::= <SESSION> [<POLICY_DATA>...]
<flow descriptor list>
The ERROR_SPEC object specifies the error and includes the IP address of either the node that detected the error or the link that has failed. See ERROR_SPEC definition in [RFC2205]. The MESSAGE_ID and related objects are defined in [RFC2961] and are used when [RFC2961] is supported.
ERROR_SPECオブジェクトは、エラーを特定し、エラーを検出したノード、または失敗したリンクのいずれかのIPアドレスを含みます。 [RFC2205]でERROR_SPECの定義を参照してください。 MESSAGE_IDと関連オブジェクトは[RFC2961]で定義され、[RFC2961]がサポートされているときに使用されます。
Notify messages are most commonly generated at nodes that detect an error that will trigger the generation of a PathErr or ResvErr message. If a PathErr message is to be generated and a Notify Request object has been received in the corresponding Path message, then a Notify message destined to the recorded node SHOULD be generated. If a ResvErr message is to be generated and a Notify Request object has been received in the corresponding Resv message, then a Notify message destined to the recorded node SHOULD be generated. As previously mentioned, a single error may generate a Notify message in both the upstream and downstream directions. Note that a Notify message MUST NOT be generated unless an appropriate Notify Request object has been received.
通知メッセージは、最も一般的のPathErr又はResvErrメッセージの生成をトリガするエラーを検出したノードにおいて生成されます。たPathErrメッセージが生成されると通知要求オブジェクトは、対応するPathメッセージで受信された場合、記録されたノード宛の通知メッセージが生成されるべきです。 ResvErrメッセージが生成されると通知要求オブジェクトは、対応するResvメッセージ中で受信された場合、記録されたノード宛の通知メッセージが生成されるべきです。先に述べたように、単一のエラーが上流及び下流方向の両方に通知メッセージを生成してもよいです。適切な通知要求オブジェクトが受信されていない限り、通知メッセージが生成されてはならないことに注意してください。
When generating Notify messages, a node SHOULD attempt to combine notifications being sent to the same Notify Node and that share the same ERROR_SPEC into a single Notify message. The means by which a node determines which information may be combined is implementation dependent. Implementations may use event, timer based or other approaches. If using a timer based approach, the implementation SHOULD allow the user to configure the interval over which notifications are combined. When using a timer based approach, a default "notification interval" of 1 ms SHOULD be used. Notify messages SHOULD be delivered using the reliable message delivery mechanisms defined in [RFC2961].
Notifyメッセージを生成する場合、ノードが同じ通知ノードとその共有、単一の通知メッセージに同じERROR_SPECに送信される通知を組み合わせることを試みる必要があります。ノードが組み合わされてもよい情報を判断する手段は実装依存です。実装はイベント、タイマーベースまたは他のアプローチを使用することができます。タイマーベースのアプローチを使用している場合、実装は、ユーザーが通知を組み合わせた上で間隔を設定できるようにする必要があります。タイマーベースのアプローチを使用する場合は、1ミリ秒のデフォルトの「通知間隔」を使用するべきです。通知メッセージは、[RFC2961]で定義された信頼性の高いメッセージ配信機構を使用して送達されるべきです。
Upon receiving a Notify message, the Notify Node SHOULD send a corresponding Ack message.
通知メッセージを受信すると、通知ノードは、対応するACKメッセージを送信すべきです。
The PathErr message as defined in [RFC2205] is sent hop-by-hop to the source of the associated Path message. Intermediate nodes may inspect this message, but take no action upon it. In an environment where Path messages are routed according to an IGP and that route may change dynamically, this behavior is a fine design choice.
[RFC2205]で定義されたPathErrメッセージは、関連するPathメッセージのソースにホップバイホップに送信されます。中間ノードは、このメッセージを検査し、それにより何もアクションを起こさないことがあります。 PathメッセージがIGPと動的に変更される可能性があり、その経路に従ってルーティングされている環境では、この動作は細かい設計上の選択です。
However, when RSVP is used with explicit routes, it is often the case that errors can only be corrected at the source node or some other node further upstream. In order to clean up resources, the source must receive the PathErr and then either send a PathTear (or wait for the messages to timeout). This causes idle resources to be held longer than necessary and increases control message load. In a situation where the control plane is attempting to recover from a serious outage, both the message load and the delay in freeing resources hamper the ability to rapidly reconverge.
RSVPは、明示的なルートが使用されている場合しかし、それはエラーが唯一のさらに上流のソースノードまたはいくつかの他のノードで補正することができる場合が多いです。リソースをクリーンアップするためには、ソースはのPathErrを受けなければならないし、その後のいずれかPathTearを送信する（またはタイムアウトのメッセージを待ちます）。これは、アイドル状態のリソースが必要以上に長く保持させると、制御メッセージの負荷を増大させます。コントロールプレーンは、深刻な停電からのメッセージ負荷と資源が急速に再収束する能力を妨げる解放の遅れの両方を回復しようとしている状況では。
The situation can be greatly improved by allowing state to be removed by intermediate nodes on certain error conditions. To facilitate this a new flag is defined in the ERROR_SPEC object. The two currently defined ERROR_SPEC objects (IPv4 and IPv6 error spec objects) each contain a one byte flag field. Within that field two flags are defined. This specification defines a third flag, 0x04, Path_State_Removed.
状況は大きく状態が特定のエラー状態に中間ノードによって除去することができるようにすることによって改善することができます。これを容易にするために、新たなフラグがERROR_SPECオブジェクトに定義されています。 2つの現在定義ERROR_SPECオブジェクト（IPv4とIPv6のエラー仕様オブジェクト）は、それぞれ1バイトのフラグフィールドを含みます。そのフィールド内の二つのフラグが定義されています。この仕様は、第3のフラグ、0x04の、Path_State_Removedを定義します。
The semantics of the Path_State_Removed flag are simply that the node forwarding the error message has removed the Path state associated with the PathErr. By default, the Path_State_Removed flag is always set to zero when generating or forwarding a PathErr message. A node which encounters an error MAY set this flag if the error results in the associated Path state being discarded. If the node setting the flag is not the session endpoint, the node SHOULD generate a corresponding PathTear. A node receiving a PathErr message containing an ERROR_SPEC object with the Path_State_Removed flag set MAY also remove the associated Path state. If the Path state is removed the Path_State_Removed flag SHOULD be set in the outgoing PathErr message. A node which does not remove the associated Path state MUST NOT set the Path_State_Removed flag. A node that receives an error with the Path_State_Removed flag set to zero MUST NOT set this flag unless it also generates a corresponding PathTear message.
Path_State_Removedフラグの意味は、エラー・メッセージを転送するノードのPathErrに関連付けられたパスの状態を削除したことを単にです。生成したりたPathErrメッセージを転送するときに、デフォルトで、Path_State_Removedフラグは常にゼロに設定されています。関連するパスの状態でエラー結果が破棄される場合は、エラーが発生したノードは、このフラグを設定してもよいです。フラグを設定するノードは、セッション・エンドポイントではない場合、ノードは、対応するPathTearを生成する必要があります。 Path_State_Removedフラグを設定してERROR_SPECオブジェクトを含むのPathErrメッセージを受信したノードは、関連するパスの状態を除去することができます。パス状態が除去された場合Path_State_Removedフラグは送信のPathErrメッセージに設定されるべきです。関連するパスの状態を削除しないノードはPath_State_Removedフラグを設定してはいけません。それはまた、対応するPathTearメッセージを生成しない限り、ゼロに設定Path_State_Removedフラグでエラーを受信したノードは、このフラグを設定してはいけません。
Note that the use of this flag does not result in any interoperability incompatibilities.
このフラグの使用は任意の相互運用性の非互換性が生じないことに注意してください。
The Label ERO (Explicit Route Object) and RRO (Record Route Object) subobjects are defined to support Explicit Label Control. Note that the Label RRO subobject was defined in [RFC3209] and is being extended to support bidirectional LSPs.
ラベルERO（明示的なルートオブジェクト）とRRO（レコードルートオブジェクト）サブオブジェクトは、明示的なLabelコントロールをサポートするために定義されています。ラベルRROサブオブジェクトは、[RFC3209]で定義された双方向LSPをサポートするように拡張されていることに留意されたいです。
The Label ERO subobject is defined as follows:
次のようにラベルEROサブオブジェクトが定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |U| Reserved | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of L, U and Label parameters.
L、Uおよびラベルのパラメータの説明については、[RFC3471]を参照してください。
Type
タイプ
3 Label
3ラベル
Length
長さ
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always divisible by 4.
長さは、タイプと長さフィールドを含むバイト単位のサブオブジェクトの全長を含んでいます。長さは常に4で割り切れます。
C-Type
C型
The C-Type of the included Label Object. Copied from the Label Object.
付属ラベルオブジェクトのC型。ラベルオブジェクトからコピーされました。
The Label subobject follows a subobject containing the IP address, or the interface identifier [RFC3477], associated with the link on which it is to be used. Up to two label subobjects may be present, one for the downstream label and one for the upstream label. The following SHOULD result in "Bad EXPLICIT_ROUTE object" errors:
ラベルサブオブジェクトは、それが使用されるのリンクに関連付けられたIPアドレスを含むサブオブジェクト、またはインタフェース識別子[RFC3477]を、次の。最大2つのラベルサブオブジェクトは、下流ラベル用と上流のラベルのための1つに存在してもよいです。以下は、「悪いEXPLICIT_ROUTEオブジェクト」エラーが発生する必要があります。
o If the first label subobject is not preceded by a subobject containing an IP address, or an interface identifier [RFC3477], associated with an output link.
O第1のラベルサブオブジェクトは、出力リンクに関連付けられたIPアドレスを含むサブオブジェクト、またはインタフェース識別子[RFC3477]、によって先行されていない場合。
o For a label subobject to follow a subobject that has the L-bit set
Lビットがセットされているサブオブジェクトを追跡するためのラベルサブオブジェクトに対してO
o On unidirectional LSP setup, for there to be a label subobject with the U-bit set
一方向LSPセットアップでoは、そこためUビットが設定されたラベルのサブオブジェクトであることが
o For there to be two label subobjects with the same U-bit values
Oが存在するため、同じUビット値を有する2つのラベルのサブオブジェクトであることが
To support the label subobject, a node must check to see if the subobject following its associate address/interface is a label subobject. If it is, one subobject is examined for unidirectional LSPs and two subobjects for bidirectional LSPs. If the U-bit of the subobject being examined is clear (0), then value of the label is copied into a new Label_Set object. This Label_Set object MUST be included on the corresponding outgoing Path message.
ラベルサブオブジェクトをサポートするために、ノードは、その仲間アドレス/インターフェース以下のサブオブジェクトは、ラベルサブオブジェクトであるかどうかを確認する必要があります。もしそうであれば、1つのサブオブジェクトは、単方向のLSPと双方向のLSPのための2つのサブオブジェクトを調べています。検査されるサブオブジェクトのUビットがクリアされている場合（0）、次いでラベルの値は、新しいLabel_Setオブジェクトにコピーされます。このLabel_Setオブジェクトは、対応する送信するPathメッセージに含まれなければなりません。
If the U-bit of the subobject 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 object" error SHOULD be generated. If the label is acceptable, the label is copied into a new Upstream_Label object. This Upstream_Label object MUST be included on the corresponding outgoing Path message.
検査されるサブオブジェクトのUビットは、（1）設定されている場合、ラベルの値は、双方向LSPに関連付けられたアップストリームトラフィックに使用されるラベルです。このラベルが受け入れられない場合は、「悪いEXPLICIT_ROUTEオブジェクト」エラーが生成されるべきです。ラベルが許容される場合は、ラベルが新しいUPSTREAM_LABELオブジェクトにコピーされます。このUPSTREAM_LABELオブジェクトは、対応する送信するPathメッセージに含まれなければなりません。
After processing, the label subobjects are removed from the ERO.
処理の後、ラベルサブオブジェクトがEROから削除されます。
Note an implication of the above procedures is that the label subobject should never be the first subobject in a newly received message. If the label subobject is the the first subobject an a received ERO, then it SHOULD be treated as a "Bad strict node" error.
上記手順の含意注ラベルサブオブジェクトは、新たに受信されたメッセージの最初のサブオブジェクトあってはならないということです。ラベルサブオブジェクトは、最初のサブオブジェクト受信EROである場合、それは「悪い厳密ノード」エラーとして扱われるべきです。
Procedures by which an LSR at the head-end of an LSP obtains the information needed to construct the Label subobject are outside the scope of this document.
LSPのヘッドエンドでのLSRがラベルサブオブジェクトを構築するために必要な情報を取得することにより、手順は、この文書の範囲外です。
The Label RRO subobject is defined as follows:
次のようにラベルRROのサブオブジェクトが定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |U| Flags | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of U and Label parameters.
Uとラベルのパラメータの説明については、[RFC3471]を参照してください。
Type
タイプ
3 Label
3ラベル
Length
長さ
See [RFC3209].
[RFC3209]を参照してください。
Flags
国旗
See [RFC3209].
[RFC3209]を参照してください。
C-Type
C型
The C-Type of the included Label Object. Copied from the Label Object.
付属ラベルオブジェクトのC型。ラベルオブジェクトからコピーされました。
Label RRO subobjects are included in RROs as described in [RFC3209]. The only modification to usage and processing from [RFC3209] is that when labels are recorded for bidirectional LSPs, label ERO subobjects for both downstream and upstream labels MUST be included.
ラベルRROサブオブジェクトは、[RFC3209]に記載されているようにRROsに含まれています。 [RFC3209]の使用量および処理にのみ変更はラベルが双方向のLSPのために記録されている場合、下流および上流両方のラベルのラベルEROサブオブジェクトを含まなければならないことです。
The use of the Protection Object is optional. The object is included to indicate specific protection attributes of an LSP. The Protection Object uses Class-Number 37 (of form 0bbbbbbb).
保護対象の使用はオプションです。オブジェクトはLSPの特定の保護属性を示すために含まれています。保護対象は、クラス番号37（フォーム0bbbbbbbはの）を使用します。
The format of the Protection Object 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (37)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
パラメータの説明については、[RFC3471]を参照してください。
Transit nodes processing a Path message containing a Protection Object MUST verify that the requested protection can be satisfied by the outgoing interface or tunnel (FA). If it cannot, the node MUST generate a PathErr message, with a "Routing problem/Unsupported Link Protection" indication.
保護対象を含むPathメッセージを処理するトランジットノードは、要求された保護は、発信インターフェースまたはトンネル（FA）によって満たすことができることを確認しなければなりません。それができない場合、ノードは、「ルーティング問題/サポートされていないリンクの保護」表示で、のPathErrメッセージを発生させなければなりません。
Administrative Status Information is carried in the Admin_Status object. The object provides information related to the administrative state of a particular LSP. The information is used in two ways. In the first, the object is carried in Path and Resv messages to indicate the administrative state of an LSP. In the second, the object is carried in a Notification message to request that the ingress node change the administrative state of an LSP.
管理ステータス情報はADMIN_STATUSオブジェクトで運ばれます。オブジェクトは、特定のLSPの管理状態に関連する情報を提供します。情報は、次の2つの方法で使用されています。最初に、オブジェクトは、LSPの管理状態を示すために、パスとのResvメッセージで運ばれます。第二に、オブジェクトは、入口ノードは、LSPの管理状態を変更することを要求する通知メッセージで搬送されます。
The use of the Admin_Status Object is optional. It uses Class-Number 196 (of form 11bbbbbb).
ADMIN_STATUSオブジェクトの使用はオプションです。これは、（フォーム11bbbbbbの）クラス番号196を使用しています。
The format of the Admin_Status Object is:
ADMIN_STATUSオブジェクトの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(196)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
パラメータの説明については、[RFC3471]を参照してください。
The Admin_Status object is used to notify each node along the path of the status of the LSP. Status information is processed by each node based on local policy and then propagated in the corresponding outgoing messages. The object may be inserted in either Path or Resv messages at the discretion of the ingress (for Path messages) or egress (for Resv messages) nodes. The absence of the object is equivalent to receiving an object containing values all set to zero (0).
ADMIN_STATUSオブジェクトはLSPの状態の経路に沿って各ノードに通知するために使用されます。状態情報は、ローカルポリシーに基づいて、各ノードによって処理され、対応する送信メッセージに伝搬されます。オブジェクトは、（RESVメッセージの場合）または出力ノード（Pathメッセージのための）入口の裁量パスまたはRESVメッセージのいずれかに挿入することができます。オブジェクトが存在しない場合は、すべてゼロに設定された値を含むオブジェクトを受信することと等価である（0）。
Transit nodes receiving a non-refresh Path or Resv message containing an Admin_Status object, update their local state, take any appropriate local action based on the indicated status and then propagate the received Admin_Status object in the corresponding outgoing Path or Resv message. If the values of an Admin_Status object received in a Resv message differs from the values received in a Path message then, with one exception, no local action should be taken but the values should still be propagated. The one case where values received in the Resv message should result in local action is when both the received R and D bits are set, i.e., are one (1).
非リフレッシュパスまたはADMIN_STATUSオブジェクトを含むResvメッセージを受信したトランジットノードは、そのローカル状態を更新指示ステータスに基づいて、任意の適切なローカルアクションを取ると、対応する送信パスまたはResvメッセージにおいて受信ADMIN_STATUSオブジェクトを伝播します。 Resvメッセージで受信ADMIN_STATUSオブジェクトの値は、パスメッセージで受信した値と異なる場合、一つの例外を除いて、ローカルアクションがとられるべきではないが、値がまだ伝播しなければなりません。 Resvメッセージにおいて受信された値は、局所作用をもたらすはずである場合は、受信したRとDのビットの両方が設定されている場合、すなわち、である1つ（1）。
Edge nodes receiving a non-refresh Path or Resv message containing an Admin_Status object, also update their local state and take any appropriate local action based on the indicated status. When an Admin Status object is received with the R bit set, the receiving edge node should reflect the received values in a corresponding outgoing message. Specifically, if an egress node receives a Path message with the R bit of the Admin_Status object set and the node has previously issued a Resv message corresponding to the Path message, the node SHOULD send an updated Resv message containing an Admin_Status object with the same values set, with the exception of the R bit, as received in the corresponding Path message. Furthermore, the egress node SHOULD also ensure that subsequent Resv messages sent by the node contain the same Admin Status Object.
非リフレッシュパスまたはADMIN_STATUSオブジェクトを含むResvメッセージを受信したエッジノードは、また、それらのローカル状態を更新し、指示された状態に基づいて、任意の適切なローカルアクションを取ります。管理ステータスオブジェクトはRビットがセットで受信された場合、受信エッジノードは、対応する送信メッセージで受信された値を反映すべきです。出口ノードセットADMIN_STATUSオブジェクトのRビットでPathメッセージを受信したノードは、以前にPathメッセージに対応するResvメッセージを発行した場合、具体的に、ノードは、同じ値を持つADMIN_STATUSオブジェクトを含む更新されたResvメッセージを送ります対応するPathメッセージで受信されるように、Rビットを除いて、セット。さらに、出口ノードは、ノードによって送信され、その後のResvメッセージが同じ管理ステータスオブジェクトが含まれていることを確認する必要があります。
Additionally, if an ingress node receives a Resv message with the R bit of the Admin_Status object set, the node SHOULD send an updated Path message containing an Admin_Status object with the same values set, with the exception of the R bit, as received in the corresponding Resv message. Furthermore, the ingress node SHOULD also ensure that subsequent Path messages sent by the node contain the same Admin Status Object.
入口ノードはADMIN_STATUSオブジェクトセットのRビットがResvメッセージを受信した場合に受信され、さらに、ノードは、Rビットを除いて、設定された同じ値を持つADMIN_STATUSオブジェクトを含む更新されたPathメッセージを送りますResvメッセージを対応します。さらに、入口ノードは、ノードによって送信され、後続のパスのメッセージが同じ管理ステータスオブジェクトが含まれていることを確認する必要があります。
In some circumstances, particularly optical networks, it is useful to set the administrative status of an LSP before tearing it down. In such circumstances the procedure SHOULD be followed when deleting an LSP from the ingress:
いくつかの状況、特に光ネットワークでは、それを切断する前に、LSPの管理状態を設定することが有用です。入口からLSPを削除する場合、このような状況で手順に従っされるべきです。
1. The ingress node precedes an LSP deletion by inserting an Admin Status Object in a Path message and setting the Reflect (R) and Delete (D) bits.
1.入口ノードは、Pathメッセージに管理ステータスオブジェクトを挿入し、（R）反射し、（D）ビットを削除して設定することにより、LSPの削除を先行します。
2. Transit and egress nodes process the Admin Status Object as described above. (Alternatively, the egress MAY respond with a PathErr message with the Path_State_Removed flag set, see section 4.4.)
上記のように2トランジットと出口ノードは、管理ステータスオブジェクトを処理します。 （あるいは、出口セクション4.4を参照して、Path_State_Removedフラグが設定されたPathErrメッセージで応答することができます。）
3. Upon receiving the Admin Status Object with the Delete (D) bit set in the Resv message, the ingress node sends a PathTear message downstream to remove the LSP and normal RSVP processing takes place.
削除（D）で管理ステータスオブジェクトを受信する3. Resvメッセージに設定ビット、入口ノードが行わLSPと通常のRSVP処理を除去するために、下流PathTearメッセージを送信します。
In such circumstances the procedure SHOULD be followed when deleting an LSP from the egress:
出口からのLSPを削除するとき、このような状況で手順に従っされるべきです。
1. The egress node indicates its desire for deletion by inserting an Admin Status Object in a Resv message and setting the Reflect (R) and Delete (D) bits.
1.出口ノードは、Resvメッセージに管理ステータスオブジェクトを挿入し、（R）反射し、（D）ビットを削除して設定することにより、削除のためにその要望を示します。
3. Upon receiving the Admin Status Object with the Delete (D) bit set in the Resv message, the ingress node sends a PathTear message downstream to remove the LSP and normal RSVP processing takes place.
削除（D）で管理ステータスオブジェクトを受信する3. Resvメッセージに設定ビット、入口ノードが行わLSPと通常のRSVP処理を除去するために、下流PathTearメッセージを送信します。
It is possible that some nodes along an LSP will not support the Admin Status Object. In the case of a non-supporting transit node, the object will pass through the node unmodified and normal processing can continue. In the case of a non-supporting egress node, the Admin Status Object will not be reflected back in the Resv Message. To support the case of a non-supporting egress node, the ingress SHOULD only wait a configurable period of time for the updated Admin Status Object in a Resv message. Once the period of time has elapsed, the ingress node sends a PathTear message. By default this period of time SHOULD be 30 seconds.
LSPに沿っていくつかのノードは、管理ステータスオブジェクトをサポートしていない可能性があります。非支持トランジットノードの場合には、オブジェクトは、非修飾および通常の処理を継続することができるノードを通過することになります。非支持出口ノードの場合には、管理ステータスオブジェクトが背面のResvメッセージには反映されません。非サポート出口ノードのケースをサポートするために、侵入はResvメッセージ内の更新管理ステータスオブジェクトのために設定可能な期間を待つ必要があります。時間が経過すると、入口ノードはPathTearメッセージを送信します。デフォルトでは、この時間は30秒であるべきです。
Intermediate and egress nodes may trigger the setting of administrative status via the use of Notify messages. To accomplish this, an intermediate or egress node generates a Notify message with the corresponding upstream notify session information. The Admin Status Object MUST be included in the session information, with the appropriate bit or bits set. The Reflect (R) bit MUST NOT be set. The Notify message may be, but is not required to be, encapsulated, see Section 4.3.
中級と出口ノードは、通知メッセージの使用を経由して管理ステータスの設定をトリガすることができます。これを達成するために、中間または出力ノードが、対応するアップストリームで通知メッセージを生成し、セッション情報を通知します。適切なビット又はビットがセットで管理ステータスオブジェクトは、セッション情報に含まれなければなりません。リフレクト（R）ビットが設定されてはいけません。通知メッセージは、かもしれないが、4.3節を参照してください、カプセル化、である必要はありません。
An ingress node receiving a Notify message containing an Admin Status Object with the Delete (D) bit set, SHOULD initiate the deletion procedure described in the previous section. Other bits SHOULD be propagated in an outgoing Path message as normal.
削除（D）ビットが設定された管理状態オブジェクトを含む通知メッセージを受信した入口ノードは、前のセクションで説明削除手順を開始すべきです。他のビットは通常通り送信Pathメッセージに伝播されるべきです。
Some special processing is required in order to cover the case of nodes that do not support the Admin Status Object and other error conditions. Specifically, a node that sends a Notify message containing an Admin Status Object with the Down (D) bit set MUST verify that it receives a corresponding Path message with the Down (D) bit set within a configurable period of time. By default this period of time SHOULD be 30 seconds. If the node does not receive such a Path message, it SHOULD send a PathTear message downstream and either a ResvTear message or a PathErr message with the Path_State_Removed flag set upstream.
いくつかの特別な処理は、管理ステータスオブジェクトや他のエラー状態をサポートしていないノードの場合をカバーするために必要とされます。具体的には、下（D）に対応するPathメッセージを受信したことを確認しなければならないダウン（D）ビットが設定された管理状態オブジェクトを含む通知メッセージを送信するノードは、設定可能な期間内にビットセット。デフォルトでは、この時間は30秒であるべきです。ノードは、Pathメッセージを受信しない場合、それは下流PathTearメッセージを送信したResvTearメッセージまたは上流設定Path_State_Removedフラグ付きのPathErrメッセージのいずれかすべきです。
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 Path message. The choice of the data interface is indicated by the sender of the Path message by including the data channel's interface identifier in the message using a new RSVP_HOP object sub-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 path sender explicitly identifies the component interface used in each direction. The new RSVP_HOP object is used in Resv message to indicate the downstream node's usage of the indicated interface(s).
使用するデータ・インタフェースの選択は、常にPathメッセージの送信者によって行われます。データインタフェースの選択は、新しいRSVP_HOPオブジェクトのサブタイプを使用して、メッセージ内のデータチャネルのインタフェース識別子を含めることによって、Pathメッセージの送信者によって示されています。双方向のLSPのために、送信者は、各方向のデータインタフェースを選択します。全ての場合しかし結束において、上流インターフェースは、下流インタフェースによって暗示されています。束ねるため、パスの送信者は、明示的に各方向に使用されるコンポーネント・インタフェースを識別する。新しいRSVP_HOPオブジェクトが指示されたインターフェース（複数可）の下流ノードの使用状況を示すために、Resvメッセージに使用されます。
The format of the IPv4 IF_ID RSVP_HOP Object is:
IPv4のIF_ID RSVP_HOPオブジェクトの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (3) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 IF_ID RSVP_HOP Object is:
IPv6のIF_ID RSVP_HOPオブジェクトの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (3) | C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Next/Previous Hop Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC2205] for a description of hop address and handle fields. See [RFC3471] for a description of parameters and encoding of TLVs.
ホップアドレスの説明については、[RFC2205]を参照してくださいとフィールドを扱います。パラメータとのTLVの符号化の詳細については[RFC3471]を参照。
An IF_ID RSVP_HOP object is used in place of previously defined RSVP_HOP objects. It is used on links where there is not a one-to-one association of a control channel to a data channel, see [RFC3471]. The Hop Address and Logical Interface Handle fields are used per standard RSVP [RFC2205].
IF_ID RSVP_HOPオブジェクトは、以前に定義されたRSVP_HOPオブジェクトの代わりに使用されます。これは、データチャネルに対する制御チャネルの一対一の関連がない、[RFC3471]を参照リンクで使用されています。ホップアドレスと論理インターフェイスハンドルフィールドは、標準のRSVP [RFC2205]ごとに使用されています。
TLVs are used to identify the data channel(s) associated with an 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 the Path message. The IF_ID RSVP_HOP object SHOULD NOT be used when no TLVs are needed.
TLVは、LSPに関連するデータ・チャネル（単数または複数）を同定するために使用されます。一方向LSPのため、下りデータチャネルが示されなければなりません。双方向のLSPのために、共通のダウンストリームおよびアップストリームデータチャネルが正常に示されています。バンドルリンクを横断する双方向LSP特別な場合には、上りデータチャネルとは異なる下りデータチャネルを指定することが可能です。データ・チャネルは、Pathメッセージの送信者の観点から、指定されています。何のTLVが必要とされていない場合IF_ID RSVP_HOPオブジェクトを使用しないでください。
A node receiving one or more TLVs in a Path message saves their values and returns them in the HOP objects of subsequent Resv messages sent to the node that originated the TLVs.
Pathメッセージ内の1つまたは複数のTLVを受信したノードは、それらの値を保存し、TLVを発信ノードに送信された後続のRESVメッセージのHOPオブジェクトでそれらを返します。
Note, the node originating an IF_ID object MUST ensure that the selected outgoing interface, as specified in the IF_ID object, is consistent with an ERO. A node that receives an IF_ID object SHOULD check whether the information carried in this object is consistent with the information carried in a received ERO, and if not it MUST send a PathErr Message with the error code "Routing Error" and error value of "Bad Explicit Route Object" toward the sender. This check CANNOT be performed when the initial ERO subobject is not the incoming interface.
IF_IDオブジェクトで指定されるように、発信インターフェイスを選択していることを確認しなければならないIF_IDオブジェクトを発信ノードは、EROと一致して、注意してください。 IF_IDオブジェクトを受信したノードは、このオブジェクトで運ばれた情報を受信EROで運ばれた情報と一致しているかどうかを確認する必要があり、そうでない場合には、不良」のエラーコード「ルーティングエラー」と誤差値とのPathErrメッセージを送信しなければなりません送信者に向けて、明示的なルートオブジェクト」。初期EROサブオブジェクトは、着信インターフェイスでない場合は、このチェックは実行できません。
There are cases where it is useful to indicate a specific interface associated with an error. To support these cases the IF_ID ERROR_SPEC Objects are defined.
エラーに関連付けられた特定のインターフェイスを示すために有用である場合があります。これらのケースをサポートするためにIF_ID ERROR_SPECオブジェクトが定義されています。
The format of the IPv4 IF_ID ERROR_SPEC Object is:
IPv4のIF_ID ERROR_SPECオブジェクトの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 IF_ID ERROR_SPEC Object is:
IPv6のIF_ID ERROR_SPECオブジェクトの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Error Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC2205] for a description of address, flags, error code and error value fields. See [RFC3471] for a description of parameters and encoding of TLVs.
アドレス、フラグ、エラーコード及びエラー値フィールドの説明のために[RFC2205]を参照。パラメータとのTLVの符号化の詳細については[RFC3471]を参照。
Nodes wishing to indicate that an error is related to a specific interface SHOULD use the appropriate IF_ID ERROR_SPEC Object in the corresponding PathErr or ResvErr message. IF_ID ERROR_SPEC Objects SHOULD be generated and processed as any other ERROR_SPEC Object, see [RFC2205].
エラーは、特定のインタフェースに関連していることを示すことを望むノードは、対応のPathErr又はResvErrメッセージに適切なIF_ID ERROR_SPECオブジェクトを使用すべきです。 IF_ID ERROR_SPECオブジェクトは[RFC2205]を参照して、他のERROR_SPECオブジェクトとして生成され、処理されるべきです。
The handling of two types of control communication faults is described in this section. The first, referred to as nodal faults, relates to the case where a node losses its control state (e.g., after a restart) but does not loose its data forwarding state. In the second, referred to as control channel faults, relates to the case where control communication is lost between two nodes. The handling of both faults is supported by the Restart_Cap object defined below and require the use of Hello messages.
制御通信障害の二つのタイプの処理は、このセクションに記載されています。最初は、ノード障害と呼ばれる、（再起動後に例えば、）ノード損失がその制御状態の場合にも関するが、状態を転送し、そのデータを失いません。制御チャネル障害と呼ばれる第二に、制御通信は、2つのノード間に失われた場合にも関します。両方の障害の取り扱いは、以下のように定義さRestart_CapオブジェクトでサポートされているとHelloメッセージを使用する必要があります。
Note, the Restart_Cap object MUST NOT be sent when there is no mechanism to detect data channel failures independent of control channel failures.
制御チャネル障害の独立したデータチャネルの障害を検出するための機構がない場合Restart_Capオブジェクトが送信されてはいけません、注意してください。
Please note this section is derived from [PAN-RESTART].
このセクションは、[PAN-RESTART]から導出されますのでご注意ください。
The Restart_Cap Object is carried in Hello messages.
Restart_CapオブジェクトがHelloメッセージで運ばれます。
The format of the Restart_Cap Object is:
Restart_Capオブジェクトの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(131)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Restart Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Restart Time: 32 bits
再起動時間：32ビット
Restart Time is measured in milliseconds. Restart Time SHOULD be set to the sum of the time it takes the sender of the object to restart its RSVP-TE component (to the point where it can exchange RSVP Hello with its neighbors) and the communication channel that is used for RSVP communication. A value of 0xffffffff indicates that the restart of the sender's control plane may occur over an indeterminate interval and that the operation of its data plane is unaffected by control plane failures. The method used to ensure continued data plane operation is outside the scope of this document.
再起動時間はミリ秒単位で測定されます。再起動時は、その（それはその隣人とRSVPハローを交換することができる点まで）RSVP-TE成分とRSVPの通信のために使用される通信チャネルを再起動するオブジェクトの送信者にかかる時間との和に設定されるべきです。 0xFFFFFFFFの値は、送信者の制御プレーンの再起動が不定間隔でそのデータプレーンの動作は、制御プレーンの障害によって影響を受けないことが起こり得ることを示しています。継続的なデータプレーン動作を保証するために使用される方法は、この文書の範囲外です。
Recovery Time: 32 bits
リカバリ時間：32ビット
The period of time, in milliseconds, that the sender desires for the recipient to re-synchronize RSVP and MPLS forwarding state with the sender after the re-establishment of Hello synchronization. A value of zero (0) indicates that MPLS forwarding state was not preserved across a particular reboot.
時間の期間は、ミリ秒単位で、送信者はこんにちは同期の再確立後に送信者と受信者の状態を転送して再同期RSVPへとMPLSのために望んでいます。ゼロ（0）の値はMPLS転送状態が特定のリブート保持されなかったことを示しています。
Nodes supporting state recovery advertise this capability by carrying the Restart_Cap object in Hello messages. Such nodes MUST include the Restart_Cap object in all Hello messages. (Note that this includes Hello messages containing ACK objects.) Usage of the special case Recovery Time values is described in greater detail below.
状態の回復をサポートするノードは、HelloメッセージにRestart_Capオブジェクトを行うことにより、この機能をアドバタイズします。このようなノードは、すべてのHelloメッセージにRestart_Capオブジェクトを含まなければなりません。 （これはACKオブジェクトを含むHelloメッセージを含むことに留意されたい。）特殊なケース回復時間値の使用は、以下でより詳細に説明します。
When a node receives a Hello message with the Restart_Cap object, it SHOULD record the values of the parameters received.
ノードはRestart_CapオブジェクトにHelloメッセージを受信すると、受信したパラメータの値を記録する必要があります。
When a node determines that RSVP communication with a neighbor has been lost, and the node previously learned that the neighbor supports state recovery, the node SHOULD wait at least the amount of time indicated by the Restart Time indicated by the neighbor before invoking procedures related to communication loss. A node MAY wait a different amount of time based on local policy or configuration information.
ノードがネイバーとRSVP通信が失われた、とノードが以前に隣人が状態の回復をサポートしていることを学んだと判断した場合は、ノードはに関連する手順を呼び出す前に、隣人で示される再起動時間によって示された時間の少なくとも量を待つ必要があります通信損失。ノードは、ローカルポリシーまたは設定情報に基づいて、時間の異なる量を待ってもよいです。
During this waiting period, all Hello messages MUST be sent with a Dst_Instance value set to zero (0), and Src_Instance should be unchanged. While waiting, the node SHOULD also preserve the RSVP and MPLS forwarding state for (already) established LSPs that traverse the link(s) between the node and the neighbor. In a sense with respect to established LSPs the node behaves as if it continues to receive periodic RSVP refresh messages from the neighbor. The node MAY clear RSVP and forwarding state for the LSPs that are in the process of being established when their refresh timers expire. Refreshing of Resv and Path state SHOULD be suppressed during this waiting period.
この待機期間中は、すべてのHelloメッセージは（0）をゼロに設定Dst_Instance値を送らなければなりません、とSrc_Instanceは変わらないはずです。待っている間、ノードは、ノードと、隣接間のリンクをトラバース（既に）を設立したLSPのためのRSVPとMPLS転送状態を保存すべきです。それは隣人からの定期的なRSVPリフレッシュメッセージを受信し続けるかのように確立されたLSPに対する意味でノードが動作します。ノードは、RSVPをクリアし、そのリフレッシュタイマーが満了したときに確立されつつあるのLSPの状態を転送するかもしれません。 Resvとパス状態のリフレッシュは、この待機期間中に抑制されるべきである（SHOULD）。
During this waiting period, the node MAY inform upstream nodes of the communication loss via a PathErr and/or upstream Notify message with "Control Channel Degraded State" indication. If such notification has been sent, then upon restoration of the control channel the node
この待機期間中、ノードは、のPathErrを介して、通信喪失の上流のノードに通知することができる、および/または上流の「制御チャネル劣化状態」指示のメッセージを通知します。そのような通知が送信された場合、制御の復帰時にノードチャネル
MUST inform other nodes of the restoration via a PathErr and/or upstream Notify message with "Control Channel Active State" indication. (Specific error codes have been assigned by IANA.)
PathErrを介して復元の他のノードに通知し、および/または上流の「制御チャネルアクティブ状態」の表示とメッセージを通知しなければなりません。 （特定のエラーコードは、IANAによって割り当てられています。）
When a new Hello message is received from the neighbor, the node must determine if the fault was limited to the control channel or was a nodal fault. This determination is based on the Src_Instance received from the neighbor. If the value is different than the value that was received from the neighbor prior to the fault, then the neighbor should be treated as if it has restarted. Otherwise, the the fault was limited control channel. Procedures for handling each case are described below.
新しいHelloメッセージがネイバーから受信した場合、障害が制御チャネルに限定されていたか、リンパ節のせいだった場合、ノードが判断しなければなりません。この決意は、ネイバーから受信Src_Instanceに基づいています。値が故障する前に、ネイバーから受信された値と異なる場合、それは再起動されたかのように、そして、隣人が扱われるべきです。そうしないと、障害が制限された制御チャネルでした。各ケースを処理するための手順は以下の通りです。
In the case of control channel faults, the node SHOULD refresh all state shared with the neighbor. Summary Refreshes [RFC2961] with the ACK_Desired flag set SHOULD be used, if supported. Note that if a large number of messages are need, some pacing should be applied. All state SHOULD be refreshed within the Recovery time advertised by the neighbor.
制御チャネル故障の場合に、ノードは、ネイバーと共有するすべての状態を更新すべきです。サポートされている場合ACK_Desiredフラグが設定された要約の更新[RFC2961]は、使用されるべきです。多数のメッセージが必要とされている場合、一部のペーシングを適用する必要があることに注意してください。すべての状態は隣人によってアドバタイズ復旧時間内にリフレッシュされるべきである（SHOULD）。
Recovering from nodal faults uses one new object and other existing protocol messages and objects.
リンパ節の障害からの回復は、1つの新しいオブジェクトと他の既存のプロトコルメッセージとオブジェクトを使用しています。
The Recovery_Label object is used during the nodal fault recovery process. The format of a Recovery_Label object is identical to a generalized label. A Recovery_Label object uses Class-Number 34 (of form 0bbbbbbb) and the C-Type of the label being suggested.
Recovery_Labelオブジェクトは、結節障害復旧プロセス中に使用されています。 Recovery_Labelオブジェクトの形式は、一般的なラベルと同じです。 Recovery_Labelオブジェクトは、（フォーム0bbbbbbbはの）クラス番号34を使用し、ラベルのC-Typeが提案されています。
After a node restarts its control plane, a node that supports state recovery SHOULD check whether it was able to preserve its MPLS forwarding state. If no forwarding state from prior to the restart was preserved, then the node MUST set the Recovery Time to 0 in the Hello message the node sends to its neighbors.
ノードは、その制御プレーンを再起動した後、状態の回復をサポートするノードは、そのMPLSフォワーディングステートを維持することができたかどうかを確認する必要があります。再起動する前からの転送状態が保存されなかった場合は、そのノードは、ノードがネイバーに送信するHelloメッセージに0に回復時間を設定しなければなりません。
If the forwarding state was preserved, then the node initiates the state recovery process. The period during which a node is prepared to support the recovery process is referred to as the Recovery Period. The total duration of the Recovery Period is advertised by the recovering node in the Recovery Time parameter of the Restart_Cap object. The Recovery Time MUST be set to the duration of the
転送状態を保存した場合、ノードは、状態回復プロセスを開始します。ノードが回復プロセスをサポートするために用意されている期間は、回復期間と呼ばれます。回復期間の総持続時間はRestart_Capオブジェクトの回復時間パラメータの回復ノードによって通知されます。回復時間は、期間中に設定しなければなりません
Recovery Period in all Hello messages sent during the Recovery Period. State that is not resynchronized during the Recovery Period SHOULD be removed at the end of the Period.
回復期間中に送信されたすべてのHelloメッセージでの回復期間。回復期間中に再同期されていない状態は、期間の終了時に削除する必要があります。
Note that if during Hello synchronization the restarting node determines that a neighbor does not support state recovery, and the restarting node maintains its MPLS forwarding state on a per neighbor basis, the restarting node should immediately consider the Recovery Period with that neighbor completed. Forwarding state may be considered to be maintained on a per neighbor basis when per interface labels are used on point-to-point interfaces.
こんにちは、同期中に再開ノードは、隣人が状態の回復をサポートしていないと判断し、再起動するノードは、隣接ごとにそのMPLSフォワーディングステートを維持した場合、再起動ノードはすぐに完了しているネイバーと回復期間を考慮すべきであることに注意してください。転送状態は、インタフェースのラベルごとに、ポイントツーポイントインターフェイスで使用される場合、隣接ごとに維持されると考えることができます。
When a node receives a Path message during the Recovery Period, the node first checks if it has an RSVP state associated with the message. If the state is found, then the node handles this message according to previously defined procedures.
それはメッセージに関連付けられたRSVPの状態を有する場合、ノードは、回復期間中にノードを最初にチェックをパスメッセージを受信した場合。状態が見つかった場合、そのノードは、以前に定義された手順に従って、このメッセージを処理します。
If the RSVP state is not found, and the message does not carry a Recovery_Label object, the node treats this as a setup for a new LSP, and handles it according to previously defined procedures.
RSVP状態が見つからない場合、メッセージはRecovery_Labelオブジェクトを搬送しない場合、ノードは、新しいLSPの設定としてこれを扱い、先に定義された手順に従ってそれを処理します。
If the RSVP state is not found, and the message carries a Recovery_Label object, the node searches its MPLS forwarding table (the one that was preserved across the restart) for an entry whose incoming interface matches the Path message and whose incoming label is equal to the label carried in the Recovery_Label object.
RSVP状態が見つからない場合、メッセージはRecovery_Labelオブジェクトを運ぶ、ノードは、その着信インターフェイス着信ラベルに等しく、Pathメッセージと一致するエントリを、そのMPLS転送テーブル（再起動を横切って保存したもの）を検索する場合Recovery_Labelオブジェクトで運ばれたラベル。
If the MPLS forwarding table entry is not found, the node treats this as a setup for a new LSP, and handles it according to previously defined procedures.
MPLS転送テーブルエントリが見つからない場合、ノードは新しいLSPの設定としてこれを扱い、先に定義された手順に従ってそれを処理します。
If the MPLS forwarding table entry is found, the appropriate RSVP state is created, the entry is bound to the LSP associated with the message, and related forwarding state should be considered as valid and refreshed. Normal Path message processing should also be conducted. When sending the corresponding outgoing Path message the node SHOULD include a Suggested_Label object with a label value matching the outgoing label from the now restored forwarding entry. The outgoing interface SHOULD also be selected based on the forwarding entry. In the special case where a restarting node also has a restating downstream neighbor, a Recovery_Label object should be used instead of a Suggested_Label object.
MPLS転送テーブルエントリが見つかった場合、適切なRSVP状態が作成され、エントリは、メッセージに関連付けられたLSPに結合され、そして関連フォワーディング状態が有効とリフレッシュと考えるべきです。通常のパスメッセージ処理も行われるべきです。対応する発信Pathメッセージを送信するとき、ノードは、現在復元転送エントリから出ラベルと一致するラベル値を持つSuggested_Labelオブジェクトを含めるべきです。発信インターフェースは、転送エントリに基づいて選択されるべきです。再開ノードも修正再表示下流隣人を持つ特殊な場合には、Recovery_Labelオブジェクトは代わりSuggested_Labelオブジェクトを使用すべきです。
Additionally, for bidirectional LSPs, the node extracts the label from the UPSTREAM_LABEL object carried in the received Path message, and searches its MPLS forwarding table for an entry whose outgoing label is equal to the label carried in the object (in the case of link bundling, this may also involved first identifying the appropriate incoming component link).
また、双方向のLSPのために、ノードは、受信したPathメッセージで運ばUPSTREAM_LABELオブジェクトからラベルを抽出し、その出力ラベルリンクバンドリングの場合（オブジェクトで運ばラベルに等しいエントリをそのMPLS転送テーブルを検索しこれはまた、最初の）適切な受信コンポーネントリンクを識別する関与してもよいです。
If the MPLS forwarding table entry is not found, the node treats this as a setup for a new LSP, and handles it according to previously defined procedures.
MPLS転送テーブルエントリが見つからない場合、ノードは新しいLSPの設定としてこれを扱い、先に定義された手順に従ってそれを処理します。
If the MPLS forwarding table entry is found, the entry is bound to the LSP associated with the Path message, and the entry should be considered to be re-synchronized. In addition, if the node is not the tail-end of the LSP, the corresponding outgoing Path messages is sent with the incoming label from that entry carried in the UPSTREAM_LABEL object.
MPLS転送テーブルエントリが見つかった場合、エントリはPathメッセージに関連付けられたLSPに結合され、エントリが再同期させることが考慮されるべきです。ノードは、LSPの末尾でない場合に加えて、対応する発信Pathメッセージは、UPSTREAM_LABELオブジェクトで運ばそのエントリからの着信ラベルで送信されます。
During the Recovery Period, Resv messages are processed normally with two exceptions. In the case that a forwarding entry is recovered, no new label or resource allocation is required while processing the Resv message. The second exception is that ResvErr messages SHOULD NOT be generated when a Resv message with no matching Path state is received. In this case the Resv message SHOULD just be silently discarded.
回復期間中、RESVメッセージは、2つの例外を除いて正常に処理されます。 Resvメッセージを処理中に転送エントリが回収される場合には、新しいラベルまたはリソース割り当てが必要とされません。第二の例外は、一致するパス状態とResvメッセージを受信したときResvErrメッセージが生成されるべきではないことです。この場合、Resvメッセージはただ静かに捨てられるべきです。
The following specifies the procedures that apply when the node reestablishes communication with the neighbor's control plane within the Restart Time, the node determines (using the procedures defined in Section 5 of [RFC3209]) that the neighbor's control plane has restarted, and the neighbor was able to preserve its forwarding state across the restart (as was indicated by a non-zero Recovery Time carried in the Restart_Cap object of the RSVP Hello messages received from the neighbor). Note, a Restart Time value of 0xffffffff indicates an infinite Restart Time interval.
以下では、ノードが再起動した時間内に隣人の制御プレーンとの通信を再確立するときに適用する手順を指定し、ノードは、近隣の制御プレーンが再起動され、そして隣人であったこと（[RFC3209]のセクション5で定義された手順を使用して）決定します（ハローメッセージは、ネイバーから受信RSVPのRestart_Capオブジェクトで運ば非ゼロ回復時間によって示されたように）再起動を横切ってその転送状態を維持することができます。注、0xffffffffの再起動の時間価値は無限再起動の時間間隔を示します。
Upon detecting a restart with a neighbor that supports state recovery, a node SHOULD refresh all Path state shared with that neighbor. The outgoing Path messages MUST include a Recovery_Label object containing a label value corresponding to the label value received in the most recently received corresponding Resv message. All Path state SHOULD be refreshed within approximately 1/2 of the Recovery time advertised by the restarted neighbor. If there are many LSP's going through the restarting node, the neighbor node should avoid sending Path messages in a short time interval, as to avoid unnecessary stressing the restarting node's CPU. Instead, it should spread the messages across 1/2 the Recovery Time interval.
状態の回復をサポートしているネイバーと再起動を検出すると、ノードはその隣人と共有するすべてのパスの状態をリフレッシュする必要があります。送信するPathメッセージは、最後に受信し、対応するResvメッセージで受信したラベル値に対応するラベルの値を含むRecovery_Labelオブジェクトを含まなければなりません。すべてのパスの状態が約1/2に再起動隣人によってアドバタイズ回復時間の内にリフレッシュされるべきである（SHOULD）。 LSPのは、再起動するノードを経由する多くがある場合は、隣接ノードが再開ノードのCPUを強調し、不必要な避けるために、短い時間間隔でパスメッセージを送信することは避けてください。代わりに、それは1/2のリカバリ時間間隔全体にメッセージを広める必要があります。
After detecting a restart of a neighbor that supports state recovery, all Resv state shared with the restarting node MUST NOT be refreshed until a corresponding Path message is received. This requires suppression of normal Resv and Summary Refresh processing to the neighbor during the Recovery Time advertised by the restarted neighbor. As soon as a corresponding Path message is received a Resv message SHOULD be generated and normal state processing SHOULD be re-enabled.
対応するPathメッセージが受信されるまで再起動するノードをリフレッシュしてはならないとの状態の回復をサポートしているネイバーの再起動を検出した後、すべてのResv状態が共有しました。これは、再起動隣人によって広告回復時間の間に隣人への通常のResvと概要更新処理の抑制を必要とします。対応するPathメッセージが受信されるとすぐにResvメッセージが生成されるべきであり、通常の状態処理が再度有効にする必要があります。
This message summarizes RSVP message formats and handling as modified by GMPLS.
GMPLSによって修正されたこのメッセージは、RSVPメッセージ形式とハンドリングをまとめました。
This section presents the RSVP message related formats as modified by this document. Where they differ, formats for unidirectional LSPs are presented separately from bidirectional LSPs. Unmodified formats are not listed. Again, MESSAGE_ID and related objects are defined in [RFC2961].
この文書によって修正されたこのセクションでは、RSVPメッセージに関連するフォーマットを提示します。それらが異なる場合には、単方向のLSPのためのフォーマットは、双方向のLSPとは別に提示されています。非修飾形式は表示されません。再び、MESSAGE_IDおよび関連オブジェクトは[RFC2961]で定義されています。
The format of a Path message is as follows:
次のようにPathメッセージの形式は次のとおりです。
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
The format of the sender description for unidirectional LSPs is:
単方向のLSPの送信者の記述の形式は次のとおりです。
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
The format of the sender description for bidirectional LSPs is:
双方向のLSPの送信者の記述の形式は次のとおりです。
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
<UPSTREAM_LABEL>
The format of a PathErr message is as follows:
以下の通りのPathErrメッセージの形式は次のとおりです。
<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
The format of a Resv message is as follows:
次のようにResvメッセージの形式は次のとおりです。
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> is not modified by this document.
<フロー記述子リスト>この文書では変更されません。
The format of a ResvErr message is as follows:
次のようにResvErrメッセージの形式は次のとおりです。
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ]
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<STYLE> <error flow descriptor>
The modified Hello message format is:
こんにちは変更されたメッセージの形式は次のとおりです。
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
[ <RESTART_CAP> ]
RSVP was designed to handle dynamic (non-explicit) path changes and non RSVP hops along the path. To this end, the Path, PathTear and ResvConf messages carry the destination address of the session in the IP header. In generalized signaling, routes are usually explicitly signaled. Further, hops that cannot allocate labels cannot exist in the path of an LSP. A further difference with traditional RSVP is that at times, an RSVP message may travel out of band with respect to an LSP's data channel.
RSVPは、動的（非明示）経路の変更及び経路に沿って非RSVPホップを処理するように設計しました。このため、パスは、PathTearとResvConfメッセージは、IPヘッダにセッションの宛先アドレスを運びます。一般シグナリングにおいて、ルートは通常、明示的にシグナリングされます。さらに、ラベルを割り当てることができないのホップは、LSPの経路に存在することができません。伝統的なRSVPとのさらなる違いは時間で、RSVPメッセージはLSPのデータチャネルに対して帯域外で移動することができるということです。
When a node is sending a Path, PathTear or ResvConf message to a node that it knows to be adjacent at the data plane (i.e., along the path of the LSP), it SHOULD address the message directly to an address associated with the adjacent node's control plane. In this case the router-alert option SHOULD not be included.
ノードは、それが（LSPの経路に沿って、すなわち、）データ面に隣接するように知っているノードに、PathTear又はResvConfメッセージをパスを送信している場合は、隣接ノードの関連付けられたアドレスにメッセージを直接に対処すべきですコントロールプレーン。この場合、ルータアラートオプションが含まれるべきではありません。
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, including Igor Bryskin, Adrian Farrel and Dimitrios Pendarakis. Portions of Section 4 are based on suggestions and text proposed by Adrian Farrel.
貴重なコメント入力はイゴールBryskin、エードリアンファレルとディミトリオスPendarakis含めた人の数、から受け取りました。第4節の一部は、エードリアンファレルによって提案された提案とテキストに基づいています。
The security considerations section is based on text provided by Steven Bellovin.
セキュリティの考慮セクションはスティーブンBellovin氏によって提供されたテキストに基づいています。
RSVP message security is described in [RFC2747] and provides message integrity and node authentication. For hop-by-hop messages, this document introduces no other new security considerations.
RSVPメッセージのセキュリティは、[RFC2747]に記載されており、メッセージの保全とノード認証を提供しています。ホップバイホップメッセージについては、この文書には、他の新しいセキュリティ問題も紹介しません。
This document introduces the ability to send a Notify message in a non-hop-by-hop fashion. This precludes RSVP's hop-by-hop integrity and authentication model. In the case where RSVP is generating end-to-end messages and the same level of security provided by [RFC2747] is desired, the standard IPSEC based integrity and authentication can be used. Alternatively, the sending of no-hop-by-hop Notify messages can be disabled.
この文書では、非ホップバイホップファッションに通知メッセージを送信する機能が導入されました。これは、RSVPのホップバイホップの整合性および認証モデルを排除します。 RSVPは、エンドツーエンドのメッセージを生成して、[RFC2747]で提供されるセキュリティの同じレベルが望まれる場合には、標準的なIPSECベースの整合性と認証を使用することができます。また、無ホップバイホップの送信は、メッセージを無効にすることができます希望します。
When using IPSEC to provide message authentication, the following apply:
メッセージ認証を提供するために、IPSECを使用する場合は、以下が適用されます。
Selectors The selector is identified by RSVP messages exchanged between a pair of non-adjacent nodes. The nodes are identified by the source and destination IP address of the inner IP header used on Notify messages.
セレクタは、セレクタは、非隣接ノードの対の間で交換RSVPメッセージによって識別されます。ノードは、通知メッセージで使用される内部IPヘッダの送信元および宛先IPアドレスによって識別されます。
Mode In this application, transport mode is the proper choice. The information being communicated is generally not confidential, so encryption need not be used. Either AH [RFC2402] or ESP [RFC2406] MAY be used; if ESP is used, the sender's IP address MUST be checked against the IP address asserted in the key management exchange.
このアプリケーションモードでは、トランスポートモードでは適切な選択です。通信されている情報は、一般的に機密ではないので、暗号化を使用する必要はありません。 AH [RFC2402]またはESP [RFC2406]のいずれかが使用されるかもしれません。 ESPを使用する場合は、送信者のIPアドレスは、IPアドレスと照合しなければならない鍵管理引き換えに主張しました。
Key Management To permit replay detection, an automated key management system SHOULD be used, most likely IKE [RFC2409]. Configured keys MAY be used.
キー管理は、リプレイの検出を可能にするために、自動化された鍵管理システムを使用する必要がある、最も可能性の高いIKE [RFC2409]。構成されたキーを使用することができます。
Security Policy Messages MUST NOT be accepted except from nodes that are not known to the recipient to be authorized to make such requests.
セキュリティポリシーのメッセージが受信者に知られていないノードからそのような要求を行うことを許可することを除いて受け入れてはなりません。
Identification Shared keys mechanisms should be adequate for initial deployments and smaller networks. For larger-scale deployments, certificate-based IKE should be supported. Whatever scheme is used, it must tie back to a source IP address in some fashion.
識別共有鍵メカニズムは、初期導入や小規模なネットワークのための十分なはずです。大規模な展開では、証明書ベースのIKEがサポートされなければなりません。どのようなスキームは、それが何らかの形で送信元IPアドレスに戻って固定する必要があり、使用されています。
Availability Many routers and switches already support IPSEC. For cases where IPSEC is unavailable and security is required, Notify messages MUST be sent hop-by-hop.
可用性多くのルータやスイッチは、すでにIPSECをサポートしています。 IPSECが使用できないとセキュリティが必要な場合のために、通知メッセージは、ホップバイホップを送らなければなりません。
IANA assigns values to RSVP protocol parameters. Within the current document multiple objects are defined. Each of these objects contain C-Types. This section defines the rules for the assignment of the related C-Type values. This section uses the terminology of BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [BCP26].
IANAは、プロトコルパラメータをRSVPに値を割り当てます。現在のドキュメント内で複数のオブジェクトが定義されています。これらの各オブジェクトは、C-タイプが含まれています。このセクションでは、関連するC型値の割り当てのための規則を定義します。このセクションでは、[BCP26]「RFCでIANA問題部に書くためのガイドライン」BCP 26の用語を使用しています。
As per [RFC2205], C-Type is an 8-bit number that identifies the function of an object. All possible values except zero are available for assignment.
[RFC2205]に従って、C型は、オブジェクトの機能を識別する8ビットの数です。ゼロ以外のすべての可能な値は、割り当てのために利用可能です。
The assignment of C-Type values of the objects defined in this document fall into three categories. The first category inherit C-Types from the Label object, i.e., object class number 16 [RFC3209]. IANA is requested to institute a policy whereby all C-Type values assign for the Label object are also assigned for the following objects:
この文書で定義されたオブジェクトのC-Type値の割り当ては、次の3つのカテゴリに分類されます。最初のカテゴリ、すなわち、オブジェクトクラス番号16 [RFC3209]、ラベルオブジェクトからC-タイプを継承します。 IANAは、すべてのC-Type値は、次のオブジェクトに対して割り当てられたラベルオブジェクトに割り当てることにより、ポリシーを制定するように要求されます。
o Suggested_Label (Class-Num 129) o Upstream_Label (Class-Num 35) o Recovery_Label (Class-Num 34)
O Suggested_Label（クラス民129）O UPSTREAM_LABEL（クラス民35）O Recovery_Label（34クラスNUM）
The second category of objects follow independent policies. Specifically, following the policies outlined in [BCP26], C-Type values in the range 0x00 - 0x3F are allocated through an IETF Consensus action, values in the range 00x40 - 0x5F are allocated as First Come First Served, and values in the range 0x60 - 0x7F are reserved for Private Use. This policy applies to the following objects.
オブジェクトの第二のカテゴリーは、独立したポリシーに従ってください。 0x3F IETFコンセンサス作用によって割り当てられ、範囲00x40の値 - - [BCP26]に概説された方針以下、範囲は0x00でC型の値は、具体的に、0x5Fは、まず最初に配信来るように割り当てられ、範囲0x60での値であります - 0x7Fのは、私的使用のために予約されています。このポリシーは、次のオブジェクトに適用されます。
o Label_Set (Class-Num 36) o Notify_Request (Class-Num 195) o Protection (Class-Num 37) o Admin Status (Class-Num 196) o Restart_Cap (Class-Num 131)
O Label_Set（クラス民36）O Notify_Request（クラス民195）O Restart_Cap（131クラスNUM）O管理ステータスO保護（クラス民37）（クラス民196）
The assignment of C-Type values for the remaining object, the Acceptable_Label_Set object, follows the assignment of C-Type values of the Label_Set object. IANA will institute a policy whereby all C-Type values assigned for the Label_Set object are also assigned for the Acceptable_Label_Set object.
残りのオブジェクトのためのC型値の割り当て、Acceptable_Label_Setオブジェクトは、Label_SetオブジェクトのC-Type値の割り当てに従います。 IANAはLabel_Setオブジェクトに割り当てられたすべてのC型値もAcceptable_Label_Setオブジェクトに対して割り当てられていることにより、ポリシーを制定します。
This section summarizes values used in this document that have been assigned by IANA.
このセクションでは、IANAによって割り当てられている。この文書で使用される値をまとめたもの。
---------------------------------------------------------------------
Message Types
o Notify message (Message type = 21)
O Notifyメッセージ（メッセージタイプ= 21）
---------------------------------------------------------------------
Class Types
o RSVP_HOP (C-Num 3) - IPv4 IF_ID RSVP_HOP (C-type = 3) - IPv6 IF_ID RSVP_HOP (C-type = 4)
O RSVP_HOP（C-民3） - IPv4のIF_ID RSVP_HOP（C型= 3） - IPv6のIF_ID RSVP_HOP（C型= 4）
o ERROR_SPEC (C-Num 6) - IPv4 IF_ID ERROR_SPEC (C-type = 3) - IPv6 IF_ID ERROR_SPEC (C-type = 4)
O ERROR_SPEC（C-テンキー6） - IPv4のIF_ID ERROR_SPEC（C型= 3） - IPv6のIF_ID ERROR_SPEC（C型= 4）
o LABEL_REQUEST (Class-Num 19) - Generalized_Label_Request (C-Type = 4)
LABEL_REQUEST（クラス民19）O - Generalized_Label_Request（C-タイプ= 4）
o RSVP_LABEL (Class-Num = 16) - Generalized_Label (C-Type = 2) - Waveband_Switching_Label C-Type (C-Type = 3)
O RSVP_LABEL（クラス民= 16） - Generalized_Label（Cタイプ= 2） - Waveband_Switching_Label C型（C-タイプ= 3）
---------------------------------------------------------------------
New Class-Nums, C-Types inherited from Label object (same as CNum16)
o RECOVERY_LABEL Class-Num of form 0bbbbbbb (= 34) o SUGGESTED_LABEL Class-Num of form 10bbbbbb (= 129) o UPSTREAM_LABEL Class-Num of form 0bbbbbbb (= 35)
Oフォーム0bbbbbbbはUPSTREAM_LABELのクラス民O SUGGESTED_LABELフォーム10bbbbbbのクラス民（= 129）Oフォーム0bbbbbbbは（= 34）のRECOVERY_LABELクラス民（= 35）
---------------------------------------------------------------------
New Class-Nums
o LABEL_SET Class-Num of form 0bbbbbbb (= 36) - Type 1 (C-Type = 1) o ACCEPTABLE_LABEL_SET Class-Num of form 10bbbbbb (= 130) - Type 1 Acceptable_Label_Set (C-type from label_set cnum) o NOTIFY_REQUEST Class-Num of form 11bbbbbb (= 195) - IPv4 Notify Request (C-Type = 1) - IPv6 Notify Request (C-Type = 2) o PROTECTION Class-Num of form 0bbbbbbb (= 37) - Type 1 (C-Type = 1)
フォーム0bbbbbbbはのO LABEL_SETクラス民（= 36） - タイプ1（C-タイプ= 1）フォーム10bbbbbbのACCEPTABLE_LABEL_SETクラス民（= 130）O - タイプ1 Acceptable_Label_Set（label_set CNUMからC型）NOTIFY_REQUESTクラス - Oフォーム11bbbbbbのNUM（= 195） - IPv4の要求を通知する（C-タイプ= 1） - IPv6の要求を通知する（C-タイプ= 2）Oフォーム0bbbbbbbは保護クラスNUM（= 37） - タイプ1（C-タイプ= 1）
o ADMIN STATUS Class-Num of form 11bbbbbb (= 196)
- Type 1 (C-Type = 1)
o RESTART_CAP Class-Num of form 10bbbbbb (= 131)
- Type 1 (C-Type = 1)
---------------------------------------------------------------------
ERO/RRO subobject types
o Label ERO subobject Type 3 - Label
OラベルEROサブオブジェクトタイプ3 - ラベル
o Label RRO subobject
Type 3 - Label
---------------------------------------------------------------------
Error codes
o "Routing problem/Label Set" (value = 11)
o "Routing problem/Switching Type" (value = 12)
(duplicate code 13 dropped)
o "Routing problem/Unsupported Encoding" (value = 14)
o "Routing problem/Unsupported Link Protection" (value = 15)
o "Notify Error/Control Channel Active State" (value = 4)
o "Notify Error/Control Channel Degraded State" (value = 5)
---------------------------------------------------------------------
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月。
[RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.（エド。）、張、L.、Berson氏、S.、ハーツォグ、S.とS.ヤミン、 "リソース予約プロトコル - バージョン1の機能的な仕様"、RFC 2205、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2401, November 1998.
[RFC2402]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2401、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2401, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2401、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベーカー、F.、リンデル、B.及びM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]バーガー、L.、ガン、D.、ツバメ、G.、パン、P.、Tommasi、F.及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、RFC 2961、2001年4月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニバサン、V.およびG.ツバメ、 "RSVP-TE：ExtensionsがLSPトンネルのためのRSVPする"、RFC 3209、2001年12月。
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、エディタ、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource Reservation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K.とY. Rekhter、 "リソース予約プロトコルでアンナンバードリンクシグナリング - トラフィックエンジニアリング（RSVP-TE）"、RFC 3477、2003年1月。
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[BCP26] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[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。
[PAN-RESTART] Pan, P., et. al., "Graceful Restart Mechanism for RSVP-TE", Work in Progress.
[PAN-RESTART]パン、P.、ら。ら、「RSVP-TEのためのグレースフルリスタートメカニズム」が進行中で働いています。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
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
John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138
ジョン・ドレイクCalientネットワーク5853ルーフェラーリカリフォルニア州サンノゼ95138
Phone: +1 408 972 3720 EMail: jdrake@calient.net
電話：+1 408 972 3720 Eメール：jdrake@calient.net
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
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Kireeti Kompellaジュニパーネットワークス株式会社1194 N.マチルダアベニュー。サニーベール、CA 94089
EMail: kireeti@juniper.net
メールアドレス：kireeti@juniper.net
Jonathan P. Lang EMail: jplang@ieee.org
ジョナサンP.ラングEメール：jplang@ieee.org
Fong Liaw Solas Research, LLC
フォンLiawソラスリサーチ、LLC
EMail: fongliaw@yahoo.com
メールアドレス：fongliaw@yahoo.com
Eric Mannie Independent Consultant 2 Avenue de la Folle Chanson 1050 Brussels Belgium
エリック・マニー独立コンサルタントマッドソング1050ブリュッセルベルギーの2アベニュー
EMail: eric_mannie@hotmail.com
メールアドレス：eric_mannie@hotmail.com
Ping Pan Ciena 10480 Ridgeview Court Cupertino, CA 95014
Pingのパンシエナ10480 Ridgeview裁判所クパチーノ、CA 95014
Phone: 408-366-4700 EMail: ppan@ciena.com
電話：408-366-4700 Eメール：ppan@ciena.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
Yakov Rekhter Juniper Networks, Inc.
ヤコフ・レックタージュニパーネットワークス株式会社
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
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
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機能のための基金は現在、インターネット協会によって提供されます。