RFC3473 日本語訳
3473 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)Extensions. L. Berger, Ed.. January 2003. (Format: TXT=91808 bytes) (Updated by RFC4003, RFC4201, RFC4420, RFC4783, RFC4874, RFC4873, RFC4974, RFC5063, RFC5151) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Berger, Editor Request for Comments: 3473 Movaz Networks Category: Standards Track January 2003
ワーキンググループのL.バーガー、コメントを求めるエディタ要求をネットワークでつないでください: 3473Movazはカテゴリをネットワークでつなぎます: 標準化過程2003年1月
Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions
一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング資源予約プロトコル交通工学(RSVP-Te)拡大
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
このドキュメントはMulti-プロトコルLabel Switching(MPLS)リソースReserVationプロトコルに拡大について説明します--トラフィックEngineering(RSVP-TE)シグナリングがGeneralized MPLSをサポートするのが必要です。 一般化されたMPLSは、時間分割(例えば、同期式光通信網と同期デジタルハイアラーキ、Sonet/SDH)、波長(光学λ)、および空間的な切り換え(例えば、出発しているポートかファイバーへの入って来るポートかファイバー)を取り囲むためにMPLS制御飛行機を広げています。 このドキュメントは拡大のRSVP-TEの明確な記述を提示します。 別々のドキュメントでジェネリックの機能的な記述を見つけることができます。
Table of Contents
目次
1. Introduction .............................................. 2
2. Label Related Formats .................................... 3
2.1 Generalized Label Request Object ........................ 3
2.2 Bandwidth Encoding ...................................... 4
2.3 Generalized Label Object ................................ 5
2.4 Waveband Switching ...................................... 5
2.5 Suggested Label ......................................... 6
2.6 Label Set ............................................... 7
3. Bidirectional LSPs ........................................ 8
3.1 Procedures .............................................. 9
3.2 Contention Resolution ................................... 9
4. Notification .............................................. 9
4.1 Acceptable Label Set Object ............................. 10
4.2 Notify Request Objects .................................. 10
1. 序論… 2 2. 関連形式をラベルしてください… 3 2.1はラベル要求オブジェクトを一般化しました… 3 2.2 帯域幅コード化… 4 2.3はラベルオブジェクトを一般化しました… 5 2.4 周波数帯の切り換え… 5 2.5はラベルを示しました… 6 2.6ラベルはセットしました… 7 3. 双方向のLSPs… 8 3.1の手順… 9 3.2主張解決… 9 4. 通知… 9 4.1の許容できるラベルはオブジェクトを設定しました… 10 4.2 要求オブジェクトに通知してください… 10
Berger Standards Track [Page 1] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[1ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
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
4.3 メッセージに通知してください… 12 4.4 PathErrメッセージをもっている州を取り除きます… 14 5. 明白なラベルコントロール… 15 5.1 ERO subobjectをラベルしてください… 15 5.2 RRO subobjectをラベルしてください… 16 6. 保護オブジェクト… 17 6.1の手順… 18 7. 管理状態情報… 18 7.1アドミン状態オブジェクト… 18 7.2経路とResvメッセージ手順… 18 7.3 メッセージ手順に通知してください… 20 8. チャネルセパレーションを制御してください… 21 8.1 識別を連結してください… 21 8.2はインタフェース識別をErroredしました… 23 9. 欠点取り扱い… 25 9.1 _上限オブジェクトを再開してください… 25 9.2 再開_上限オブジェクトの処理… 26 9.3 変更、こんにちは、状態が回復であるとサポートするために処理します… 26 9.4 チャンネル欠点を制御してください… 27 9.5 こぶのような欠点… 27 10. RSVPメッセージ・フォーマットと取り扱い… 30 10.1 RSVPメッセージ・フォーマット… 30 10.2 経路とPathTearがメッセージであると扱います… 32 11. 承認… 32 12. セキュリティ問題… 33 13. IANA問題… 34 13.1 IANA課題… 35 14. 知的所有権問題… 36 15. 参照… 37 15.1 標準の参照… 37 15.2 有益な参照… 38 16. 貢献者… 38 17. エディタのアドレス… 41 18. 完全な著作権宣言文… 42
1. Introduction
1. 序論
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)がインタフェースであるとサポートして、3つの新しいクラスのインタフェースのサポートを含むように切り替わって、切り替わるのからMPLSを広げています: 時間事業部は(TDM)、λスイッチ(LSC)、およびファイバースイッチ(FSC)を多重送信します。 MPLSシグナリングへの拡大の機能的な記述は、新しいクラスのインタフェースをサポートする必要がありました、そして、[RFC3471]に切り換えを提供します。 このドキュメントはすべての4つのクラスのインタフェースをサポートするのが必要である特定の形式とメカニズムをRSVP-TEに提示します。
Berger Standards Track [Page 2] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[2ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
[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]に沿います。 また、Generalized 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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Label Related Formats
2. 関連形式をラベルしてください。
This section defines formats for a generalized label request, a generalized label, support for waveband switching, suggested label and label sets.
このセクションは一般化されたラベル要求のために書式を定義して、一般化されたラベル(周波数帯の切り換えのサポート)はラベルとラベル・セットを示しました。
2.1. Generalized Label Request Object
2.1. 一般化されたラベル要求オブジェクト
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.
SHOULDがTypeをコード化するトランジットLSRsで切り替わる際に最大の柔軟性を許容するのにおいてできるだけ特定のLSP(ラベルSwitched Path)を含んでいるというPathメッセージ。 Generalized Label Requestオブジェクトは、イングレスノードによって設定されて、トランジットノードによって透過的に渡されて、出口ノードによって使用されます。 また、ホップごとにSwitching Type分野をアップデートするかもしれません。
The format of a Generalized Label Request object is:
Generalized Label Requestオブジェクトの形式は以下の通りです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (19)| C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム(19)| C-タイプ(4)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc。 タイプ|切り換えタイプ| G-PID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
パラメタの記述に関して[RFC3471]を見てください。
2.1.1. Procedures
2.1.1. 手順
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.
Generalized Label Requestを含むPathメッセージを処理するノードは、入って来るラベルが割り当てられることになっているインタフェース、ノード自体の近くと、そして、トラフィックが伝えられるインタフェースで要求されたパラメタを満たすことができることを確かめなければなりません。 ノードが直接LSPを支えるかもしれませんか、またはそれはすなわち、トンネル(FA)、もう1人のクラスの切り換えを使用するかもしれません。 どちらの場合ではも、各パラメタをチェックしなければなりません。
Berger Standards Track [Page 3] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[3ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
Note that local node policy dictates when tunnels may be used and when they may be created. Local policy may allow for tunnels to be dynamically established or may be solely administratively controlled. For more information on tunnels and processing of ER hops when using tunnels see [MPLS-HIERARCHY].
ローカルのノード方針が、トンネルがいつ使用されるかもしれないか、そして、それらがいつ作成されるかもしれないかを決めることに注意してください。 ローカルの方針は、トンネルがダイナミックに確立されるのを許容するか、または唯一行政上制御されるかもしれません。 トンネルを使用するとき、ERのトンネルと処理の詳しい情報に関しては、ホップは[MPLS-HIERARCHY]を見ます。
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 Encoding Typeをサポートすることができます。 コード化をサポートすることができないなら、ノードは「ルート設定の問題/サポートされないコード化」指示で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.
ノードは、Switching Typeパラメタで示されたタイプが対応する入って来るインタフェースでサポートされることを確かめなければなりません。 タイプをサポートすることができないなら、ノードは「ルート設定の問題/切り換えタイプ」指示で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をサポートすることができないなら、出口はPathErrメッセージを生成しなければなりません、「ルート設定の問題/サポートされないL3PID」指示で。 また、PSCの際と終わりから二番目のホップの飛び出し(PHP)がいつ要求されるかとき、終わりから二番目のホップはResvメッセージの処理の間、(保存される)のG-PIDを調べます。 この場合、G-PIDがサポートされないなら、終わりから二番目のホップは「ルート設定問題/容認できないラベル値」指示でResvErrメッセージを生成しなければなりません。 セクション4.1は、発生しているResvErrメッセージがAcceptable Label Setを含むかもしれないのを見ます。
When an error message is not generated, normal processing occurs. In the transit case this will typically result in a Path message being propagated. In the egress case and PHP special case this will typically result in a Resv message being generated.
エラーメッセージが発生していないとき、正常処理は起こります。 トランジット場合では、これは伝播されるPathメッセージを通常もたらすでしょう。 出口場合とPHPの特別な場合では、これは生成されるResvメッセージを通常もたらすでしょう。
2.2. Bandwidth Encoding
2.2. 帯域幅コード化
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.
帯域幅encodingsはSENDER_TSPECとFLOWSPECオブジェクトで運ばれます。 [RFC3471]を見て、値の定義は特定の信号タイプに使用されてください。 [RFC2210]は、これらの値がInt-ServオブジェクトのPeak Data Rate分野に設定されるのを見ます。 オブジェクトのサービス他の帯域幅/関連するパラメタは、透過的に無視されて、運ばれます。
Berger Standards Track [Page 4] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[4ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
2.3. Generalized Label Object
2.3. 一般化されたラベルオブジェクト
The format of a Generalized Label object is:
Generalized Labelオブジェクトの形式は以下の通りです。
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム(16)| C-タイプ(2)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ラベル| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters and encoding of labels.
パラメタの記述とラベルのコード化に関して[RFC3471]を見てください。
2.3.1. Procedures
2.3.1. 手順
The Generalized Label travels in the upstream direction in Resv messages.
Generalized Labelは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.
Generalized Labelを含むResvメッセージの受取人は、通過された値が許容できることを確かめます。 ラベルが容認できないなら、受取人は「ルート設定問題/MPLSラベル割り振りの失敗」指示でResvErrメッセージを生成しなければなりません。
2.4. Waveband Switching Object
2.4. 周波数帯切り換えオブジェクト
Waveband switching uses the same format as the generalized label, see section 2.2. Waveband Label uses C-Type (3),
セクション2.2は、周波数帯の切り換えが一般化されたラベルと同じ形式を使用するのを見ます。 周波数帯LabelはC-タイプ(3)を使用します。
In the context of waveband switching, the generalized label has the following format:
周波数帯の切り換えの文脈では、一般化されたラベルは以下の形式を持っています:
Berger Standards Track [Page 5] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[5ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム(16)| C-タイプ(3)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 周波数帯イド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | スタートラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 終わりのラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
パラメタの記述に関して[RFC3471]を見てください。
2.4.1. Procedures
2.4.1. 手順
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.
周波数帯が別の周波数帯に切り換えられるとき、さらに、周波数帯の中の波長が中心周波数に関して反映されるのは、可能です。 このタイプの切り換えが採用しているとき、ラベルオブジェクトを進める前に、新しい周波数帯アイダホ州と共に周波数帯ラベルオブジェクトの始めと終わりのラベルをはじき出さなければなりません。 この様に、これらの値を逆にする周波数帯ラベルを受けて、また、そうしなければならないのを知っている出口/イングレスLSRは適切な波長を拾う出口協会を逆にします。
This operation MUST be performed in both directions when a bidirectional waveband tunnel is being established.
双方向の周波数帯トンネルが確立されているとき、両方の方向にこの操作を実行しなければなりません。
2.5. Suggested Label Object
2.5. 提案されたラベルオブジェクト
The format of a Suggested_Label object is identical to a generalized label. It is used in Path messages. A Suggested_Label object uses Class-Number 129 (of form 10bbbbbb) and the C-Type of the label being suggested.
Suggested_Labelオブジェクトの形式は一般化されたラベルと同じです。 それはPathメッセージで使用されます。 Suggested_Labelオブジェクトは129(フォーム10bbbbbbの)のClass-数と示されるラベルのC-タイプを使用します。
Errors in received Suggested_Label objects MUST be ignored. This includes any received inconsistent or unacceptable values.
容認されたSuggested_Labelオブジェクトの誤りを無視しなければなりません。 これはどんな容認された矛盾したか容認できない値も含んでいます。
Per [RFC3471], if a downstream node passes a label value that differs from the suggested label upstream, the upstream LSR MUST either reconfigure itself so that it uses the label specified by the downstream node or generate a ResvErr message with a "Routing
[RFC3471]に従って、川下のノードが提案されたラベル上流と異なっているラベル値を通過するなら、上流のLSR MUSTは川下のノードによって指定されたラベルを使用するようにそれ自体を再構成するか、または「ルート設定」でResvErrメッセージを生成します。
Berger Standards Track [Page 6] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[6ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
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.
「問題/容認できないラベル値」指示。 その上、イングレスノードSHOULD NOTは、川下のノードが対応するラベル上流を通り過ぎるまで提案されたラベルを使用することでデータ通信量を伝えます。
2.6. Label Set Object
2.6. ラベル・セットオブジェクト
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オブジェクトは36(フォーム0bbbbbbbの)のClass-数と1人のC-タイプを使用します。 それはPathメッセージで使用されます。
The format of a Label_Set is:
Label_Setの形式は以下の通りです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (36)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム(36)| C-タイプ(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 動作| 予約されます。| ラベル形式| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブチャネル1| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブチャネル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]を見てください。
2.6.1. Procedures
2.6.1. 手順
A Label Set is defined via one or more Label_Set objects. Specific labels/subchannels can be added to or excluded from a Label Set via Action zero (0) and one (1) objects respectively. Ranges of labels/subchannels can be added to or excluded from a Label Set via Action two (2) and three (3) objects respectively. When the Label_Set objects only list labels/subchannels to exclude, this implies that all other labels are acceptable.
Label Setは1個以上のLabel_Setオブジェクトを通して定義されます。 特定のラベル/サブチャネルは、(0)と1(1)オブジェクトをそれぞれ加えるか、またはActionゼロを通したLabel Setから除くことができます。 ラベル/サブチャネルの範囲は、(2)と3(3)オブジェクトをそれぞれ加えるか、またはAction twoを通したLabel Setから除くことができます。 Label_Setオブジェクトが除くラベル/サブチャネルを記載するだけであるとき、これは、他のすべてのラベルが許容できるのを含意します。
Berger Standards Track [Page 7] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[7ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
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オブジェクトの不在も、すべてのラベルが許容できるのを含意します。 ノードが川下で使用されるかもしれないラベルを制限したがっているとき、Label Setは含まれています。
On reception of a Path message, the receiving node will restrict its choice of labels to one which is in the Label Set. Nodes capable of performing label conversion may also remove the Label Set prior to forwarding the Path message. If the node is unable to pick a label from the Label Set or if there is a problem parsing the Label_Set objects, then the request is terminated and a PathErr message with a "Routing problem/Label Set" indication MUST be generated. It is a local matter if the Label Set is stored for later selection on the Resv or if the selection is made immediately for propagation in the Resv.
Pathメッセージのレセプションでは、受信ノードはラベルの選択をLabel Setにあるものに制限するでしょう。 また、Pathメッセージを転送する前に、ラベル変換を実行できるノードはLabel Setを取り外すかもしれません。 ノードがLabel Setからラベルを選ぶことができないか、またはLabel_Setオブジェクトを分析することにおける問題があれば、要求は終えられます、そして、「ルート設定問題/ラベル・セット」指示があるPathErrメッセージを生成しなければなりません。 後の選択のためにResvにLabel Setを保存するかどうか、またはすぐResvでの伝播のために選択をするかどうかが、地域にかかわる事柄です。
On reception of a Path message, the Label Set represented in the message is compared against the set of available labels at the downstream interface and the resulting intersecting Label Set is forwarded in a Path message. When the resulting Label Set is empty, the Path must be terminated, and a PathErr message, and a "Routing problem/Label Set" indication MUST be generated. Note that intersection is based on the physical labels (actual wavelength/band values) which may have different logical values on different links, as a result it is the responsibility of the node to map these values so that they have a consistent physical meaning, or to drop the particular values from the set if no suitable logical label value exists.
Pathメッセージのレセプションでは、川下のインタフェースで利用可能なラベルのセットに対してメッセージに表されたLabel Setを比較します、そして、Pathメッセージで結果として起こる交差Label Setを送ります。 結果として起こるLabel Setが空であるときに、Pathは終えられてPathErrメッセージであるに違いありません、そして、「ルート設定問題/ラベル・セット」指示を生成しなければなりません。 交差点が異なったリンクの上に異なった論理的な値を持っているかもしれない物理的なラベル(実際の波長/バンド値)に基づいていることに注意してください、それらには、一貫した物理的な意味がその結果、これらの値を写像するのが、ノードの責任であるので、あるか、またはセットから特定の値を下げるために、値は適当な論理的なラベルでないなら存在しています。
When processing a Resv message at an intermediate node, the label propagated upstream MUST fall within the Label Set.
中間的ノードでResvメッセージを処理するとき、上流へ伝播されたラベルはLabel Setの中に落ちなければなりません。
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メッセージに受け取られるのと同じ物理的なラベル(波長/バンド)使用するほど他の選択を全く持っていないことに注意してください。 この場合、Label Setの使用と伝播はこの配分が失敗するという可能性をかなり小さくするでしょう。
3. Bidirectional LSPs
3. 双方向のLSPs
Bidirectional LSP setup is indicated by the presence of an Upstream Label in the Path message. An Upstream_Label object has the same format as the generalized label, see Section 2.3. The Upstream_Label object uses Class-Number 35 (of form 0bbbbbbb) and the C-Type of the label being used.
双方向のLSPセットアップはPathメッセージでのUpstream Labelの存在によって示されます。 セクション2.3は、Upstream_Labelオブジェクトには一般化されたラベルと同じ形式があるのを見ます。 Upstream_Labelオブジェクトは35(フォーム0bbbbbbbの)のClass-数と使用されるラベルのC-タイプを使用します。
Berger Standards Track [Page 8] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[8ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
3.1. Procedures
3.1. 手順
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の設立に続きます。 双方向のLSPsがUpstream_LabelオブジェクトであるとサポートするのがPathメッセージに追加されます。 Upstream_LabelオブジェクトはPathメッセージを送るとき推進に、有効なラベルを示さなければなりません。
When a Path message containing an Upstream_Label object is received, the receiver first verifies that the upstream label is acceptable. If the label is not acceptable, the receiver MUST issue a PathErr message with a "Routing problem/Unacceptable label value" indication. The generated PathErr message MAY include an Acceptable Label Set, see Section 4.1.
Upstream_Labelオブジェクトを含むPathメッセージが受信されているとき、受信機は、最初に、上流のラベルが許容できることを確かめます。 ラベルが許容できないなら、受信機は「ルート設定問題/容認できないラベル値」指示でPathErrメッセージを発行しなければなりません。 セクション4.1は、発生しているPathErrメッセージがAcceptable Label Setを含むかもしれないのを見ます。
An intermediate node must also allocate a label on the outgoing interface and establish internal data paths before filling in an outgoing upstream label and propagating the Path message. If an intermediate node is unable to allocate a label or internal resources, then it MUST issue a PathErr message with a "Routing problem/MPLS label allocation failure" indication.
中間的ノードは、また、外向的なインタフェースにラベルを割り当てて、出発している上流のラベルに記入して、Pathメッセージを伝播する前に、内部のデータ経路を確立しなければなりません。 中間的ノードがラベルか社内資源を割り当てることができないなら、それは「ルート設定問題/MPLSラベル割り振りの失敗」指示でPathErrメッセージを発行しなければなりません。
Terminator nodes process Path messages as usual, with the exception that the upstream label can immediately be used to transport data traffic associated with the LSP upstream towards the initiator.
ターミネーターノードはすぐにLSP上流に関連しているデータ通信量を創始者に向かって輸送するのに上流のラベルを使用できるという例外による通常通りのPathメッセージを処理します。
When a bidirectional LSP is removed, both upstream and downstream labels are invalidated and it is no longer valid to send data using the associated labels.
双方向のLSPが取り外されるとき、上流の、そして、川下の両方のラベルは無効にされます、そして、データを送るのは、もう関連ラベルを使用することで有効ではありません。
3.2. Contention Resolution
3.2. 主張解決
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番目はノードIDがRSVP主張解決の目的のための、RSVP_HOPオブジェクトで使用されるIPアドレスであるということです。 2番目は初期のPathメッセージを送るとき、隣人のノードIDが知られていないかもしれないということです。 本件が現れると、ノードは利用可能なラベルスペースから無作為に選ばれたラベルを示すはずです。
4. Notification
4. 通知
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
このセクションはいくつかの通知関連する拡大をカバーします。 最初の拡大は、[RFC3471]あたりのLabel Errorの上のNotificationをサポートするためにAcceptable Label Setオブジェクトを定義します。 拡大が可能にする2番目と3番目は失敗したLSPsを返すのに原因となるノードに失敗と他のイベントの通知を速めました。 (2番目の拡大(Notify Requestオブジェクト)がどこかを特定する、イベント
Berger Standards Track [Page 9] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[9ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
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.
通知は送ることです。 3番目の拡大(Notifyメッセージ)は一般的なイベント通知に備えます。) 最終通告関連する拡張子はPathErrメッセージの取り扱いのPath状態の取り外しを考慮します。
4.1. Acceptable Label Set Object
4.1. 許容できるラベル・セットオブジェクト
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(フォーム10bbbbbbの)のClass-数を使用します。 セクション2.6は、Label_Setが反対するようにC-タイプを含むオブジェクトの残っている内容には同じ形式があるのを見ます。
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は、Acceptable Label Setを定義するための手順がLabel Setを定義するために手順に従うのを見ます。 明確に、Acceptable Label Setは1個以上のAcceptable_Label_Setオブジェクトを通して定義されます。 特定のラベル/サブチャネルは、(0)と1(1)オブジェクトをそれぞれ加えるか、またはActionゼロを通したAcceptable Label Setから除くことができます。 ラベル/サブチャネルの範囲は、(2)と3(3)オブジェクトをそれぞれ加えるか、またはAction twoを通したAcceptable Label Setから除くことができます。 Acceptable_Label_Setオブジェクトが除くラベル/サブチャネルを記載するだけであるとき、これは、他のすべてのラベルが許容できるのを含意します。
The inclusion of Acceptable_Label_Set objects is optional. If included, the PathErr or ResvErr message SHOULD contain a "Routing problem/Unacceptable label value" indication. The absence of Acceptable_Label_Set objects does not have any specific meaning.
Acceptable_Label_Setオブジェクトの包含は任意です。 含まれているなら、PathErrかResvErrメッセージSHOULDが「ルート設定問題/容認できないラベル値」指示を含んでいます。 Acceptable_Label_Setオブジェクトの不在には、少しの特定の意味もありません。
4.2. Notify Request Objects
4.2. 要求オブジェクトに通知してください。
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 Requestオブジェクトは、通知の世代を要求するのに使用されます。 すなわち、通知、Notifyメッセージの発信は両方の上流の、そして、川下の方向に要求されているかもしれません。
4.2.1. Required Information
4.2.1. 必須情報
The Notify Request Object may be carried in Path or Resv Messages, see Section 7. The Notify_Request Class-Number is 195 (of form 11bbbbbb). The format of a Notify Request is:
セクション7は、Notify Request ObjectがPathかResv Messagesで運ばれるかもしれないのを見ます。 Notify_Request Class-数は195(フォーム11bbbbbbの)です。 Notify Requestの形式は以下の通りです。
o IPv4 Notify Request Object
o IPv4は要求オブジェクトに通知します。
Berger Standards Track [Page 10] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[10ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム(1)| C-タイプ(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4はノードアドレスに通知します。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム(2)| C-タイプ(2)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6はノードアドレスに通知します。| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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オブジェクトを含んでいるなら、最初のオブジェクトだけが重要です。 _Requestが無視されるかもしれないのを反対させるその後のNotifyとSHOULD NOT、伝播されてください。
4.2.2. Procedures
4.2.2. 手順
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.
Notify RequestオブジェクトはPathかLSPの故障について通知されるべきであるノードのアドレスを示すResvメッセージに挿入されるかもしれません。 以前に言及されるように、通知は両方の上流の、そして、川下の方向に要求されているかもしれません。 上流の通知は対応するPathメッセージでのNotify Request Objectの包含で示されます。 川下の通知は対応するResvメッセージでのNotify Request Objectの包含で示されます。
Berger Standards Track [Page 11] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[11ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
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 Node Addressが妨げるNotify RequestオブジェクトSHOULD店を含むメッセージを受け取るノード。 ノードがそうなら、aはノードを通過して、それは出発しているPathかResvのまた、含まれているa Notify Requestオブジェクトが通信させるSHOULDです。 ローカルの方針に基づいて出発しているNotify Node Addressをアップデートするかもしれません。
Note that the inclusion of a Notify Request object does not guarantee that a Notify message will be generated.
Notify Requestオブジェクトの包含が、Notifyメッセージが生成されるのを保証しないことに注意してください。
4.3. Notify Message
4.3. メッセージに通知してください。
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 Requestオブジェクトを受け取った後にだけ生成します。 Notifyメッセージは即座の上流の、または、川下の隣人以外のノードに「狙うことができる」という点において現在定義されたエラーメッセージ(すなわち、PathErrとResvErrメッセージ)と異なっています、そして、それは一般化された通知メカニズムです。 Notifyメッセージは既存のエラーメッセージを置き換えません。 (a) 通常、Notifyメッセージを送るかもしれません、非目標ノードがただNotifyメッセージを目標ノードに転送するところで、[RFC2205]でのResvConf処理と同様です。 または、(b)は目的地が目標IPアドレスと等しい新しいIPヘッダーで要約されました。 効果波及経路にかかわらず、Notifyメッセージを受け取るノードがノードフォワードにメッセージを運命づけませんでした、変更されていません、目標に向かって。
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 Message[RFC2961]は、Notify Messageの領収書を受け取ったことを知らせるのに使用されます。 信頼できるRSVPメッセージ配送に関する詳細に関して[RFC2961]を見てください。
4.3.1. Required Information
4.3.1. 必須情報
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のMessage Typeがあります。 Notifyメッセージ・フォーマットは以下の通りです:
<Notify message> ::= <Common Header> [<INTEGRITY>]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<ERROR_SPEC> <notify session list>
<はメッセージ>に通知します:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<MESSAGE_ID>] ><が>を記載するようにセッションに通知する<ERROR_SPEC
Berger Standards Track [Page 12] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[12ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
<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]がサポートされるとき、使用されています。
4.3.2. Procedures
4.3.2. 手順
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メッセージが発生していることであり、Notify Requestオブジェクトを受け取ったなら、対応するPathメッセージ、次に運命づけられたNotifyメッセージでは記録されたノードSHOULDに生成してください。 ResvErrメッセージが発生していることであり、Notify Requestオブジェクトを受け取ったなら、対応するResvメッセージ、次に運命づけられたNotifyメッセージでは記録されたノードSHOULDに生成してください。 以前に言及されるように、ただ一つの誤りは、両方のNotifyメッセージが上流の、そして、川下の方向であると生成するかもしれません。 適切なNotify Requestオブジェクトが受け取られていない場合Notifyメッセージを生成してはいけないことに注意してください。
When generating Notify messages, a node SHOULD attempt to combine notifications being sent to the same Notify Node and that share the same ERROR_SPEC into a single Notify message. The means by which a node determines which information may be combined is implementation dependent. Implementations may use event, timer based or other approaches. If using a timer based approach, the implementation SHOULD allow the user to configure the interval over which notifications are combined. When using a timer based approach, a default "notification interval" of 1 ms SHOULD be used. Notify messages SHOULD be delivered using the reliable message delivery mechanisms defined in [RFC2961].
メッセージ、同じNotify Nodeとそれに送られる通知を結合するノードSHOULD試みをNotifyに生成するときには、同じERROR_SPECをただ一つのNotifyメッセージと共有してください。 ノードがどの情報が結合されるかもしれないかを決定する手段は実装に依存しています。 実装はイベント、基づくタイマまたは他のアプローチを使用するかもしれません。 タイマに基づいているアプローチを使用するなら、実装SHOULDはユーザに通知が結合されている間隔を構成させます。 使用するとき、タイマは1ms SHOULDについてアプローチ、デフォルト「通知間隔」を基礎づけました。使用されます。 提供された使用が[RFC2961]で定義された信頼できるメッセージ排紙機構であったならメッセージSHOULDに通知してください。
Upon receiving a Notify message, the Notify Node SHOULD send a corresponding Ack message.
Notifyメッセージを受け取ると、Notify Node SHOULDは対応するAckメッセージを送ります。
Berger Standards Track [Page 13] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[13ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
4.4. Removing State with a PathErr message
4.4. PathErrメッセージをもっている州を取り除きます。
The PathErr message as defined in [RFC2205] is sent hop-by-hop to the source of the associated Path message. Intermediate nodes may inspect this message, but take no action upon it. In an environment where Path messages are routed according to an IGP and that route may change dynamically, this behavior is a fine design choice.
ホップごとに[RFC2205]で定義されるPathErrメッセージを関連Pathメッセージの源に送ります。 中間的ノードはこのメッセージを点検するかもしれませんが、それへの行動を全く取らないでください。 IGPに応じてPathメッセージが発送されて、そのルートがダイナミックに変化するかもしれない環境で、この振舞いはよいデザイン選択です。
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を送らなければなりません(タイムアウトにメッセージを待ってください)。 これは、遊休資源が必要とするより長い間保持されることを引き起こして、コントロールメッセージ荷重を増強します。 制御飛行機が試みている状況で、重大な供給停止、メッセージ負荷とリソースが急速に能力を妨げる解放の遅れの両方から、reconvergeを回収してください。
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個の旗が定義されます。 Path_州_Removed、この仕様は3番目の旗、0×04を定義します。
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_州_Removed旗の意味論はエラーメッセージを転送するノードがPathErrに関連しているPath状態を取り除いたということです。 PathErrメッセージを生成するか、または転送するとき、デフォルトで、Path_州_Removed旗はいつもゼロに設定されます。 誤りが関連Path状態をもたらして、捨てられる場合、誤りに遭遇するノードはこの旗を設定するかもしれません。 旗を設定するノードがセッション終点でないなら、ノードSHOULDは対応するPathTearを生成します。 また、Path_州_Removed旗のセットでERROR_SPECオブジェクトを含むPathErrメッセージを受け取るノードは関連Path状態を取り除くかもしれません。 Path状態が取り除いて、Path_州_RemovedがSHOULDに旗を揚げさせるということであるなら、送信するPathErrメッセージに設定されてください。 関連Path状態を取り除かないノードはPath_州_Removed旗を設定してはいけません。 また、それが対応するPathTearメッセージを生成しない場合、ゼロに設定されたPath_州_Removed旗で誤りを受けるノードはこの旗を設定してはいけません。
Note that the use of this flag does not result in any interoperability incompatibilities.
この旗の使用がどんな相互運用性非互換性ももたらさないことに注意してください。
Berger Standards Track [Page 14] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[14ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
5. Explicit Label Control
5. 明白なラベルコントロール
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.
Label ERO(明白なRoute Object)とRRO(Route Objectを記録する)「副-オブジェクト」は、Explicit Label Controlをサポートするために定義されます。 Label RRO subobjectが[RFC3209]で定義されて、双方向のLSPsをサポートするために広げられていることに注意してください。
5.1. Label ERO subobject
5.1. ラベルERO subobject
The Label ERO subobject is defined as follows:
Label 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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| タイプ| 長さ|U| 予約されます。| C-タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ラベル| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of L, U and Label parameters.
L、U、およびLabelパラメタの記述に関して[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.
LengthはTypeとLength分野を含むバイトで表現される「副-オブジェクト」の全長を含んでいます。 Lengthはいつも4で分割可能です。
C-Type
C-タイプ
The C-Type of the included Label Object. Copied from the Label
Object.
含まれているLabel ObjectのC-タイプ。 ラベルオブジェクトから、コピーされます。
5.1.1. Procedures
5.1.1. 手順
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:
Label subobjectはIPアドレス、またはインタフェース識別子[RFC3477]を含む「副-オブジェクト」に続きます、それが使用されていることになっているリンクに関連しています。 最大2ラベル「副-オブジェクト」は、プレゼントと、川下のラベルのためのものと上流のラベルのためのものであるかもしれません。 以下のSHOULDは「悪いEXPLICIT_ROUTEオブジェクト」誤りをもたらします:
o If the first label subobject is not preceded by a subobject
containing an IP address, or an interface identifier [RFC3477],
associated with an output link.
o 最初のラベルであるなら、「副-オブジェクト」はIPアドレス、またはインタフェース識別子[RFC3477]を含む「副-オブジェクト」によって先行されていません、出力リンクに関連しています。
Berger Standards Track [Page 15] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[15ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
o For a label subobject to follow a subobject that has the L-bit set
o ラベル「副-オブジェクト」が「副-オブジェクト」に続くように、それで、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 そこでは、2ラベルであることが同じU-ビット値で副反対します。
To support the label subobject, a node must check to see if the subobject following its associate address/interface is a label subobject. If it is, one subobject is examined for unidirectional LSPs and two subobjects for bidirectional LSPs. If the U-bit of the subobject being examined is clear (0), then value of the label is copied into a new Label_Set object. This Label_Set object MUST be included on the corresponding outgoing Path message.
ラベルが「副-オブジェクト」であるとサポートするなら、ノードは、副アドレス/インタフェースに続く「副-オブジェクト」がラベル「副-オブジェクト」であるかどうか確認するためにチェックしなければなりません。 それがそうなら、1個の「副-オブジェクト」が双方向のLSPsのために単方向LSPsと2個の「副-オブジェクト」がないかどうか調べられます。 調べられる「副-オブジェクト」のU-ビットが明確な(0)であるなら、ラベルの値は新しいLabel_Setオブジェクトにコピーされます。 対応する送信するPathメッセージにこの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に関連している上流のトラフィックに使用されるべきラベルです。 このラベルが許容できるa「悪いEXPLICIT_ROUTEオブジェクト」誤りSHOULDでないなら、生成されてください。 ラベルが許容できるなら、ラベルは新しいUpstream_Labelオブジェクトにコピーされます。 対応する送信するPathメッセージにこの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.
上の手順の含意がラベル「副-オブジェクト」が新たに受け取られたメッセージで決して最初の「副-オブジェクト」であるべきでないということであることに注意してください。 ラベル「副-オブジェクト」が最初の「副-オブジェクト」であるなら、aはEROを受けて、次に、それはSHOULD aとして扱われた「悪い厳しいノード」誤りです。
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がLabel subobjectを組み立てるのに必要である情報を得る手順があります。
5.2. Label RRO subobject
5.2. ラベルRRO subobject
The Label RRO subobject is defined as follows:
Label 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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ|U| 旗| C-タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ラベル| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of U and Label parameters.
UとLabelパラメタの記述に関して[RFC3471]を見てください。
Berger Standards Track [Page 16] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[16ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
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.
含まれているLabel ObjectのC-タイプ。 ラベルオブジェクトから、コピーされます。
5.2.1. Procedures
5.2.1. 手順
Label RRO subobjects are included in RROs as described in [RFC3209]. The only modification to usage and processing from [RFC3209] is that when labels are recorded for bidirectional LSPs, label ERO subobjects for both downstream and upstream labels MUST be included.
ラベルRRO subobjectsは[RFC3209]で説明されるようにRROsに含まれています。 用法への唯一の変更と[RFC3209]からの処理はラベルが双方向のLSPsのために記録されるとき、川下の、そして、上流の両方のラベルのためのラベルERO subobjectsを含まなければならないということです。
6. Protection Object
6. 保護オブジェクト
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).
Protection Objectの使用は任意です。 オブジェクトは、LSPの特異的予防属性を示すために含まれています。 Protection ObjectはClass-No.37(フォーム0bbbbbbbの)を使用します。
The format of the Protection Object is:
Protection Objectの形式は以下の通りです。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム(37)| C-タイプ(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| 予約されます。| リンク旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
パラメタの記述に関して[RFC3471]を見てください。
Berger Standards Track [Page 17] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[17ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
6.1. Procedures
6.1. 手順
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.
Protection Objectを含むPathメッセージを処理するトランジットノードは、外向的なインタフェースかトンネル(FA)で要求された保護を満たすことができることを確かめなければなりません。 そうすることができないなら、ノードは「ルート設定の問題/サポートされないリンク保護」指示でPathErrメッセージを生成しなければなりません。
7. Administrative Status Information
7. 管理状態情報
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.
管理Status情報はAdmin_Statusオブジェクトで運ばれます。 オブジェクトは特定のLSPの管理州に関連する情報を提供します。 情報は2つの方法で使用されます。 1番目では、オブジェクトはPathとLSPの管理州を示すResvメッセージで運ばれます。 2番目では、オブジェクトはイングレスノードがLSPの管理州を変えるよう要求するNotificationメッセージで運ばれます。
7.1. Admin Status Object
7.1. アドミン状態オブジェクト
The use of the Admin_Status Object is optional. It uses Class-Number 196 (of form 11bbbbbb).
Admin_Status Objectの使用は任意です。 それはClass-No.196(フォーム11bbbbbbの)を使用します。
The format of the Admin_Status Object is:
Admin_Status Objectの形式は以下の通りです。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム(196)| C-タイプ(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| 予約されます。|T|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
パラメタの記述に関して[RFC3471]を見てください。
7.2. Path and Resv Message Procedures
7.2. 経路とResvメッセージ手順
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の状態の経路に沿った各ノードに通知するのに使用されます。 状態情報は、ローカルの方針に基づく各ノードによって処理されて、次に、対応する送信されるメッセージで伝播されます。 オブジェクトはイングレス(Pathメッセージのための)か出口(Resvメッセージのための)ノードの裁量でPathかResvメッセージのどちらかに挿入されるかもしれません。 オブジェクトの不在はすべてが(0)のゼロを合わせるように設定する値を含むオブジェクトを受けるのに同等です。
Berger Standards Track [Page 18] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[18ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
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).
aを受けて、ノードを通過してください、非、リフレッシュ、PathかResvがAdmin_Statusオブジェクトを含んでいて、通信して、地元の状態をアップデートして、示された状態に基づくどんな適切な地方の行動も取って、次に、対応する出発しているPathかResvメッセージで容認されたAdmin_Statusオブジェクトを伝播します。 Resvメッセージに受け取られたAdmin_Statusオブジェクトの値がその時Pathメッセージに受け取られた値と異なっているなら、ただ1つを例外として、どんな地方の行動も取るべきではありませんが、まだ値を伝播しているべきです。 Resvメッセージで受け取られていている値が地方の動作をもたらすべきである1つのケースは容認されたRとDビットの両方がそうであるときに、すなわち、設定されているのが、1つ(1)であるということです。
Edge nodes receiving a non-refresh Path or Resv message containing an Admin_Status object, also update their local state and take any appropriate local action based on the indicated status. When an Admin Status object is received with the R bit set, the receiving edge node should reflect the received values in a corresponding outgoing message. Specifically, if an egress node receives a Path message with the R bit of the Admin_Status object set and the node has previously issued a Resv message corresponding to the Path message, the node SHOULD send an updated Resv message containing an Admin_Status object with the same values set, with the exception of the R bit, as received in the corresponding Path message. Furthermore, the egress node SHOULD also ensure that subsequent Resv messages sent by the node contain the same Admin Status Object.
aを受けて、ノードを斜めに進ませてください、非、リフレッシュ、Pathか_Adminを含んでいて、Statusが反対して、また、地元の状態をアップデートするというResvメッセージとどんな適切な地方の動きも示された状態に基礎づけた撮影。 Rビットがセットした状態でAdmin Statusオブジェクトを受け取るとき、受信縁のノードは容認された値を対応する送信されるメッセージに反映するはずです。 明確に、出口ノードがAdmin_StatusオブジェクトセットのRビットでPathメッセージを受け取って、ノードが以前にPathメッセージに対応するResvメッセージを発行したなら、ノードSHOULDはRビットを除いて、設定された同じ値があるAdmin_Statusオブジェクトを含むアップデートされたResvメッセージを送ります、対応するPathメッセージに受け取るように。 その上、また、出口ノードSHOULDは、ノードによって送られたその後のResvメッセージが同じAdmin Status Objectを含むのを確実にします。
Additionally, if an ingress node receives a Resv message with the R bit of the Admin_Status object set, the node SHOULD send an updated Path message containing an Admin_Status object with the same values set, with the exception of the R bit, as received in the corresponding Resv message. Furthermore, the ingress node SHOULD also ensure that subsequent Path messages sent by the node contain the same Admin Status Object.
さらに、イングレスノードがAdmin_StatusオブジェクトセットのRビットでResvメッセージを受け取るなら、ノードSHOULDはRビットを除いて、設定された同じ値があるAdmin_Statusオブジェクトを含むアップデートされたPathメッセージを送ります、対応するResvメッセージに受け取るように。 その上、また、イングレスノードSHOULDは、ノードによって送られたその後のPathメッセージが同じAdmin Status Objectを含むのを確実にします。
7.2.1. Deletion procedure
7.2.1. 削除手順
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の管理状態を設定するのは役に立ちます。 そのような事情の手順SHOULD、イングレスからLSPを削除するときには、続かれてください:
1. The ingress node precedes an LSP deletion by inserting an Admin
Status Object in a Path message and setting the Reflect (R) and
Delete (D) bits.
1. PathメッセージにAdmin Status Objectを挿入して、Reflect(R)とDelete(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. トランジットと出口ノードは上で説明されるようにAdmin Status Objectを処理します。 (セクション4.4は、あるいはまた、出口がPath_州_Removed旗のセットと共にPathErrメッセージで応じるかもしれないのを見ます。)
Berger Standards Track [Page 19] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[19ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
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)ビットでAdmin Status Objectを受けると、イングレスノードはLSPを取り外すためにPathTearメッセージを川下に送ります、そして、通常のRSVP処理は行われます。
In such circumstances the procedure SHOULD be followed when deleting an LSP from the egress:
そのような事情の手順SHOULD、出口から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メッセージにAdmin Status Objectを挿入して、Reflect(R)とDelete(D)ビットを設定することによって、削除に関する願望を示します。
2. Transit nodes process the Admin Status Object as described above.
2. トランジットノードは上で説明されるようにAdmin Status Objectを処理します。
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)ビットでAdmin Status Objectを受けると、イングレスノードはLSPを取り外すためにPathTearメッセージを川下に送ります、そして、通常のRSVP処理は行われます。
7.2.2. Compatibility and Error Procedures
7.2.2. 互換性と誤り処理手続き
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に沿ったいくつかのノードがAdmin Status Objectを支えないのは、可能です。 非サポートトランジットノードの場合では、オブジェクトは変更されていなくノードを通り抜けるでしょう、そして、正常処理は続くことができます。 非サポート出口ノードの場合では、Admin Status ObjectはResv Messageで映し出されないでしょう。 非サポート出口ノードに関するケースを支えるために、イングレスSHOULDはResvメッセージでアップデートされたAdmin Status Objectに、構成可能な期間を待つだけです。 期間がいったん経過すると、イングレスノードはPathTearメッセージを送ります。 デフォルトで、この期間SHOULD、30秒になってください。
7.3. Notify Message Procedures
7.3. メッセージ手順に通知してください。
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.
中間介在物と出口ノードはNotifyメッセージの使用で管理状態の設定の引き金となるかもしれません。 これを達成するために、中間介在物か出口ノードが上流がセッション情報に通知する対応でNotifyメッセージを生成します。 セッション情報に適切なビットでAdmin Status Objectを含まなければならない、さもなければ、ビットはセットしました。 Reflect(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)ビットでAdmin Status Objectを含むNotifyメッセージを受け取るイングレスノードはセットして、SHOULDは前項で説明された削除手順に着手します。 他のビットSHOULD、正常な送信するPath同じくらいメッセージで伝播されてください。
Berger Standards Track [Page 20] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[20ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
7.3.1. Compatibility and Error Procedures
7.3.1. 互換性と誤り処理手続き
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.
何らかの特別な処理が、Admin Status Objectを支えないノードと他のエラー条件に関するケースをカバーするのに必要です。 明確に、Down(D)ビットがセットした状態でAdmin Status Objectを含むNotifyメッセージを送るノードは、構成可能な期間以内に設定されたDown(D)ビットで対応するPathメッセージを受け取ることを確かめなければなりません。 デフォルトで、この期間SHOULD、30秒になってください。 ノードがそうしないなら、そのようなPathメッセージを受け取ってください、それ。SHOULDはPathTearメッセージを川下に送ります、そして、Path_州_Removed旗があるResvTearメッセージかPathErrメッセージのどちらかが上流へセットしました。
8. Control Channel Separation
8. コントロールチャネルセパレーション
This section provides the protocol specific formats and procedures to required support a control channel not being in-band with a data channel.
このセクションはコントロールが向ける必要なサポートへのデータ・チャンネルでバンドでない特定の形式と手順をプロトコルに提供します。
8.1. Interface Identification
8.1. インタフェース識別
The choice of the data interface to use is always made by the sender of the Path message. The choice of the data interface is indicated by the sender of the Path message by including the data channel's interface identifier in the message using a new RSVP_HOP object sub- type. For bidirectional LSPs, the sender chooses the data interface in each direction. In all cases but bundling, the upstream interface is implied by the downstream interface. For bundling, the path sender explicitly identifies the component interface used in each direction. The new RSVP_HOP object is used in Resv message to indicate the downstream node's usage of the indicated interface(s).
使用するデータインタフェースの選択はいつもPathメッセージの送付者によってされます。 データインタフェースの選択は、メッセージに新しいRSVP_HOP物のサブタイプを使用することでデータ・チャンネルのインタフェース識別子を含んでいることによって、Pathメッセージの送付者によって示されます。 双方向のLSPsのために、送付者は各方向にデータインタフェースを選びます。 すべてのケースにもかかわらず、バンドリングでは、上流のインタフェースは川下のインタフェースによって含意されます。 バンドリングのために、経路送付者は明らかに各方向に使用されるコンポーネントインタフェースを特定します。 新しいRSVP_HOP物は川下のノードの示されたインタフェースの用法を示すResvメッセージで使用されます。
Berger Standards Track [Page 21] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[21ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
8.1.1. IF_ID RSVP_HOP Objects
8.1.1. _ID RSVP_が物を飛び越すなら
The format of the IPv4 IF_ID RSVP_HOP Object is:
_ID RSVP_HOP Objectであるなら、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 (3) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム(3)| C-タイプ(3)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4次/の前のホップアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 論理的なインタフェースハンドル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 IF_ID RSVP_HOP Object is:
_ID RSVP_HOP Objectであるなら、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 (3) | C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Next/Previous Hop Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム(3)| C-タイプ(4)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6次/の前のホップアドレス| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 論理的なインタフェースハンドル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC2205] for a description of hop address and handle fields. See [RFC3471] for a description of parameters and encoding of TLVs.
ホップアドレスの記述に関して[RFC2205]を見てください、そして、分野を扱ってください。 パラメタの記述とTLVsのコード化に関して[RFC3471]を見てください。
Berger Standards Track [Page 22] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[22ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
8.1.2. Procedures
8.1.2. 手順
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].
__ID RSVP_HOP物が以前に定義されたRSVPに代わって使用されるなら、HOPは反対します。 それはデータ・チャンネルの制御チャンネルの1〜1つの協会がないリンクの上に使用されます、と[RFC3471]は見ます。 Hop AddressとLogical Interface Handle分野は標準の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.
TLVsは、LSPに関連しているデータ・チャンネルを特定するのに使用されます。 LSP、川下のデータ・チャンネルがそうしなければならない単方向、示されてください。 双方向のLSPsに関しては、通常、川下で一般的で上流のデータ・チャンネルは示されます。 束ねられたリンクを横断する双方向のLSPであり川下を指定するのが可能であるデータが向ける特別な場合では、それは上流のデータ・チャンネルと異なっています。 データ・チャンネルはPathメッセージの送付者の観点から指定されます。 TLVsは全く必要でないときに、_ID RSVP_HOP物のSHOULD NOTであるなら、使用されてください。
A node receiving one or more TLVs in a Path message saves their values and returns them in the HOP objects of subsequent Resv messages sent to the node that originated the TLVs.
Pathメッセージで1TLVsを受けるノードは、TLVsを溯源したノードに送られたその後のResvメッセージのHOP物で彼らの値を節約して、それらを返します。
Note, the node originating an IF_ID object MUST ensure that the selected outgoing interface, as specified in the IF_ID object, is consistent with an ERO. A node that receives an IF_ID object SHOULD check whether the information carried in this object is consistent with the information carried in a received ERO, and if not it MUST send a PathErr Message with the error code "Routing Error" and error value of "Bad Explicit Route Object" toward the sender. This check CANNOT be performed when the initial ERO subobject is not the incoming interface.
ノードが由来して、注意する、_ID物が選択された外向的な同じくらいインタフェースであって、中で同じくらい指定されていた状態でそれを確実にしなければならない、_ID物がEROと一致しているなら。 受信するノード、_ID物のSHOULDが、情報が運び込んだかどうかチェックするなら、この物は容認されたEROで運ばれる情報と一致していて、そうでなければ、それは「悪い明白なルート物」のエラーコード「ルート設定誤り」と誤り値があるPathErr Messageを送付者に向かって送らなければなりません。 初期のERO subobjectが入って来るインタフェースでないときに、このチェックは実行されません。
8.2. Errored Interface Identification
8.2. インタフェース識別をErroredしました。
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.
ケースが誤りに関連している特定のインタフェースを示すのが役に立つところにあります。 これらのケースを支える、_ID ERROR_SPEC Objectsが定義されるなら。
Berger Standards Track [Page 23] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[23ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
8.2.1. IF_ID ERROR_SPEC Objects
8.2.1. _ID誤り_仕様が反対するなら
The format of the IPv4 IF_ID ERROR_SPEC Object is:
_ID ERROR_SPEC Objectであるなら、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 (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム(6)| C-タイプ(3)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4誤りノードアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 旗| エラーコード| 誤り値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 IF_ID ERROR_SPEC Object is:
_ID ERROR_SPEC Objectであるなら、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 (6) | C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Error Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム(6)| C-タイプ(4)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6誤りノードアドレス| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 旗| エラーコード| 誤り値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 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]を見てください。 パラメタの記述とTLVsのコード化に関して[RFC3471]を見てください。
8.2.2. Procedures
8.2.2. 手順
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].
誤りが特定のインタフェースSHOULDに関連するのを示したがっているノードが_対応するPathErrかResvErrメッセージのID ERROR_SPEC Objectであるなら好個を使用します。 _ID ERROR_SPEC Objects SHOULDが発生していかなる他のERROR_SPEC Objectとしても処理されているなら、[RFC2205]を見てください。
Berger Standards Track [Page 24] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[24ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
9. Fault Handling
9. 欠点取り扱い
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つのタイプのコントロール通信エラーの取り扱いはこのセクションで説明されます。 こぶのような欠点と呼ばれた1番目はしかしコントロールが述べる(例えば、再開の後に)ノードの損失が状態を進めながらデータを発射しないケースに関連します。 2番目では、コントロールチャンネル欠点と呼ばれて、コントロールコミュニケーションが2つのノードの間で失われているケースに関連します。 両方の欠点の取り扱いは下で定義されて、必要である_CapがHelloメッセージの使用を反対させるRestartによって支持されます。
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]からこのセクションを得ます。
9.1. Restart_Cap Object
9.1. 再開_キャップ物
The Restart_Cap Object is carried in Hello messages.
Restart_Cap ObjectはHelloメッセージで運ばれます。
The format of the Restart_Cap Object is:
Restart_Cap Objectの形式は以下の通りです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム(131)| C-タイプ(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 再開時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 回復時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
再開Timeはミリセカンドで測定されます。 現代の合計へのそれが送付者を連れて行くセットがRSVP-TEの部品(それが隣人とRSVP Helloを交換できるポイントへの)とRSVPコミュニケーションに使用される通信チャネルを再開する物であったならTime SHOULDを再開してください。 0xffffffffの値は送付者の制御飛行機の再開が不確定の間隔の間起こるかもしれなくて、データ飛行機の操作がコントロール飛行機の故障で影響を受けないのを示します。 方法は、以前はよくこのドキュメントの範囲の外に継続的なデータ飛行機操作があるのを保証していました。
Berger Standards Track [Page 25] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[25ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
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同期の再建の後に状態を進めるRSVPとMPLSを送付者に再連動させることを望んでいるミリセカンドで表現される期間。 (0)がない値は、MPLS推進状態が特定のリブートの向こう側に保持されなかったのを示します。
9.2. Processing of Restart_Cap Object
9.2. 再開_キャップ物の処理
Nodes supporting state recovery advertise this capability by carrying the Restart_Cap object in Hello messages. Such nodes MUST include the Restart_Cap object in all Hello messages. (Note that this includes Hello messages containing ACK objects.) Usage of the special case Recovery Time values is described in greater detail below.
州の回復を支えるノードが、HelloメッセージでRestart_Cap物を運ぶことによって、この能力の広告を出します。 そのようなノードはすべてのHelloメッセージにRestart_Cap物を含まなければなりません。 (これがACK物を含むHelloメッセージを含んでいることに注意してください。) 特別なケースRecovery Time値の用法は以下で詳細によりすばらしい説明されます。
When a node receives a Hello message with the Restart_Cap object, it SHOULD record the values of the parameters received.
ノードがRestart_でHelloメッセージを受け取るとき、Capは反対して、それはパラメタの値が受け取ったSHOULD記録です。
9.3. Modification to Hello Processing to Support State Recovery
9.3. 変更、こんにちは、州の回復を支持するために処理すること。
When a node determines that RSVP communication with a neighbor has been lost, and the node previously learned that the neighbor supports state recovery, the node SHOULD wait at least the amount of time indicated by the Restart Time indicated by the neighbor before invoking procedures related to communication loss. A node MAY wait a different amount of time based on local policy or configuration information.
ノードが、隣人とのRSVPコミュニケーションが失われたことを決定して、ノードが、以前に隣人が州の回復を支持することを学んだとき、ノードSHOULDは少なくともコミュニケーションの損失に関連する手順を呼び出す前に隣人によって示されたRestart Timeによって示された時間を待っています。 ノードはローカルの方針か設定情報に基づく異なった時間を待つかもしれません。
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.
この待ちの期間、Instance値が(0)のゼロを合わせるように設定したDst_ですべてのHelloメッセージを送らなければなりません、そして、Src_Instanceは変わりがないはずです。 また、待っている間、ノードSHOULDはRSVPを保存します、そして、(既に)のために状態を進めるMPLSがノードと隣人とのリンクを横断するLSPsを設立しました。 ある意味で、まるで受信し続けているかのようにノードが反応させる確立したLSPsに関して、周期的なRSVPは隣人からのメッセージをリフレッシュします。 リフレッシュしてください。ノードの5月の明確なRSVPとLSPsのための設立されることの途中にある状態にいつを送るか、彼ら、タイマは期限が切れます。 ResvとPath州のSHOULDをリフレッシュして、この待ちの期間、抑圧されてください。
During this waiting period, the node MAY inform upstream nodes of the communication loss via a PathErr and/or upstream Notify message with "Control Channel Degraded State" indication. If such notification has been sent, then upon restoration of the control channel the node
この待ちの期間、ノードは「コントロールのチャンネルの降格している状態」指示でPathErr、そして/または、上流のNotifyメッセージでコミュニケーションの損失の上流のノードを知らせるかもしれません。 そのようなものであるなら、通知を送って、制御チャンネルの修復でのその時はノードです。
Berger Standards Track [Page 26] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[26ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
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、そして/または、上流のNotifyメッセージで回復の他のノードを知らせなければなりません。 (特定のエラーコードは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に基づいています。 値が欠点の前に隣人から受け取られた値と異なるなら、隣人はまるで再開したかのように扱われるべきです。 さもなければ、欠点は限られた制御チャンネルでした。 各ケースを扱うための手順は以下で説明されます。
9.4. Control Channel Faults
9.4. コントロールチャンネル欠点
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.
コントロールチャンネル欠点の場合では、ノードSHOULDは隣人と共有されたすべての状態をリフレッシュします。 ACK_Desired旗のセットSHOULDが中古であって、支持されている概要Refreshes[RFC2961。] いくつかのペースが多くのメッセージが必要性であるなら、適用されるべきであることに注意してください。 すべてが、SHOULDが隣人によって広告に掲載されたRecovery時中にリフレッシュされると述べます。
9.5. Nodal Faults
9.5. こぶのような欠点
Recovering from nodal faults uses one new object and other existing protocol messages and objects.
こぶのような欠点から回復するのは1個の新しい物、他の既存のプロトコルメッセージ、および物を使用します。
9.5.1. Recovery Label
9.5.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(フォーム0bbbbbbbの)のClass-数と示されるラベルのC-タイプを使用します。
9.5.2. Procedures for the Restarting node
9.5.2. Restartingノードのための手順
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推進状態を保持できたか否かに関係なく、SHOULDがチェックする州の回復を支えるノードです。 再開がことになる保存されています、次に、ノードがノードが隣人に送るHelloメッセージの0にRecovery Timeを設定しなければならないという前状態を進めません。
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と呼ばれます。 Restart_Cap物のRecovery Timeパラメタの回復ノードはRecovery Periodの総持続時間の広告を出します。 Recovery Timeは持続時間に用意ができなければなりません。
Berger Standards Track [Page 27] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[27ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
Recovery Period in all Hello messages sent during the Recovery Period. State that is not resynchronized during the Recovery Period SHOULD be removed at the end of the Period.
すべてのHelloメッセージの回復PeriodはRecovery Periodの間、発信しました。 すなわち、Recovery Period SHOULDの間、再連動しないで、Periodの端で取り除かれるように述べてください。
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同期の間、再開ノードが、隣人が州の回復を支持しないことを決定して、再開ノードが隣人基礎あたりのaで状態を進めながらMPLSを主張するなら、その隣人が完成している状態で再開ノードがすぐにRecovery Periodを考えるはずであることに注意してください。 ラベルがインタフェースに従って二地点間インタフェースで使用されるとき、隣人基礎あたりのaで推進状態が維持されると考えられるかもしれません。
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.
ノードがRecovery Periodの間Pathメッセージを受け取るとき、ノードは、最初に、それでメッセージに関連しているRSVP状態があるかどうかチェックします。 状態が見つけられるなら、以前に定義された手順によると、ノードはこのメッセージを扱います。
If the RSVP state is not found, and the message does not carry a Recovery_Label object, the node treats this as a setup for a new LSP, and handles it according to previously defined procedures.
RSVP状態が見つけられないで、またメッセージがRecovery_Label物を運ばないなら、ノードは、新しいLSPのためにセットアップとしてこれを扱って、以前に定義された手順によると、それを扱います。
If the RSVP state is not found, and the message carries a Recovery_Label object, the node searches its MPLS forwarding table (the one that was preserved across the restart) for an entry whose incoming interface matches the Path message and whose incoming label is equal to the label carried in the Recovery_Label object.
RSVP状態が見つけられないで、メッセージがRecovery_Label物を運ぶなら、ノードは入って来るインタフェースがPathメッセージに合って、入って来るラベルがRecovery_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 appropriate RSVP state is created, the entry is bound to the LSP associated with the message, and related forwarding state should be considered as valid and refreshed. Normal Path message processing should also be conducted. When sending the corresponding outgoing Path message the node SHOULD include a Suggested_Label object with a label value matching the outgoing label from the now restored forwarding entry. The outgoing interface SHOULD also be selected based on the forwarding entry. In the special case where a restarting node also has a restating downstream neighbor, a Recovery_Label object should be used instead of a Suggested_Label object.
テーブル項目を進めるMPLSが見つけられるなら、適切なRSVP状態が創設されて、エントリーがメッセージに関連しているLSPに縛られて、関連する推進状態は、有効であるとみなされて、リフレッシュされるべきです。 また、通常のPathメッセージ処理が行われるべきです。 対応する送信するPathメッセージにノードを送るとき、SHOULDはラベル値が現在回復した推進エントリーから出発しているラベルに合っているSuggested_Label物を含んでいます。 外向的はSHOULDを連結します、また、推進エントリーに基づいて、選択されてください。 また再開ノードには言い直している川下の隣人がいる特別な場合では、Suggested_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
さらに、双方向のLSPs、UPSTREAM_LABEL物からのラベルが受信されたPathメッセージ、および検索で運んだノード抽出のために、MPLS推進はエントリーに外向的にだれのものをテーブルの上に置きます。
Berger Standards Track [Page 28] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[28ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
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).
ラベルは物で運ばれたラベルと等しいです(かかわった1番目がも適切な入って来るコンポーネントリンクを特定して、リンクバンドリングの場合では、これはそうするかもしれません)。
If the MPLS forwarding table entry is not found, the node treats this as a setup for a new LSP, and handles it according to previously defined procedures.
テーブル項目を進めるMPLSが見つけられないなら、ノードは、新しいLSPのためにセットアップとしてこれを扱って、以前に定義された手順によると、それを扱います。
If the MPLS forwarding table entry is found, the entry is bound to the LSP associated with the Path message, and the entry should be considered to be re-synchronized. In addition, if the node is not the tail-end of the LSP, the corresponding outgoing Path messages is sent with the incoming label from that entry carried in the UPSTREAM_LABEL object.
テーブル項目を進めるMPLSが見つけられるなら、エントリーはPathメッセージに関連しているLSPに縛られます、そして、エントリーが再連動すると考えられるべきです。 さらに、ノードがLSPの末端でないなら、入って来るラベルでUPSTREAM_LABEL物で運ばれたそのエントリーから対応する送信するPathメッセージを送ります。
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.
Recovery Periodの間、通常、Resvメッセージは2つの例外で処理されます。 推進エントリーが回復されて、どんな新しいラベルも資源配分もResvメッセージを処理する間、必要ではありません。 2番目の例外は合っているPath状態のないResvメッセージが受信されているとき、ResvErrメッセージSHOULD NOTが発生するということです。 この場合、捨てられて、ResvメッセージSHOULDはまさしく静かにそうです。
9.5.3. Procedures for the Neighbor of a Restarting node
9.5.3. RestartingノードのNeighborのための手順
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.
以下はノードがRestart Timeの中で隣人の制御飛行機とのコミュニケーションを回復させるとき適用される手順を指定して、ノードは、隣人の制御飛行機が再開して、隣人が再開の向こう側に推進状態を保持できたことを決定します([RFC3209]のセクション5で定義された手順を用います)(隣人から受け取られたRSVP HelloメッセージのRestart_Cap物で運ばれた非ゼロRecovery Timeによって示されたように)。 注意、0xffffffffのRestart Time値は無限のRestart Time間隔を示します。
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.
州の回復、ノードをサポートする隣人と共に再開を検出すると、SHOULDはその隣人と共有されたすべてのPath状態をリフレッシュします。 送信するPathメッセージは最も最近受信された対応するResvメッセージのラベル対価領収に対応するラベル値を含むRecovery_Label物を含まなければなりません。 すべてのPathが、SHOULDが再開している隣人によって広告に掲載された1/2Recovery回の頃以内にリフレッシュされると述べます。 再開ノードを調べるLSPの多くのものがあれば、隣人ノードは、短い時間間隔でメッセージをPathに送るのを避けるはずです、不要な強調を避けるほど。再開ノードのCPU。 代わりに、それは1/2の向こう側にメッセージを広げるべきです。Recovery Time間隔。
Berger Standards Track [Page 29] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[29ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
After detecting a restart of a neighbor that supports state recovery, all Resv state shared with the restarting node MUST NOT be refreshed until a corresponding Path message is received. This requires suppression of normal Resv and Summary Refresh processing to the neighbor during the Recovery Time advertised by the restarted neighbor. As soon as a corresponding Path message is received a Resv message SHOULD be generated and normal state processing SHOULD be re-enabled.
州の回復を支持する隣人の再開を検出した後に、対応するPathメッセージが受信されるまで、再開ノードと共有されたすべてのResv状態をリフレッシュしてはいけません。 これは再開している隣人によって広告に掲載されたRecovery Timeの間、正常なResvとSummary Refresh処理の抑圧を隣人に必要とします。 発生していて正常な状態が処理SHOULDであったなら対応するPathメッセージが受信されたa ResvメッセージSHOULDであるとすぐに、再可能にされてください。
10. RSVP Message Formats and Handling
10. RSVPメッセージ・フォーマットと取り扱い
This message summarizes RSVP message formats and handling as modified by GMPLS.
このメッセージはGMPLSによる変更されるとしてのRSVPメッセージ・フォーマットと取り扱いをまとめます。
10.1. RSVP Message Formats
10.1. 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メッセージに提示します。 彼らが異なるところでは、単方向LSPsの間の形式は別々に双方向のLSPsから提示されます。 変更されていない形式は記載されていません。 一方、MESSAGE_IDと関連する物は[RFC2961]で定義されます。
The format of a Path message is as follows:
Pathメッセージの形式は以下の通りです:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<経路メッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>] <セッション><RSVP_ホップ><時間_は>[<の明白な_ルート>]<ラベル_要求>[<保護>]を評価します[<ラベル_は>を…設定しました]。 [<セッション_属性>] [<は_要求>に通知します] [<アドミン_状態>] [<方針_データ>] <送付者記述子>。
Berger Standards Track [Page 30] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[30ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
The format of the sender description for unidirectional LSPs is:
単方向LSPsの間の送付者記述の形式は以下の通りです。
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
<送付者記述子>:、:= _<送付者_テンプレート><送付者TSPEC>[<ADSPEC>][<記録_ルート>][<は_ラベル>を示しました][<回復_ラベル>]
The format of the sender description for bidirectional LSPs is:
双方向のLSPsのための送付者記述の形式は以下の通りです。
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
<UPSTREAM_LABEL>
<送付者記述子>:、:= _<送付者_テンプレート><送付者TSPEC>[<ADSPEC>][<記録_ルート>][<は_ラベル>を示しました][<回復_ラベル>]<上流_ラベル>。
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>
<PathErrメッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>]<セッション><誤り_仕様>[<の許容できる_ラベル_は>を…設定します] [<方針_データ>] <送付者記述子>。
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>
<Resvメッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>] <セッション><RSVP_ホップ><時間_は>を評価します[<RESV_は>を確認します][<範囲>][<は_要求>に通知します][<アドミン_状態>][<方針_データ>…]。 <様式><流れ記述子リスト>。
<flow descriptor list> is not modified by this document.
<流れ記述子リスト>はこのドキュメントによって変更されません。
Berger Standards Track [Page 31] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[31ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
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>
<ResvErrメッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>]<セッション><RSVP_ホップ><誤り_仕様>[<範囲>][<の許容できる_ラベル_は>を…設定します] [<方針_データ>] <様式><誤り流れ記述子>。
The modified Hello message format is:
変更されたHelloメッセージ・フォーマットは以下の通りです。
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
[ <RESTART_CAP> ]
<、こんにちは、メッセージ>:、:= <一般的なヘッダー>[<保全>]<、こんにちは、>。[<再開_キャップ>]
10.2. Addressing Path, PathTear and ResvConf Messages
10.2. 経路、PathTear、およびResvConfメッセージを記述します。
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の経路に沿った)で隣接しているのを知って、直接アドレスへのメッセージが隣接に関連づけたSHOULDアドレスであるというノードへのPath、PathTearまたはResvConfメッセージを送るのは、ノードの制御飛行機ですか? この場合、含まれていなくて、ルータ警戒はSHOULDにゆだねます。
11. Acknowledgments
11. 承認
This document is the work of numerous authors and consists of a composition of a number of previous documents in this area.
このドキュメントは、多数の作者の仕事であり、この領域での前の多くのドキュメントの構成から成ります。
Valuable comments and input were received from a number of people, including Igor Bryskin, Adrian Farrel and Dimitrios Pendarakis. Portions of Section 4 are based on suggestions and text proposed by Adrian Farrel.
イーゴリBryskin、エードリアン・ファレル、およびデーメートリオスPendarakisを含む多くの人々から貴重なコメントと入力を受け取りました。 セクション4の一部がエードリアン・ファレルによって提案された提案とテキストに基づいています。
The security considerations section is based on text provided by Steven Bellovin.
セキュリティ問題部はスティーブンBellovinによって提供されたテキストに基づいています。
Berger Standards Track [Page 32] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[32ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
12. Security Considerations
12. セキュリティ問題
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は保全を基礎づけました、そして、認証は使用できます。 あるいはまた、ホップごとのNotifyメッセージの発信を無能にすることができます。
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.
セレクタ、セレクタは1組の非隣接しているノードの間で交換されたRSVPメッセージによって特定されます。 ノードは内側のIPヘッダーのIPアドレスがNotifyメッセージで使用したソースと目的地によって特定されます。
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.
モードIn、このアプリケーションであり、交通機関は適切な選択です。 伝えられる情報が一般に秘密でないので、暗号化は使用される必要はありません。 AH[RFC2402]か超能力[RFC2406]のどちらかが使用されるかもしれません。 超能力が使用されているなら、かぎ管理交換で断言された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.
Key Management Toは中古の、そして、最もありそうなIKEが[RFC2409]であったなら再生検出、自動化されたかぎ管理システムSHOULDを可能にします。 構成されたキーは使用されるかもしれません。
Security Policy
Messages MUST NOT be accepted except from nodes that are not
known to the recipient to be authorized to make such requests.
そのような要求をするのが認可されるのが受取人にとって知られないノード以外に、セキュリティPolicy Messagesを受け入れてはいけません。
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.
初期の展開と、より小さいネットワークに、識別Sharedキーメカニズムは適切であるべきです。 より大きいスケール展開において、証明書ベースのIKEは支持されるべきです。 いかなる計画も使用されていても、それは何らかのファッションでソースIPアドレスに後部を結ばなければなりません。
Berger Standards Track [Page 33] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[33ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
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.
有用性Manyルータとスイッチは既にIPSECを支持します。 IPSECが入手できなく、セキュリティが必要であるケースにおいて、ホップごとにNotifyメッセージを送らなければなりません。
13. IANA Considerations
13. IANA問題
IANA assigns values to RSVP protocol parameters. Within the current document multiple objects are defined. Each of these objects contain C-Types. This section defines the rules for the assignment of the related C-Type values. This section uses the terminology of BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [BCP26].
IANAはRSVPプロトコルパラメタに値を割り当てます。 現在のドキュメントの中では、複数の物が定義されます。 それぞれのこれらの物はC-タイプを含んでいます。 このセクションは関連するC-タイプ値の課題のために規則を決めます。 このセクションはBCP26の用語「RFCsにIANA問題部に書くためのガイドライン」[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つのカテゴリと定義しました。 最初のカテゴリはLabel物からのCタイプ、すなわち、物のクラス番号16[RFC3209]を引き継ぎます。 IANAがまた値がLabel物のために選任するすべてのC-タイプが以下の物のために選任される方針を設けるよう要求されています:
o Suggested_Label (Class-Num 129)
o Upstream_Label (Class-Num 35)
o Recovery_Label (Class-Num 34)
o 提案された_Label(クラスヌム129)o Upstream_Label(クラスヌム35)o Recovery_Label(クラスヌム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番目のカテゴリは独立している方針に従います。 明確に範囲0x00の[BCP26]に概説された方針に従うC-タイプ値--IETF Consensus動作で0x3Fを割り当てます、範囲00x40の値--First Come First Served、および値として範囲0x60に0x5Fを割り当てます--0x7Fは兵士のUseのために予約されます。 この方針は以下の物に適用されます。
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 ラベル_Set(クラスヌム36)o Notify_Request(クラスヌム195)o Protection(クラスヌム37)o Admin Status(クラスヌム196)o Restart_Cap(クラスヌム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-タイプ値の課題(Acceptable_Label_Set物)はLabel_Set物のC-タイプ値の課題に続きます。 IANAはまたLabel_Set物のために割り当てられたすべてのC-タイプ値がAcceptable_Label_Set物のために割り当てられる方針を設けるでしょう。
Berger Standards Track [Page 34] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[34ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
13.1. IANA Assignments
13.1. IANA課題
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_ホップ(C-ヌム3)--IPv4は_ID RSVP_であるなら(C-タイプ=3)を飛び越します--IPv6は_ID RSVP_であるなら跳びます。(C-タイプ=4)
o ERROR_SPEC (C-Num 6)
- IPv4 IF_ID ERROR_SPEC (C-type = 3)
- IPv6 IF_ID ERROR_SPEC (C-type = 4)
o 誤り_仕様(C-ヌム6)--、IPv4、_ID誤り_仕様(C-タイプ=3)であるなら--IPv6、_ID誤り_仕様です。(C-タイプ=4)
o LABEL_REQUEST (Class-Num 19)
- Generalized_Label_Request (C-Type = 4)
o ラベル_は(クラスヌム19)を要求します--_ラベル_要求を広めます。(C-タイプ=4)
o RSVP_LABEL (Class-Num = 16)
- Generalized_Label (C-Type = 2)
- Waveband_Switching_Label C-Type (C-Type = 3)
o RSVP_ラベル(クラスヌム=16)--一般化された_ラベル(C-タイプ=2)--周波数帯_切り換え_ラベルC-タイプ(C-タイプ=3)
--------------------------------------------------------------------- New Class-Nums, C-Types inherited from Label object (same as CNum16)
--------------------------------------------------------------------- 新しいClass-Nums、Label物から引き継がれたC-タイプ(CNum16と同じこと)
o RECOVERY_LABEL Class-Num of form 0bbbbbbb (= 34) o SUGGESTED_LABEL Class-Num of form 10bbbbbb (= 129) o UPSTREAM_LABEL Class-Num of form 0bbbbbbb (= 35)
o フォーム0bbbbbbbのフォーム10bbbbbb(= 129)○UPSTREAM_LABEL Classヌムのフォーム0bbbbbbb(= 34)○SUGGESTED_LABEL ClassヌムのRECOVERY_LABEL Class-ヌム(= 35)
--------------------------------------------------------------------- New Class-Nums
--------------------------------------------------------------------- 新しいクラス-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 フォーム0bbbbbbb(= 36)のLABEL_SET Class-ヌム--フォーム10bbbbbb(= 130)の1(C-タイプ=1)oのACCEPTABLE_LABEL_SET Class-ヌムをタイプしてください--フォーム11bbbbbb(= 195)の1Acceptable_Label_Set(ラベル_からのC-タイプはcnumを設定します)o NOTIFY_REQUEST Class-ヌムをタイプしてください--IPv4 Notify Request(C-タイプ=1)(IPv6 Notify Request(C-タイプ=2)○ フォーム0bbbbbbbのPROTECTION Class-ヌム(= 37))は1をタイプします。(C-タイプ=1)
Berger Standards Track [Page 35] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[35ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年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 フォーム11bbbbbb(= 196)のADMIN STATUS Class-ヌム--フォーム10bbbbbb(= 131)の1(C-タイプ=1)oのRESTART_CAP Class-ヌムをタイプしてください--1(C-タイプ=1)をタイプしてください。--------------------------------------------------------------------- ERO/RRO subobjectはタイプします。
o Label ERO subobject
Type 3 - Label
o ラベルERO subobject Type3--ラベル
o Label RRO subobject
Type 3 - Label
---------------------------------------------------------------------
Error codes
o ラベルRRO subobject Type3--ラベル--------------------------------------------------------------------- エラーコード
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)
---------------------------------------------------------------------
o ○ 「制御チャンネル誤り/活動的な状態に通知する」(値=4)という「ルート設定問題/ラベルSet」(値の=11)o「ルート設定の問題/切り換えタイプ」(値の=12)(写しコード13は低下した)「ルート設定の問題/サポートされないコード化o(値の=14)」o「ルート設定の問題/サポートされないリンク保護」(値の=15)oは「制御チャンネル誤り/降格している状態に通知する」(値の=5)。---------------------------------------------------------------------
14. Intellectual Property Considerations
14. 知的所有権問題
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はどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を記述してください。
Berger Standards Track [Page 36] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[36ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
15. References
15. 参照
15.1. Normative References
15.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.
R.編(チャン)の[RFC2205]ブレーデン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は議定書を作ります--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF
Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication
Header", RFC 2401, November 1998.
[RFC2402] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2401、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2401, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2401、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key
Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January
2000.
[RFC2747] ベイカーとF.とリンデルとB.とM.Talwar、「RSVPの暗号の認証」、RFC2747、2000年1月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
F. and S. Molendini, "RSVP Refresh Overhead
Reduction Extensions", RFC 2961, April 2001.
[RFC2961]のバーガー、L.、ガン、D.、ツバメ、G.、なべ、P.、トンマージ、F.、およびS.Molendini、「RSVPは全般的な減少拡大をリフレッシュします」、RFC2961、2001年4月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions
to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Functional
Description", RFC 3471, January 2003.
[RFC3471] バーガー、L.、エディタ、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、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)」、RFC3477、2003年1月。
Berger Standards Track [Page 37] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[37ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
15.2. Informative References
15.2. 有益な参照
[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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
MPLS TE", Work in Progress.
「MPLS TeがあるLSP階層構造」という[MPLS-階層構造]のKompella、K.、およびY.Rekhterは進行中で働いています。
[PAN-RESTART] Pan, P., et. al., "Graceful Restart Mechanism for
RSVP-TE", Work in Progress.
[PAN-RESTART] etなべ、P.、アル、「RSVP-Teのための優雅な再開メカニズム」、ProgressのWork。
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
16. Contributors
16. 貢献者
Peter Ashwood-Smith Nortel Networks Corp. P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7 Canada
ピーターAshwood-スミスノーテルは社の私書箱3511駅C、オタワをK1Y 4H7カナダにネットワークでつなぎます。
Phone: +1 613 763 4534 EMail: petera@nortelnetworks.com
以下に電話をしてください。 +1 4534年の613 763メール: petera@nortelnetworks.com
Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose, CA 95138
アヤンバネルジーCalientネットワーク5853はフェラーリサンノゼ、カリフォルニア 95138を悔悟します。
Phone: +1 408 972-3645 EMail: abanerjee@calient.net
以下に電話をしてください。 +1 408 972-3645 メールしてください: abanerjee@calient.net
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
ルウバーガーMovazはInc.7926ジョーンズ支店ドライブスイート615マクリーン・ヴァージニア、22102をネットワークでつなぎます。
Phone: +1 703 847-1801 EMail: lberger@movaz.com
以下に電話をしてください。 +1 703 847-1801 メールしてください: lberger@movaz.com
Berger Standards Track [Page 38] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[38ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
Greg Bernstein EMail: gregb@grotto-networking.com
グレッグバーンスタインEMail: gregb@grotto-networking.com
John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138
ジョンドレイクCalientネットワーク5853はフェラーリサンノゼ、カリフォルニア 95138を悔悟します。
Phone: +1 408 972 3720 EMail: jdrake@calient.net
以下に電話をしてください。 +1 3720年の408 972メール: jdrake@calient.net
Yanhe Fan Axiowave Networks, Inc. 200 Nickerson Road Marlborough, MA 01752
YanheファンAxiowaveはInc.200Nickerson Roadマールバラ、MA 01752をネットワークでつなぎます。
Phone: + 1 774 348 4627 EMail: yfan@axiowave.com
以下に電話をしてください。 4627がメールする+1 774 348: yfan@axiowave.com
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Kireeti Kompella杜松はInc.1194N.マチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア 94089
EMail: kireeti@juniper.net
メール: kireeti@juniper.net
Jonathan P. Lang EMail: jplang@ieee.org
ジョナサンP.ラングメール: jplang@ieee.org
Fong Liaw Solas Research, LLC
フォンLiawソラスResearch、LLC
EMail: fongliaw@yahoo.com
メール: fongliaw@yahoo.com
Berger Standards Track [Page 39] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[39ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
Eric Mannie Independent Consultant 2 Avenue de la Folle Chanson 1050 Brussels Belgium
エリックマニー無党派Consultant2アベニューde la Folle Chanson1050ブリュッセルベルギー
EMail: eric_mannie@hotmail.com
メール: eric_mannie@hotmail.com
Ping Pan Ciena 10480 Ridgeview Court Cupertino, CA 95014
ピングなべCiena10480Ridgeview法廷カルパチーノ、カリフォルニア 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
私書箱901Oceanport、Bala Rajagopalan Tellium Inc.2の三日月形Placeニュージャージー07757-0901
Phone: +1 732 923 4237 Fax: +1 732 923 9804 EMail: braja@tellium.com
以下に電話をしてください。 +1 732 923、4237Fax: +1 9804年の732 923メール: braja@tellium.com
Yakov Rekhter Juniper Networks, Inc.
ヤコフRekhter JuniperはInc.をネットワークでつなぎます。
EMail: yakov@juniper.net
メール: yakov@juniper.net
Debanjan Saha EMail: debanjan@acm.org
DebanjanシャハEMail: debanjan@acm.org
Berger Standards Track [Page 40] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[40ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
Vishal Sharma Metanoia, Inc. 1600 Villa Street, Unit 352 Mountain View, CA 94041-1174
VishalシャルマMetanoia, Inc.1600Villa通り、Unit352マウンテンビュー、カリフォルニア94041-1174
Phone: +1 650-386-6723 EMail: v.sharma@ieee.org
以下に電話をしてください。 +1 650-386-6723 メールしてください: v.sharma@ieee.org
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824
ジョージツバメシスコシステムズInc.250アポロDriveチェルムズフォード、MA 01824
Phone: +1 978 244 8143 EMail: swallow@cisco.com
以下に電話をしてください。 +1 8143年の978 244メール: swallow@cisco.com
Z. Bo Tang EMail: botang01@yahoo.com
Z.棒ピリッとする味メール: botang01@yahoo.com
17. Editor's Address
17. エディタのアドレス
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
ルウバーガーMovazはInc.7926ジョーンズ支店ドライブスイート615マクリーン・ヴァージニア、22102をネットワークでつなぎます。
Phone: +1 703 847-1801 EMail: lberger@movaz.com
以下に電話をしてください。 +1 703 847-1801 メールしてください: lberger@movaz.com
Berger Standards Track [Page 41] RFC 3473 GMPLS Signaling - RSVP-TE Extensions January 2003
バーガー標準化過程[41ページ]RFC3473GMPLSシグナリング--RSVP-Te拡大2003年1月
18. Full Copyright Statement
18. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Berger Standards Track [Page 42]
バーガー標準化過程[42ページ]
一覧
スポンサーリンク
