[要約] RFC 3473は、GMPLSのRSVP-TE拡張に関する規格です。このRFCの目的は、GMPLSネットワークでのトラフィックエンジニアリングとリソース予約をサポートするためのプロトコル拡張を提供することです。
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.
Copyright（c）The Internet Society（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をサポートするために必要なマルチプロトコルラベルスイッチング（MPLS）リソース予約プロトコル - トラフィックエンジニアリング（RSVP-TE）シグナル伝達への拡張について説明します。一般化されたMPLSは、MPLSコントロールプレーンを拡張して、時間帯（例えば、同期光ネットワークと同期デジタル階層、SONET/SDH）、波長（光lambdas）および空間スイッチング（たとえば、出力ポートまたは発信ポートまたはファイバーへの繊維）を包含します。このドキュメントでは、拡張機能の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.
一般化されたMPLSは、サポートパケット（PSC）インターフェイスからMPLSを拡張し、3つの新しいクラスのインターフェイスとスイッチングのサポートを含めるために、タイムディビジョンマルチプレックス（TDM）、LAMBDAスイッチ（LSC）、ファイバースイッチ（FSC）をサポートします。[RFC3471]には、新しいクラスのインターフェイスとスイッチングをサポートするために必要な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の他の機能に加えて、このドキュメントは、迅速な障害通知をサポートするRSVP-TE固有の機能も定義しています。セクション4.2および4.3を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
This section defines formats for a generalized label request, a generalized label, support for waveband switching, suggested label and label sets.
このセクションでは、一般化されたラベルリクエストのフォーマット、一般化されたラベル、ウェーブバンドスイッチングのサポート、提案されたラベルセット、ラベルセット。
A 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.
パスメッセージには、特定のLSP（ラベルスイッチ付きパス）エンコードタイプとして、トランジットLSRによる切り替えの最大の柔軟性を可能にする必要があります。一般化されたラベル要求オブジェクトは、イングレスノードによって設定され、トランジットノードで透過的に通過し、出力ノードで使用されます。スイッチングタイプフィールドは、ホップバイホップを更新することもできます。
The format of a Generalized Label Request 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 (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.
一般化されたラベルリクエストを含むパスメッセージの処理は、要求されたパラメーターが、着信ラベルが割り当てられるインターフェイス、ノード自体、およびトラフィックが送信されるインターフェイスによって満たされることを確認する必要があります。ノードは、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].
ローカルノードポリシーは、トンネルがいつ使用されるか、いつ作成されるかを決定することに注意してください。ローカルポリシーは、トンネルを動的に確立することを可能にする場合があります。また、管理上管理されている場合もあります。トンネルのトンネルと処理の詳細については、トンネルを使用する場合は[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の場合、最後から2番目のホップポップ（PHP）が要求される場合、最後から2番目のホップは、RESVメッセージの処理中に（保存された）G-PIDも調べます。この場合、G-PIDがサポートされていない場合、最後から2番目のホップは、「ルーティングの問題/容認できないラベル値」の表示を持つ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.
エラーメッセージが生成されない場合、通常の処理が発生します。トランジットの場合、これは通常、パスメッセージが伝播されます。出口の場合と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]を参照してください。これらの値は、int-servオブジェクトのピークデータレートフィールドに設定されています。[RFC2210]を参照してください。オブジェクト内の他の帯域幅/サービス関連のパラメーターは無視され、透過的に運ばれます。
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),
WaveBand Switchingは、一般化されたラベルと同じ形式を使用します。セクション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.
さらに、波形が別の波帯に切り替えられると、波帯内の波長が中心周波数についてミラーリングされる可能性があります。このタイプのスイッチングが使用される場合、WaveBandラベルオブジェクトの開始ラベルとエンドラベルをめくり、ラベルオブジェクトをNew WaveBand 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.
Prossived_labelオブジェクトの形式は、一般化されたラベルと同一です。パスメッセージで使用されます。Prossived_labelオブジェクトは、クラス番号129（フォーム10bbbbbbbの）を使用し、ラベルのc型を提案します。
Errors in received Suggested_Label objects MUST be ignored. This includes any received inconsistent or unacceptable values.
受信したsmosided_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は、下流ノードで指定されたラベルを使用するか、「ルーティングの問題/」でレスバーメッセージを生成するようにそれ自体を再構成する必要があります。受け入れられないラベル値 "指標。さらに、イングレスノードは、下流のノードが対応するラベルの上流に渡されるまで、提案されたラベルを使用してデータトラフィックを送信してはなりません。
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オブジェクトは、Class-Number 36（フォーム0BBBBBBBB）とCタイプ1を使用します。パスメッセージで使用されます。
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.
ラベルセットは、1つ以上の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.
パスメッセージを受信すると、受信ノードはラベルの選択をラベルセットにあるラベルに制限します。ラベル変換を実行できるノードは、パスメッセージを転送する前にラベルセットを削除する場合があります。ノードがラベルセットからラベルを選択できない場合、または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.
パスメッセージを受信すると、メッセージに表示されるラベルセットは、ダウンストリームインターフェイスで利用可能なラベルのセットと比較され、結果の交差するラベルセットはパスメッセージに転送されます。結果のラベルセットが空の場合、パスを終了し、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セットアップは、パスメッセージに上流ラベルが存在することによって示されます。upstream_labelオブジェクトは、一般化されたラベルと同じ形式を持っています。セクション2.3を参照してください。upstream_labelオブジェクトは、クラス番号35（フォーム0bbbbbbbbの）と使用されているラベルのC型を使用します。
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オブジェクトがパスメッセージに追加されます。upstream_labelオブジェクトは、パスメッセージが送信された時点で転送に有効なラベルを示す必要があります。
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オブジェクトを含むパスメッセージが受信されると、レシーバーは最初に上流ラベルが許容できることを確認します。ラベルが受け入れられない場合、受信者は「ルーティングの問題/容認できないラベル値」の表示を備えた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.
また、中間ノードは、発信アップストリームラベルに記入してパスメッセージを伝播する前に、発信インターフェイスにラベルを割り当て、内部データパスを確立する必要があります。中間ノードがラベルまたは内部リソースを割り当てることができない場合、「ルーティングの問題/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に関連する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つの追加の競合解決に関連する考慮事項があります。1つ目は、RSVP競合解像度の目的のために、ノードIDがRSVP_HOPオブジェクトで使用されるIPアドレスであることです。2つ目は、初期パスメッセージを送信するときに隣のノード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]ごとに、ラベルエラーに関する通知をサポートする許容可能なラベルセットオブジェクトを定義します。2番目と3番目の拡張機能により、失敗したLSPの復元を担当するノードへの障害やその他のイベントの迅速な通知が可能になります。（2番目の拡張子であるNotify requestオブジェクトは、イベント通知を送信する場所を識別します。3番目の拡張子であるNotifyメッセージは、一般的なイベント通知を提供します。）最終的な通知関連拡張機能により、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.
許容可能な_label_setオブジェクトは、クラス番号130（フォーム10bbbbbbb）を使用します。Cタイプを含むオブジェクトの残りのコンテンツは、label_setオブジェクトと同じ形式を持っています。セクション2.6を参照してください。
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.
許容可能な_label_setオブジェクトは、patherrおよびresverrメッセージで運ばれる場合があります。許容可能なラベルセットを定義する手順は、ラベルセットを定義するための手順に従ってください。セクション2.6.1を参照してください。具体的には、許容可能なラベルセットは、1つ以上の許容可能な_label_setオブジェクトを介して定義されます。特定のラベル/サブチャネルは、それぞれアクションゼロ（0）および1つのオブジェクトを介して許容可能なラベルセットに追加または除外できます。ラベル/サブチャネルの範囲は、それぞれアクション2（2）および3つのオブジェクトを使用して、許容可能なラベルセットに追加または除外できます。ecceptable_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.
eccuptable_label_setオブジェクトを含めることはオプションです。含まれている場合、PatherrまたはResverrメッセージには、「ルーティングの問題/容認できないラベル値」の表示を含める必要があります。許容可能な_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.
通知は、以下に定義されているNotifyメッセージを介して送信される場合があります。Notifyリクエストオブジェクトは、通知の生成を要求するために使用されます。通知、つまり、通知メッセージの送信は、上流方向と下流方向の両方で要求される場合があります。
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:
Notifyリクエストオブジェクトは、パスまたはRESVメッセージに携帯する場合があります。セクション7を参照してください。Notify_Requestクラス番号は195（フォーム11BBBBBBの）です。Notifyリクエストの形式は次のとおりです。
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
IPv6はノードアドレスを通知します：16バイト
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.
通知要求オブジェクトをPATHまたはRESVメッセージに挿入して、LSP障害を通知するノードのアドレスを示すことができます。前述のように、上流と下流の方向の両方で通知が要求される場合があります。上流の通知は、対応するパスメッセージに通知要求オブジェクトを含めることにより示されます。下流の通知は、対応する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.
通知要求オブジェクトを含むメッセージを受信するノードは、対応する状態ブロックにNotifyノードアドレスを保存する必要があります。ノードがトランジットノードである場合、発信パスまたはRESVメッセージにNotify Requestオブジェクトも含める必要があります。発信Notifyノードアドレスは、ローカルポリシーに基づいて更新される場合があります。
Note that the inclusion of a Notify Request object does not guarantee that a Notify message will be generated.
通知リクエストオブジェクトを含めることは、通知メッセージが生成されることを保証しないことに注意してください。
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.
Notifyメッセージは、LSP関連イベントの非隣接ノードを通知するメカニズムを提供します。通知メッセージは通常、通知要求オブジェクトが受信された後にのみ生成されます。Notifyメッセージは、現在定義されているエラーメッセージ（つまり、PatherrおよびResverrメッセージ）とは異なります。これは、即時の上流または下流の隣人以外のノードに「ターゲット」される可能性があり、一般化された通知メカニズムであるということです。Notifyメッセージは、既存のエラーメッセージを置き換えません。通知メッセージは（a）通常、[rfc2205]のresvconf処理と同様に、ターゲットノードをターゲットノードに転送するだけです。または（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.
Notifyメッセージの信頼できる配信をサポートするために、ACKメッセージ[RFC2961]を使用して、通知メッセージの受信を確認します。信頼できる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.
Notifyメッセージは一般化された通知メッセージです。IP宛先アドレスは、意図した受信機のIPアドレスに設定されています。Notifyメッセージは、ルーターアラートオプションなしで送信されます。単一のNotifyメッセージには、上流と下流の両方でリストされている各セッションに関して、通知が送信される場合があります。
The Notify message has a Message Type of 21. The Notify message format is as follows:
Notifyメッセージには、21のメッセージタイプがあります。Notifyメッセージ形式は次のとおりです。
<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メッセージを生成し、対応するパスメッセージで通知リクエストオブジェクトを受信した場合、記録されたノードに導かれる通知メッセージを生成する必要があります。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].
通知メッセージを生成する場合、ノードは同じノードに送信される通知を結合しようとする必要があります。ノードがどの情報を組み合わせるかを決定する手段は、実装依存です。実装は、イベント、タイマーベース、またはその他のアプローチを使用する場合があります。タイマーベースのアプローチを使用する場合、実装により、ユーザーは通知が組み合わされる間隔を構成できるようにする必要があります。タイマーベースのアプローチを使用する場合、1 msのデフォルトの「通知間隔」を使用する必要があります。[RFC2961]で定義されている信頼できるメッセージ伝達メカニズムを使用して、メッセージを配信する必要があります。
Upon receiving a Notify message, the Notify Node SHOULD send a corresponding Ack message.
Notifyメッセージを受信すると、Notifyノードは対応する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メッセージは、関連するパスメッセージのソースにホップバイホップを送信されます。中間ノードはこのメッセージを検査する場合がありますが、それにはアクションを実行しません。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バイトフラグフィールドが含まれています。そのフィールド内で、2つのフラグが定義されています。この仕様は、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フラグは常にゼロに設定されます。エラーに遭遇するノードは、エラーが関連するパス状態が破棄されると、このフラグを設定する場合があります。ノードの設定がフラグがセッションエンドポイントではない場合、ノードは対応するパステアを生成する必要があります。PATH_STATE_REMOVEDフラグセットを使用してERROR_SPECオブジェクトを含むPatherRメッセージを受信するノードも、関連するパス状態を削除する場合があります。PATH状態が削除されている場合、PATH_STATE_REMOVEDフラグを発信PATHERRメッセージに設定する必要があります。関連するパス状態を削除しないノードは、path_state_removedフラグを設定してはなりません。PATH_STATE_REMOVEDフラグをゼロに設定してエラーを受信するノードは、対応するPATHTEARメッセージも生成しない限り、このフラグを設定してはなりません。
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（レコードルートオブジェクト）サブオブジェクトは、明示的なラベルコントロールをサポートするために定義されます。ラベルRROサブオブジェクトは[RFC3209]で定義されており、双方向LSPをサポートするために拡張されていることに注意してください。
The Label ERO subobject is defined as follows:
ラベルERO Subobjectは次のように定義されています。
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つはダウンストリームラベル用、もう1つはアップストリームラベル用です。以下は、「bad reblicit_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 最初のラベルサブオブジェクトの前に、出力リンクに関連付けられたIPアドレスまたはインターフェイス識別子[RFC3477]を含むサブオブジェクトが前に行われない場合。
o For a label subobject to follow a subobject that has the L-bit set
o ラベルSubobjectがLビットセットを持つサブオブジェクトに従うこと
o On unidirectional LSP setup, for there to be a label subobject with the U-bit set
o 一方向のLSPセットアップでは、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.
ラベルSubobjectをサポートするには、ノードを確認して、アソシエイトアドレス/インターフェイスに続くSubObjectがラベルSubobjectであるかどうかを確認する必要があります。もしそうなら、1つのサブオブジェクトは、単方向LSPと双方向LSPの2つのサブオブジェクトについて調べられます。調査対象のサブオブジェクトのUビットがクリア（0）である場合、ラベルの値は新しいlabel_setオブジェクトにコピーされます。このlabel_setオブジェクトは、対応する発信パスメッセージに含める必要があります。
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に関連する上流トラフィックに使用されるラベルです。このラベルが受け入れられない場合、「bad rebricit_routeオブジェクト」エラーを生成する必要があります。ラベルが許容できる場合、ラベルは新しいupstream_labelオブジェクトにコピーされます。このupstream_labelオブジェクトは、対応する発信パスメッセージに含める必要があります。
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.
上記の手順の意味は、ラベルSubobjectが新しく受信したメッセージの最初のサブオブジェクトではないことです。ラベルSubobjectが最初のSubobject an A A-受信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 Subobjectは次のように定義されています。
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.
[RFC3209]に記載されているように、ラベルRROサブオブジェクトは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（フォーム0bbbbbbbb）を使用します。
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.
トランジットノード保護オブジェクトを含むパスメッセージの処理は、発信インターフェイスまたはトンネル（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.
Adminterativeステータス情報は、Admin_Statusオブジェクトに掲載されています。オブジェクトは、特定のLSPの管理状態に関連する情報を提供します。情報は2つの方法で使用されます。最初に、オブジェクトはPATHおよびRESVメッセージに配置され、LSPの管理状態を示します。2番目では、オブジェクトは通知メッセージに配置され、イングレスノードがLSPの管理状態を変更するように要求します。
The use of the Admin_Status Object is optional. It uses Class-Number 196 (of form 11bbbbbb).
Admin_Statusオブジェクトの使用はオプションです。クラス番号196（フォーム11bbbbbbbの）を使用します。
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メッセージの場合）ノードの裁量で、パスまたは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オブジェクトの値がパスメッセージで受信された値とは異なる場合、1つの例外を除き、ローカルアクションは取得する必要はありませんが、値はまだ伝播する必要があります。RESVメッセージで受信された値がローカルアクションをもたらす1つのケースは、受信したRビットとDビットの両方が設定されている場合、つまり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ビットを使用してパスメッセージを受信し、ノードが以前にパスメッセージに対応するRESVメッセージを発行した場合、ノードは同じ値のadmin_statusオブジェクトを含むadmin_statusオブジェクトを含む更新されたRESVメッセージを送信する必要があります対応するパスメッセージで受信したように、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.
さらに、IngressノードがAdmin_StatusオブジェクトセットのRビットを使用してRESVメッセージを受信した場合、ノードは、R BITを除き、同じ値を除いて、同じ値を除いてAdmin_Statusオブジェクトを含む更新されたパスメッセージを送信する必要があります。対応する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. Ingressノードは、パスメッセージに管理者ステータスオブジェクトを挿入し、反射（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. トランジットおよび出口ノード上記のように、管理者ステータスオブジェクトを処理します。（または、出口は、path_state_removedフラグセットでpatherrメッセージで応答する場合があります。セクション4.4を参照してください。）
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.
3. RESVメッセージにdelete（d）ビットが設定された管理ステータスオブジェクトを受信すると、IngressノードはLSPを削除するためにPathtearメッセージを下流に送信し、通常のRSVP処理が行われます。
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）ビットを設定することにより、削除の要望を示します。
2. Transit nodes process the Admin Status Object as described above.
2. トランジットノード上記のように管理ステータスオブジェクトを処理します。
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.
3. RESVメッセージにdelete（d）ビットが設定された管理ステータスオブジェクトを受信すると、IngressノードはLSPを削除するためにPathtearメッセージを下流に送信し、通常のRSVP処理が行われます。
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メッセージで更新された管理者ステータスオブジェクトに対して構成可能な期間のみを待つ必要があります。期間が経過すると、Ingressノードは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.
中間ノードと出口ノードは、通知メッセージを使用して管理ステータスの設定をトリガーする場合があります。これを達成するために、中間または出口ノードは、対応する上流の通知セッション情報を使用して通知メッセージを生成します。Admin Statusオブジェクトは、適切なビットまたはビットが設定されたセッション情報に含める必要があります。反射（r）ビットを設定してはなりません。Notifyメッセージは、カプセル化されている必要はありませんが、セクション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.
delete（d）ビット設定を備えた管理者ステータスオブジェクトを含む通知メッセージを受信するイングレスノードは、前のセクションで説明した削除手順を開始する必要があります。他のビットは、通常どおり発信パスメッセージに伝播する必要があります。
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）ビット設定を持つ管理者ステータスオブジェクトを含む通知メッセージを送信するノードは、構成可能な期間内に[d）ビット設定で対応するパスメッセージを受信することを確認する必要があります。デフォルトでは、この期間は30秒でなければなりません。ノードがそのようなパスメッセージを受信しない場合、Path_State_Removedフラグを上流に設定したPATHTEARメッセージまたはPATHERRメッセージを下流のPATHTEARメッセージまたは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).
使用するデータインターフェイスの選択は、常にパスメッセージの送信者によって行われます。データインターフェイスの選択は、新しいRSVP_HOPオブジェクトサブタイプを使用してメッセージにデータチャネルのインターフェイス識別子をメッセージに含めることにより、パスメッセージの送信者によって示されます。双方向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オブジェクトの代わりに使用されます。コントロールチャネルとデータチャネルとの1対1の関連性がないリンクで使用されています。[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が、上流のデータチャネルとは異なる下流のデータチャネルを指定する特別なケースでは。データチャネルは、パスメッセージの送信者の視点から指定されています。IF_ID RSVP_HOPオブジェクトは、TLVが不要な場合は使用しないでください。
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.
パスメッセージ内の1つ以上のTLVを受信するノードは、値を保存し、TLVを発信するノードに送信された後続のRESVメッセージのホップオブジェクトでそれらを返します。
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に掲載された情報と一致しているかどうかを確認する必要があります。送信者に向かって明示的なルートオブジェクト。このチェックは、最初の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オブジェクトは、他のERROR_SPECオブジェクトとして生成および処理する必要があります。[RFC2205]を参照してください。
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種類の制御通信障害の処理について説明します。NODAL障害と呼ばれる最初のものは、ノードがコントロール状態を損なう場合（例えば、再起動後）、データ転送状態を緩和しない場合に関連しています。コントロールチャネル障害と呼ばれる2番目の場合、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-TEコンポーネントを再起動する時間の合計（RSVP Hello helloとneighborsと交換できるポイント）と、RSVP通信に使用される通信チャネルの合計に設定する必要があります。0xffffffffffの値は、送信者のコントロールプレーンの再起動が不確定な間隔で発生する可能性があり、データプレーンの動作がコントロールプレーンの故障の影響を受けないことを示しています。継続的なデータプレーンの操作を確保するために使用される方法は、このドキュメントの範囲外です。
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.
Hello Synchronizationの再確立後、送信者が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.
State Recoveryをサポートするノードは、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オブジェクトを使用してハローメッセージを受信すると、受信したパラメーターの値を記録する必要があります。
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.
Nodeが隣人とのRSVP通信が失われたと判断し、Nodeが隣人が状態回復をサポートすることを以前に学んだ場合、ノードは少なくとも、に関連する手順を呼び出す前に隣人が示す再起動時間で示される時間を待つ必要がありますコミュニケーションの損失。ノードは、ローカルポリシーまたは構成情報に基づいて、異なる時間を待つ場合があります。
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メッセージはdst_instance値をゼロ（0）に設定して送信する必要があり、src_instanceは変更されません。待っている間、ノードは、ノードと近隣のリンクを横断する（すでに）確立されたLSPのRSVPおよびMPLS転送状態も保持する必要があります。確立されたLSPに関しては、ノードは隣人から定期的なRSVP更新メッセージを受け取るように動作します。ノードは、リフレッシュタイマーが期限切れになったときに確立されるプロセスにあるLSPのRSVPと転送状態をクリアする場合があります。この待機期間中、RESVとパス状態をリフレッシュする必要があります。
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 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および/または上流の通知メッセージを介した通信損失の上流ノードに「コントロールチャネル劣化状態」の表示を通知することができます。そのような通知が送信された場合、制御チャネルの復元時にノードは、「制御チャネルアクティブ状態」指示を使用して、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.
制御チャネル障害の場合、ノードは隣人と共有されるすべての状態を更新する必要があります。概要[RFC2961]は、サポートされている場合は、ACK_DESIREDフラグセットをリフレッシュします。多数のメッセージが必要な場合は、一部のペースを適用する必要があることに注意してください。すべての州は、隣人が宣伝する回復時間内に更新する必要があります。
Recovering from nodal faults uses one new object and other existing protocol messages and objects.
NODAL障害から回復すると、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オブジェクトは、クラス番号34（フォーム0bbbbbbbbの）を使用し、ラベルのC型を提案します。
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転送状態を保持できるかどうかを確認する必要があります。再起動前の転送状態が保持されていない場合、ノードはノードが近隣に送信するハローメッセージで回復時間を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 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.
転送状態が保存されている場合、ノードは状態回復プロセスを開始します。ノードが回復プロセスをサポートする準備ができている期間は、回復期間と呼ばれます。回復期間の合計期間は、RestART_CAPオブジェクトの回復時間パラメーターの回復ノードによって宣伝されます。回復時間は、回復期間中に送信されたすべてのハローメッセージの回復期間の期間に設定する必要があります。回復期間中に再同期されない状態は、期間の終わりに削除する必要があります。
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.
Hello同期中に再起動ノードが隣人が状態の回復をサポートしていないと判断し、再起動ノードがMPLS転送状態を1人あたりに維持していると判断した場合、再起動ノードは、その隣人が完了した回復期間を直ちに検討する必要があることに注意してください。転送状態は、インターフェイスごとのラベルがポイントツーポイントインターフェイスで使用される場合、近隣ベースで維持されると見なされる場合があります。
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オブジェクトが搭載されている場合、ノードは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に拘束され、関連する転送状態は有効で更新されていると見なされる必要があります。通常のパスメッセージ処理も実行する必要があります。対応する発信パスメッセージを送信する場合、ノードには、現在復元された転送エントリの発信ラベルと一致するラベル値を持つ提案された_labelオブジェクトを含める必要があります。発信インターフェイスも、転送エントリに基づいて選択する必要があります。再起動ノードにも下流の隣接が再定義されている特別な場合、smosided_labelオブジェクトの代わりにrecovery_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の場合、ノードは受信したパスメッセージに掲載された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転送テーブルエントリが見つかった場合、エントリはパスメッセージに関連付けられたLSPに拘束され、エントリは再同期されると見なされる必要があります。さらに、ノードがLSPのテールエンドではない場合、対応する発信パスメッセージは、そのエントリから上流のラベルから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メッセージの処理中に新しいラベルまたはリソースの割り当ては必要ありません。2番目の例外は、一致するパス状態のない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オブジェクトに掲載された非ゼロ回復時間によって示されました）。注、0xfffffffffの再起動時間値は、無限の再起動時間間隔を示します。
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.
州の回復をサポートする隣人との再起動を検出すると、ノードはその隣人と共有されるすべてのパス状態を更新する必要があります。発信パスメッセージには、最近受信した対応するRESVメッセージで受信されたラベル値に対応するラベル値を含むRecovery_Labelオブジェクトを含める必要があります。すべてのパス状態は、再起動した隣人によって宣伝された回復時間の約1/2以内で更新する必要があります。再起動ノードを使用して多くの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.
状態回復をサポートする隣人の再起動を検出した後、再起動ノードと共有されるすべてのRESV状態を、対応するパスメッセージが受信されるまで更新する必要はありません。これには、再起動した隣人が宣伝する回復時間中に、隣人への通常のRESVとサマリーリフレッシュ処理の抑制が必要です。対応するパスメッセージが受信されるとすぐに、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 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ホップを処理するように設計されています。この目的のために、PATH、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.
Igor Bryskin、Adrian Farrel、Dimitrios Pendarakisなど、多くの人々から貴重なコメントと意見が受けられました。セクション4の一部は、エイドリアンファレルが提案した提案とテキストに基づいています。
The security considerations section is based on text provided by Steven Bellovin.
セキュリティ上の考慮事項セクションは、Steven 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.
このドキュメントでは、ノンホップバイホップファッションでNotifyメッセージを送信する機能を紹介します。これにより、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メッセージによって識別されます。ノードは、Notifyメッセージで使用される内部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型値の割り当てに関するルールを定義します。このセクションでは、RFCSでIANAの考慮事項セクションを作成するためのBCP 26 "ガイドラインの用語を使用しています[BCP26]。
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型値の割り当ては、3つのカテゴリに分類されます。最初のカテゴリは、ラベルオブジェクト、つまりオブジェクトクラス番号16 [RFC3209]からCタイプを継承します。IANAは、ラベルオブジェクトに割り当てられるすべてのCタイプの値が次のオブジェクトに割り当てられるポリシーを制定するように要求されます。
o Suggested_Label (Class-Num 129) o Upstream_Label (Class-Num 35) o Recovery_Label (Class-Num 34)
o smistried_label（class-num 129）o upstream_label（class-num 35）o recovery_label（class-num 34）
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.
オブジェクトの2番目のカテゴリは、独立したポリシーに従います。具体的には、[bcp26]で概説されているポリシーに従って、0x00-0x3fの範囲のc型値はIETFコンセンサスアクション、00x40-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（class-num 36）o notify_request（class-num 195）o保護（クラス-num 37）o管理ステータス（クラス番号196）o restart_cap（class-num 131）
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型値の割り当てであるecceptable_label_setオブジェクトは、label_setオブジェクトのc型値の割り当てに従います。IANAは、label_setオブジェクトに割り当てられたすべてのc型値も、ecceptable_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 メッセージを通知する（メッセージタイプ= 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-num 3）-ipv4 if_id rsvp_hop（c-type = 3）-ipv6 if_id rsvp_hop（c-type = 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-num 6）-ipv4 if_id error_spec（c-type = 3）-ipv6 if_id error_spec（c-type = 4）
o LABEL_REQUEST (Class-Num 19) - Generalized_Label_Request (C-Type = 4)
o label_request（class-num 19） - generalized_label_request（c-type = 4）
o RSVP_LABEL (Class-Num = 16) - Generalized_Label (C-Type = 2) - Waveband_Switching_Label C-Type (C-Type = 3)
o rsvp_label（class-num = 16） - generalized_label（c-type = 2）-waveband_switching_label c-type（c-type = 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 recovery_label class-num of form 0bbbbbbbb（= 34）oフォーム10bbbbbb（= 129）o upstream_label class-num of form 0bbbbbbb（= 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)
o フォーム0bbbbbbbb（= 36） - タイプ1（c-type = 1）oフォーム10bbbbbbb（= 130） - タイプ1容認できる_label_set（c-type from label_set cnum）o compationable_label_setクラスナムo compateable_label_setクラスのnumssフォーム11bbbbbbb（= 195） - IPv4通知要求（c-type = 1） - ipv6通知要求（c-type = 2）oフォーム0bbbbbbbb（= 37） - タイプ1（c-type = 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 admin status class-num of form 11bbbbbbb（= 196） - タイプ1（c-type = 1）o restart_cap class-num of form 10bbbbbb（= 131） - type 1（c-type = 1）----------------------------------------------------------------------------------- ERO/RROサブオブジェクトタイプ
o Label ERO subobject Type 3 - Label
o ラベルEROサブオブジェクトタイプ3-ラベル
o Label RRO subobject Type 3 - Label --------------------------------------------------------------------- Error codes
o ラベルRROサブオブジェクトタイプ3-ラベル-------------------------------------------------------------------------------------------------------------------------------------エラーコード
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Braden、R。（ed。）、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2401, November 1998.
[RFC2402] Kent、S。およびR. Atkinson、「IP認証ヘッダー」、RFC 2401、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2401, November 1998.
[RFC2406] Kent、S。およびR. Atkinson、「IP Cankupsing Security Payload（ESP）」、RFC 2401、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] Baker、F.、Lindell、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] Berger、L.、Gan、D.、Pwallow、G.、Pan、P.、Tommasi、F。and 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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、2001年12月。
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、編集者、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[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-Hierarchy] Kompella、K。およびY. Rekhter、「MPLS TEとのLSP階層」、進行中の作業。
[PAN-RESTART] Pan, P., et. al., "Graceful Restart Mechanism for RSVP-TE", Work in Progress.
[Pan-Restart] Pan、P.、et。al。、「RSVP-TEの優雅な再起動メカニズム」、進行中の作業。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
Peter Ashwood-Smith Nortel Networks Corp. P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7 Canada
Peter Ashwood-Smith Nortel Networks Corp. P.O.ボックス3511ステーションC、オタワ、K1Y 4H7カナダ
Phone: +1 613 763 4534
EMail: petera@nortelnetworks.com
Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose, CA 95138
Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose、CA 95138
Phone: +1 408 972-3645
EMail: abanerjee@calient.net
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
Lou Berger Movaz Networks、Inc。7926 Jones Branch Drive Suite 615 McLean VA、22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Greg Bernstein
EMail: gregb@grotto-networking.com
John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138
John Drake Calient Networks 5853 Rue Ferrari San Jose、CA 95138
Phone: +1 408 972 3720
EMail: jdrake@calient.net
Yanhe Fan Axiowave Networks, Inc. 200 Nickerson Road Marlborough, MA 01752
YanheファンAxiowave Networks、Inc。200 Nickerson Road Marlborough、MA 01752
Phone: + 1 774 348 4627
EMail: yfan@axiowave.com
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Kireeti Kompella Juniper Networks、Inc。1194 N. Mathilda Ave. Sunnyvale、CA 94089
EMail: kireeti@juniper.net
Jonathan P. Lang EMail: jplang@ieee.org
Jonathan P. Langメール：jplang@ieee.org
Fong Liaw Solas Research, LLC
Fong Liaw Solas Research、LLC
EMail: fongliaw@yahoo.com
Eric Mannie
Independent Consultant
2 Avenue de la Folle Chanson
1050 Brussels
Belgium
EMail: eric_mannie@hotmail.com
Ping Pan Ciena 10480 Ridgeview Court Cupertino, CA 95014
Ping Pan Ciena 10480 Ridgeview Court Cupertino、CA 95014
Phone: 408-366-4700 EMail: ppan@ciena.com
電話：408-366-4700メール：ppan@ciena.com
Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901
Bala Rajagopalan Tellium、Inc。2 Crescent Place P.O.Box 901 Oceanport、NJ 07757-0901
Phone: +1 732 923 4237
Fax: +1 732 923 9804
EMail: braja@tellium.com
Yakov Rekhter Juniper Networks, Inc.
Yakov Rekhter Juniper Networks、Inc。
EMail: yakov@juniper.net
Debanjan Saha EMail: debanjan@acm.org Vishal Sharma Metanoia, Inc. 1600 Villa Street, Unit 352 Mountain View, CA 94041-1174
Debanjan Saha Email：debanjan@acm.org vishal Sharma Metanoia、Inc。1600 Villa Street、Unit 352 Mountain View、CA 94041-1174
Phone: +1 650-386-6723
EMail: v.sharma@ieee.org
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824
George Swallow Cisco Systems、Inc。250 Apollo Drive Chelmsford、MA 01824
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Z. Bo Tang EMail: botang01@yahoo.com
Z. Bo Tang Email：botang01@yahoo.com
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
Lou Berger Movaz Networks、Inc。7926 Jones Branch Drive Suite 615 McLean VA、22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。