RFC3472 日本語訳
3472 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP)Extensions. P. Ashwood-Smith, Ed., L. Berger, Ed.. January 2003. (Format: TXT=49006 bytes) (Updated by RFC3468, RFC4201) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Ashwood-Smith, Editor
Request for Comments: 3472 Nortel Networks
Category: Standards Track L. Berger, Editor
Movaz Networks
January 2003
ワーキンググループのP.Ashwood-スミス、コメントを求めるエディタ要求をネットワークでつないでください: 3472 ノーテルはカテゴリをネットワークでつなぎます: 規格は2003年1月にL.バーガー、エディタMovazネットワークを追跡します。
Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions
一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの規制ベースの発送されたラベル分配プロトコル(CR-自由民主党)拡大
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) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. A generic functional description can be found in separate documents.
このドキュメントはシグナリングがGeneralized MPLSを支持するのを必要としたMulti-プロトコルLabel Switching(MPLS)の規制ベースのRouted Label Distributionプロトコル(CR-自由民主党)に拡大について説明します。 一般化されたMPLSは、時間分割(例えば、同期式光通信網と同期デジタルハイアラーキ、Sonet/SDH)、波長(光学λ)、および空間的な切り換え(例えば、出発しているポートかファイバーへの入って来るポートかファイバー)を取り囲むためにMPLS制御飛行機を広げています。 このドキュメントは拡大のCR-自由民主党の明確な記述を提示します。 別々のドキュメントで一般的な機能的な記述を見つけることができます。
Table of Contents
目次
1. Introduction .............................................. 2
2. Label Related Formats .................................... 3
2.1 Generalized Label Request ............................... 3
2.2 Generalized Label ....................................... 4
2.3 Waveband Switching ...................................... 5
2.4 Suggested Label ......................................... 6
2.5 Label Set ............................................... 6
3. Bidirectional LSPs ........................................ 8
3.1 Procedures .............................................. 8
4. Notification on Label Error ............................... 9
5. Explicit Label Control .................................. 9
5.1 Procedures .............................................. 9
1. 序論… 2 2. 関連形式をラベルしてください… 3 2.1はラベル要求を広めました… 3 2.2はラベルを一般化しました… 4 2.3 周波数帯の切り換え… 5 2.4はラベルを示しました… 6 2.5ラベルはセットしました… 6 3. 双方向のLSPs… 8 3.1の手順… 8 4. ラベル誤りに関する通知… 9 5. 明白なラベルコントロール… 9 5.1の手順… 9
Ashwood-Smith & Berger Standards Track [Page 1] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[1ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
6. Protection TLV ............................................ 10
6.1 Procedures .............................................. 11
7. Administrative Status Information ......................... 11
7.1 Admin Status TLV ........................................ 11
7.2 REQUEST and MAPPING Message Procedures .................. 12
7.3 Notification Message Procedures ......................... 13
8. Control Channel Separation ................................ 14
8.1 Interface Identification ................................ 14
8.2 Errored Interface Identification ........................ 15
9. Fault Handling ......................................... 17
10 Acknowledgments ........................................... 17
11. Security Considerations ................................... 17
12. IANA Considerations ....................................... 17
13. Intellectual Property Considerations ...................... 18
14. References ................................................ 18
14.1 Normative References ................................... 18
14.2 Informative References ................................. 19
15. Contributors .............................................. 19
16. Editors' Addresses ........................................ 22
17. Full Copyright Statement ................................... 23
6. 保護TLV… 10 6.1の手順… 11 7. 管理状態情報… 11 7.1 アドミン状態TLV… 11 7.2要求とマッピングメッセージ手順… 12 7.3 通知メッセージ手順… 13 8. チャネルセパレーションを制御してください… 14 8.1 識別を連結してください… 14 8.2はインタフェース識別をErroredしました… 15 9. 欠点取り扱い… 17 10の承認… 17 11. セキュリティ問題… 17 12. IANA問題… 17 13. 知的所有権問題… 18 14. 参照… 18 14.1 標準の参照… 18 14.2 有益な参照… 19 15. 貢献者… 19 16. エディタのアドレス… 22 17. 完全な著作権宣言文… 23
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 CR-LDP specific formats and mechanisms needed to support all four classes of interfaces. RSVP-TE extensions can be found in [RFC3473].
一般化されたMPLSはパケット(PSC)インタフェースを支持して、3つの新しいクラスのインタフェースのサポートを含むように切り替わって、切り替わるのからMPLSを広げています: 時間事業部は(TDM)、λスイッチ(LSC)、およびファイバースイッチ(FSC)を多重送信します。 MPLSシグナリングへの拡大の機能的な記述は、新しいクラスのインタフェースを支持する必要がありました、そして、[RFC3471]に切り換えを提供します。 このドキュメントはCR-自由民主党の特定の形式とすべての4つのクラスのインタフェースを支持するのが必要であるメカニズムを提示します。 [RFC3473]でRSVP-TE拡張子を見つけることができます。
[RFC3471] should be viewed as a companion document to this document. The format of this document parallels [RFC3471]. It should be noted that the RSVP-TE specific version of Generalized MPLS includes RSVP specific support for rapid failure notification, see Section 4 [RFC3473]. For CR-LDP there is not currently a similar mechanism. When a failure is detected it will be propagated with RELEASE/WITHDRAW messages radially outward from the point of failure. Resources are to be released in this phase and actual resource information may be fed back to the source using a feedback mechanisms.
[RFC3471]は仲間ドキュメントとしてこのドキュメントに見なされるべきです。 このドキュメントの形式は[RFC3471]に沿います。 Generalized MPLSのRSVP-TEの特定のバージョンが急速な失敗通知のRSVPの特定のサポートを含んでいることに注意されるべきです、とセクション4[RFC3473]は見ます。 CR-自由民主党のために、現在でないときに、同様のメカニズムがあります。 失敗が検出されるとき、それはRELEASE/WITHDRAWメッセージで失敗のポイントから放射状に外側に伝播されるでしょう。 リソースがこのフェーズで発表することであり、フィードバック・メカニズムを使用することで実際のリソース情報を提供して戻すかもしれません。
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]で説明されるように本書では解釈されることであるべきですか?
Ashwood-Smith & Berger Standards Track [Page 2] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[2ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
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
2.1. 一般化されたラベル要求
A REQUEST message SHOULD contain as specific an LSP (Label Switched Path) Encoding Type as possible to allow the maximum flexibility in switching by transit LSRs. A Generalized Label Request Type, Length, and Value (TLV) is set by the ingress node, transparently passed by transit nodes, and used by the egress node. The Switching Type field may also be updated hop-by-hop.
SHOULDがTypeをコード化するトランジットLSRsで切り替わる際に最大の柔軟性を許容するのにおいてできるだけ特定のLSP(ラベルSwitched Path)を含んでいるというREQUESTメッセージ。 Generalized Label Request Type、Length、およびValue(TLV)はイングレスノードで用意ができて、トランジットノードによって透明に渡されて、出口ノードによって使用されます。 また、ホップごとにSwitching Type分野をアップデートするかもしれません。
The format of a Generalized Label Request 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x0824) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| タイプ(0×0824)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc。 タイプ|切り換えタイプ| G-PID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
パラメタの記述に関して[RFC3471]を見てください。
2.1.1. Procedures
2.1.1. 手順
A node processing a REQUEST message containing a Generalized Label Request must verify that the requested parameters can be satisfied by the incoming interface, the node and by the outgoing interface. The node may either directly support the LSP or it may use a tunnel (FA), i.e., another class of switching. In either case, each parameter must be checked.
Generalized Label Requestを含むREQUESTメッセージを処理するノードは、入って来るインタフェース、ノード、および外向的なインタフェースで要求されたパラメタを満たすことができることを確かめなければなりません。 ノードが直接LSPを支えるかもしれませんか、またはそれはすなわち、トンネル(FA)、もう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 (Explicit Route) hops when using tunnels see [MPLS-HIERARCHY].
ローカルのノード方針が、トンネルがいつ使用されるかもしれないか、そして、それらがいつ作成されるかもしれないかを決めることに注意してください。 ローカルの方針は、トンネルがダイナミックに確立されるのを許容するか、または唯一行政上制御されるかもしれません。 トンネルを使用するとき、ER(明白なRoute)のトンネルと処理の詳しい情報に関しては、ホップは[MPLS-HIERARCHY]を見ます。
Transit and egress nodes MUST verify that the node itself and, where appropriate, that the outgoing interface or tunnel can support the requested LSP Encoding Type. If encoding cannot be supported, the node MUST generate a NOTIFICATION message, with a "Routing problem/Unsupported Encoding" indication.
トランジットと出口ノードはそれについて確かめなければなりません。ノード自体であり、外向的が連結するか、またはトンネルを堀るのが適切であるところで要求されたLSP Encoding Typeを支持できます。 コード化を支持できないなら、ノードは「ルート設定の問題/サポートされないコード化」指示でNOTIFICATIONメッセージを発生させなければなりません。
Ashwood-Smith & Berger Standards Track [Page 3] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[3ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
Nodes MUST verify that the type indicated in the Switching Type parameter is supported on the corresponding incoming interface. If the type cannot be supported, the node MUST generate a NOTIFICATION message with a "Routing problem/Switching Type" indication.
ノードは、Switching Typeパラメタで示されたタイプが対応する入って来るインタフェースで支持されることを確かめなければなりません。 タイプを支持できないなら、ノードは「ルート設定の問題/切り換えタイプ」指示でNOTIFICATIONメッセージを発生させなければなりません。
The G-PID parameter is normally only examined at the egress. If the indicated G-PID cannot be supported then the egress MUST generate a NOTIFICATION message, with a "Routing problem/Unsupported G-PID" indication. In the case of PSC and when penultimate hop popping (PHP) is requested, the penultimate hop also examines the (stored) G-PID during the processing of the MAPPING message. In this case if the G-PID is not supported, then the penultimate hop MUST generate a NOTIFICATION message with a "Routing problem/Unacceptable label value" indication. The generated NOTIFICATION message MAY include an Acceptable Label Set, see Section 4.
通常、G-PIDパラメタは出口で調べられるだけです。 示されたG-PIDを支持できないなら、出口はNOTIFICATIONメッセージを発生させなければなりません、「ルート設定の問題/サポートされないG-PID」指示で。 また、PSCの際と終わりから二番目のホップの飛び出し(PHP)がいつ要求されるかとき、終わりから二番目のホップはMAPPINGメッセージの処理の間、(格納される)のG-PIDを調べます。 この場合、G-PIDが支持されないなら、終わりから二番目のホップは「ルート設定問題/容認できないラベル値」指示でNOTIFICATIONメッセージを発生させなければなりません。 セクション4は、発生しているNOTIFICATIONメッセージがAcceptable Label Setを含むかもしれないのを見ます。
When an error message is not generated, normal processing occurs. In the transit case this will typically result in a REQUEST message being propagated. In the egress case and PHP special case this will typically result in a MAPPING message being generated.
エラーメッセージが発生しないとき、正常処理は起こります。 トランジット場合では、これは伝播されるREQUESTメッセージを通常もたらすでしょう。 出口場合とPHPの特別な場合では、これは発生するMAPPINGメッセージを通常もたらすでしょう。
2.1.2. Bandwidth Encoding
2.1.2. 帯域幅コード化
Bandwidth encodings are carried in the CR-LDP Traffic Parameters TLV. See [RFC3471] for a definition of values to be used for specific signal types. These values are set in the Peak and Committed Data Rate fields of the Traffic Parameters TLV. Other bandwidth/service related parameters in the TLV are ignored and carried transparently.
帯域幅encodingsはCR-自由民主党Traffic Parameters TLVで運ばれます。 [RFC3471]を見て、値の定義は特定の信号タイプに使用されてください。 これらの値はTraffic Parameters TLVのPeakとCommitted Data Rate分野に設定されます。 TLVのサービス他の帯域幅/関連するパラメタは、透明に無視されて、運ばれます。
2.2. Generalized Label
2.2. 一般化されたラベル
The format of a Generalized Label 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x0825) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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|F| タイプ(0×0825)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ラベル| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters and encoding of labels.
パラメタの記述とラベルのコード化に関して[RFC3471]を見てください。
Ashwood-Smith & Berger Standards Track [Page 4] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[4ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
2.2.1. Procedures
2.2.1. 手順
The Generalized Label travels in the upstream direction in MAPPING messages.
Generalized LabelはMAPPINGメッセージの上流の方向に旅行します。
The presence of both a generalized and normal label TLV in a MAPPING message is a protocol error and should treated as a malformed message by the recipient.
MAPPINGメッセージでの一般化されて正常なラベルTLVの存在は、プロトコル誤りであり、受取人によって奇形のメッセージとして扱われて、誤りであるべきです。
The recipient of a MAPPING message containing a Generalized Label verifies that the values passed are acceptable. If the label is unacceptable then the recipient MUST generate a NOTIFICATION message with a "Routing problem/MPLS label allocation failure" indication. The generated NOTIFICATION message MAY include an Acceptable Label Set, see Section 4.
Generalized Labelを含むMAPPINGメッセージの受取人は、通過された値が許容できることを確かめます。 ラベルが容認できないなら、受取人は「ルート設定問題/MPLSラベル割り振りの失敗」指示でNOTIFICATIONメッセージを発生させなければなりません。 セクション4は、発生しているNOTIFICATIONメッセージがAcceptable Label Setを含むかもしれないのを見ます。
2.3. Waveband Switching
2.3. 周波数帯の切り換え
Waveband switching uses the same format as the generalized label, see section 2.2. The type 0x0828 is assigned for the Waveband Label.
セクション2.2は、周波数帯の切り換えが一般化されたラベルと同じ形式を使用するのを見ます。 タイプ0x0828はWaveband Labelのために選任されます。
In the context of waveband switching, the generalized label has the following format:
周波数帯の切り換えの文脈では、一般化されたラベルは以下の形式を持っています:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x0828) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waveband Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| タイプ(0×0828)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 周波数帯イド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | スタートラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 終わりのラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
パラメタの記述に関して[RFC3471]を見てください。
2.3.1. Procedures
2.3.1. 手順
The procedures defined in Section 2.2.1 apply to waveband switching. This includes generating a NOTIFICATION message with a "Routing problem/MPLS label allocation failure" indication if any of the label fields are unrecognized or unacceptable.
セクション2.2.1で定義された手順は周波数帯の切り換えに適用されます。 これは、ラベルフィールドのどれかが認識されていないか、または容認できないなら「ルート設定問題/MPLSラベル割り振りの失敗」指示でNOTIFICATIONメッセージを発生させるのを含んでいます。
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,
周波数帯が別の周波数帯に切り換えられるとき、さらに、周波数帯の中の波長が中心周波数に関して反映されるのは、可能です。 このタイプの切り換えが採用しているとき
Ashwood-Smith & Berger Standards Track [Page 5] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[5ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
the start and end label in the waveband label TLV MUST be swapped before forwarding the label TLV with the new waveband Id. In this manner an egress/ingress LSR that receives a waveband label which has these values inverted, knows that it must also invert its egress association to pick up the proper wavelengths. Without this mechanism and with an odd number of mirrored switching operations, the egress LSRs will not know that an input wavelength of say L1 will emerge from the waveband tunnel as L100.
始めと終わりがラベルする、周波数帯ラベルTLV MUSTでは、ラベルTLVを進める前に、新しい周波数帯アイダホ州と共に交換されてください。 この様に、これらの値を逆にする周波数帯ラベルを受けて、また、そうしなければならないのを知っている出口/イングレスLSRは適切な波長を拾う出口協会を逆にします。 このメカニズムなしで映された切り換え操作の奇数で、出口LSRsは、言いたい事L1の入力波長がL100として周波数帯トンネルから現れるのを知らないでしょう。
This operation MUST be performed in both directions when a bidirectional waveband tunnel is being established.
双方向の周波数帯トンネルが確立されているとき、両方の方向にこの操作を実行しなければなりません。
2.4. Suggested Label
2.4. 提案されたラベル
The format of a suggested label is identical to a generalized label. It is used in REQUEST messages. Suggested Label uses type = 0x904.
提案されたラベルの形式は一般化されたラベルと同じです。 それはREQUESTメッセージで使用されます。 提案されたLabelはタイプ=0x904を使用します。
Errors in received Suggested Labels MUST be ignored. This includes any received inconsistent or unacceptable values.
容認されたSuggested Labelsの誤りを無視しなければなりません。 これはどんな容認された矛盾したか容認できない値も含んでいます。
Per [RFC3471], if a downstream node passes a label value that differs from the suggested label upstream, the upstream LSR MUST either reconfigure itself so that it uses the label specified by the downstream node or generate a NOTIFICATION message with a "Routing problem/Unacceptable label value" indication. Furthermore, an ingress node SHOULD NOT transmit data traffic using a suggested label until the downstream node passes corresponding a label upstream.
[RFC3471]に従って、川下のノードが提案されたラベル上流と異なっているラベル値を通過するなら、上流のLSR MUSTは川下のノードによって指定されたラベルを使用するようにそれ自体を再構成するか、または「ルート設定問題/容認できないラベル値」指示でNOTIFICATIONメッセージを発生させます。 その上、イングレスノードSHOULD NOTは、川下のノードがラベル上流を対応に通り過ぎるまで提案されたラベルを使用することでデータ通信量を伝えます。
2.5. Label Set
2.5. ラベル・セット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x0827) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| タイプ(0×0827)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 動作| 予約されます。| ラベル形式| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブチャネル1| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブチャネルN| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ashwood-Smith & Berger Standards Track [Page 6] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[6ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
Label Type: 14 bits
タイプにレッテルを貼ってください: 14ビット
Indicates the type and format of the labels carried in the TLV.
Values match the TLV type of the appropriate Label TLV.
ラベルのタイプと形式がTLVで運ばれたのを示します。 値は適切なLabel TLVのTLVタイプに合っています。
See [RFC3471] for a description of other parameters.
他のパラメタの記述に関して[RFC3471]を見てください。
2.5.1. Procedures
2.5.1. 手順
A Label Set is defined via one or more Label Set TLVs. Specific labels/subchannels can be added to or excluded from a Label Set via Action zero (0) and one (1) TLVs respectively. Ranges of labels/subchannels can be added to or excluded from a Label Set via Action two (2) and three (3) TLVs respectively. When the Label Set TLVs only list labels/subchannels to exclude, this implies that all other labels are acceptable.
Label Setは1Label Set TLVsを通して定義されます。 特定のラベル/サブチャネルは、(0)と1(1)TLVsをそれぞれ加えるか、またはActionゼロを通したLabel Setから除くことができます。 ラベル/サブチャネルの範囲は、(2)と3(3)TLVsをそれぞれ加えるか、またはAction twoを通したLabel Setから除くことができます。 Label Set TLVsが除くラベル/サブチャネルを記載するだけであるとき、これは、他のすべてのラベルが許容できるのを含意します。
The absence of any Label Set TLVs implies that all labels are acceptable. A Label Set is included when a node wishes to restrict the label(s) that may be used downstream.
どんなLabel Set TLVsの不在も、すべてのラベルが許容できるのを含意します。 ノードが川下で使用されるかもしれないラベルを制限したがっているとき、Label Setは含まれています。
On reception of a REQUEST message, the receiving node will restrict its choice of labels to one, which is in the Label Set. Nodes capable of performing label conversion may also remove the Label Set prior to forwarding the REQUEST message. If the node is unable to pick a label from the Label Set or if there is a problem parsing the Label Set TLVs, then the request is terminated and a NOTIFICATION message with a "Routing problem/Label Set" indication MUST be generated. It is a local matter if the Label Set is stored for later selection on the MAPPING message or if the selection is made immediately for propagation in the MAPPING message.
REQUESTメッセージのレセプションでは、受信ノードはラベルの選択をものに制限するでしょう。(それは、Label Setにあります)。 また、REQUESTメッセージを転送する前に、ラベル変換を実行できるノードはLabel Setを取り外すかもしれません。 ノードがLabel Setからラベルを選ぶことができないか、またはLabel Set TLVsを分析することにおける問題があれば、要求は終えられます、そして、「ルート設定問題/ラベル・セット」指示があるNOTIFICATIONメッセージは発生しなければなりません。 後の選択のためにMAPPINGメッセージにLabel Setを格納するかどうか、またはすぐMAPPINGメッセージにおける伝播のために選択をするかどうかが、地域にかかわる事柄です。
On reception of a REQUEST message, the Label Set represented in the message is compared against the set of available labels at the downstream interface and the resulting intersecting Label Set is forwarded in a REQUEST message. When the resulting Label Set is empty, the REQUEST must be terminated, and a NOTIFICATION message, and a "Routing problem/Label Set" indication MUST be generated. Note that intersection is based on the physical labels (actual wavelength/band values) which may have different logical values on different links, as a result it is the responsibility of the node to map these values so that they have a consistent physical meaning, or to drop the particular values from the set if no suitable logical label value exists.
REQUESTメッセージのレセプションでは、川下のインタフェースで利用可能なラベルのセットに対してメッセージに表されたLabel Setを比較します、そして、REQUESTメッセージで結果として起こる交差Label Setを送ります。 結果として起こるLabel Setが空であるときに、REQUESTは終えられてNOTIFICATIONメッセージであるに違いありません、そして、「ルート設定問題/ラベル・セット」指示は発生しなければなりません。 交差点が異なったリンクの上に異なった論理的な値を持っているかもしれない物理的なラベル(実際の波長/バンド値)に基づいていることに注意してください、それらには、一貫した物理的な意味がその結果、これらの値を写像するのが、ノードの責任であるので、あるか、またはセットから特定の値を落とすために、値は適当な論理的なラベルでないなら存在しています。
When processing a MAPPING message at an intermediate node, the label propagated upstream MUST fall within the Label Set.
中間的ノードでMAPPINGメッセージを処理するとき、上流へ伝播されたラベルはLabel Setの中に落ちなければなりません。
Ashwood-Smith & Berger Standards Track [Page 7] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[7ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
Note, on reception of a MAPPING message a node that is incapable of performing label conversion has no other choice than to use the same physical label (wavelength/band) as received in the MAPPING message. In this case, the use and propagation of a Label Set will significantly reduce the chances that this allocation will fail.
MAPPINGメッセージのレセプションでラベル変換を実行できないノードがMAPPINGメッセージに受け取られるのと同じ物理的なラベル(波長/バンド)使用するほど他の選択を全く持っていないことに注意してください。 この場合、Label Setの使用と伝播はこの配分が失敗するという可能性をかなり小さくするでしょう。
3. Bidirectional LSPs
3. 双方向のLSPs
Bidirectional LSP setup is indicated by the presence of an Upstream Label in the REQUEST message. An Upstream Label has the same format as the generalized label, see Section 2.2. Upstream Label uses type = 0x0826.
双方向のLSPセットアップはREQUESTメッセージでのUpstream Labelの存在によって示されます。 セクション2.2は、Upstream Labelには一般化されたラベルと同じ形式があるのを見ます。 上流のLabelはタイプ=0x0826を使用します。
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 is added to the REQUEST message. The Upstream Label MUST indicate a label that is valid for forwarding at the time the REQUEST message is sent.
双方向のLSPを設立する過程はいくつかの追加による単方向LSPの設立に続きます。 双方向のLSPsを支持するために、Upstream LabelはREQUESTメッセージに追加されます。 Upstream LabelはREQUESTメッセージを送るとき推進に、有効なラベルを示さなければなりません。
When a REQUEST message containing an Upstream Label is received, the receiver first verifies that the upstream label is acceptable. If the label is not acceptable, the receiver MUST issue a NOTIFICATION message with a "Routing problem/Unacceptable label value" indication. The generated NOTIFICATION message MAY include an Acceptable Label Set, see Section 4.
Upstream Labelを含むREQUESTメッセージが受信されているとき、受信機は、最初に、上流のラベルが許容できることを確かめます。 ラベルが許容できないなら、受信機は「ルート設定問題/容認できないラベル値」指示でNOTIFICATIONメッセージを発行しなければなりません。 セクション4は、発生しているNOTIFICATIONメッセージが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 REQUEST message. If an intermediate node is unable to allocate a label or internal resources, then it MUST issue a NOTIFICATION message with a "Routing problem/Label allocation failure" indication.
中間的ノードは、また、外向的なインタフェースにラベルを割り当てて、出発しているUpstream Labelに記入して、REQUESTメッセージを伝播する前に、内部のデータ経路を確立しなければなりません。 中間的ノードがラベルか社内資源を割り当てることができないなら、それは「ルート設定問題/ラベル割り振りの失敗」指示でNOTIFICATIONメッセージを発行しなければなりません。
Terminator nodes process REQUEST messages as usual, with the exception that the upstream label can immediately be used to transport data traffic associated with the LSP upstream towards the initiator.
ターミネーターノードはすぐにLSP上流に関連しているデータ通信量を創始者に向かって輸送するのに上流のラベルを使用できるという例外による通常通りのREQUESTメッセージを処理します。
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が取り外されるとき、上流の、そして、川下の両方のラベルは無効にされます、そして、データを送るのは、もう関連ラベルを使用することで有効ではありません。
Ashwood-Smith & Berger Standards Track [Page 8] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[8ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
4. Notification on Label Error
4. ラベル誤りに関する通知
This section defines the Acceptable Label Set TLV to support Notification on Label Error per [RFC3471]. An Acceptable Label Set TLV uses a type value of 0x082a. The remaining contents of the TLV have the identical format as the Label Set TLV, see Section 2.5.
このセクションは、[RFC3471]あたりのLabel Errorの上のNotificationを支持するためにAcceptable Label Set TLVを定義します。 Acceptable Label Set TLVは0x082aのタイプ値を使用します。 セクション2.5は、TLVの残っている内容にはLabel Set TLVとして同じ形式があるのを見ます。
Acceptable Label Set TLVs may be carried in NOTIFICATION messages. The procedures for defining an Acceptable Label Set follow the procedures for defining a Label Set, see Section 2.5.1. Specifically, an Acceptable Label Set is defined via one or more Acceptable Label Set TLVs. Specific labels/subchannels can be added to or excluded from an Acceptable Label Set via Action zero (0) and one (1) TLVs respectively. Ranges of labels/subchannels can be added to or excluded from an Acceptable Label Set via Action two (2) and three (3) TLVs respectively. When the Acceptable Label Set TLVs only list labels/subchannels to exclude, this implies that all other labels are acceptable.
許容できるLabel Set TLVsはNOTIFICATIONメッセージで運ばれるかもしれません。 セクション2.5.1は、Acceptable Label Setを定義するための手順がLabel Setを定義するために手順に従うのを見ます。 明確に、Acceptable Label Setは1Acceptable Label Set TLVsを通して定義されます。 特定のラベル/サブチャネルは、(0)と1(1)TLVsをそれぞれ加えるか、またはActionゼロを通したAcceptable Label Setから除くことができます。 ラベル/サブチャネルの範囲は、(2)と3(3)TLVsをそれぞれ加えるか、またはAction twoを通したAcceptable Label Setから除くことができます。 Acceptable Label Set TLVsが除くラベル/サブチャネルを記載するだけであるとき、これは、他のすべてのラベルが許容できるのを含意します。
The inclusion of Acceptable Label Set TLVs is optional. If included, the NOTIFICATION message SHOULD contain a "Routing problem/Unacceptable label value" indication. The absence of Acceptable Label Set TLVs does not have any specific meaning.
Acceptable Label Set TLVsの包含は任意です。 含まれているなら、NOTIFICATIONメッセージSHOULDは「ルート設定問題/容認できないラベル値」指示を含んでいます。 Acceptable Label Set TLVsの不在には、少しの特定の意味もありません。
5. Explicit Label Control
5. 明白なラベルコントロール
The Label ER-Hop TLV is defined as follows:
Label ER-ホップTLVは以下の通り定義されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type (0x0829) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|U| Reserved | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label (continued) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| タイプ(0×0829)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L|U| 予約されます。| ラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ラベル(続けられています)| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of L, U and Label parameters.
L、U、およびLabelパラメタの記述に関して[RFC3471]を見てください。
5.1. Procedures
5.1. 手順
The Label ER-Hop follows a ER-Hop containing the IP address, or the interface identifier [MPLS-UNNUM], associated with the link on which it is to be used. Up to two label ER-Hops may be present, one for the downstream label and one for the upstream label. The following SHOULD result in "Bad EXPLICIT_ROUTE" errors:
IPアドレス、またはインタフェース識別子[MPLS-UNNUM]を含んでいて、Label ER-ホップはER-ホップに続きます、それが使用されていることになっているリンクに関連しています。 最大2つのラベルER-ホップが、プレゼントと、川下のラベルのためのものと上流のラベルのためのものであるかもしれません。 以下のSHOULDは「悪い明白な_ルート」誤りをもたらします:
Ashwood-Smith & Berger Standards Track [Page 9] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[9ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
o If the first label ER-Hop is not preceded by a ER-Hop containing
an IP address, or a interface identifier [MPLS-UNNUM], associated
with an output link.
o For a label ER-Hop to follow a ER-Hop that has the L-bit set.
o On unidirectional LSP setup, for there to be a label ER-Hop with
the U-bit set.
o For there to be two label ER-Hops with the same U-bit values.
o IPアドレスを含んでいて、ER-ホップが最初のラベルER-ホップに先行しないか、そして、インタフェース識別子[MPLS-UNNUM]が同じU-ビット値で. o For2ラベルになるようにU-ビットセットo Forと共にL-ビットセットo On単方向LSPがラベルER-ホップであることをそこにセットアップするER-ホップにそこに続くラベルER-ホップER-ホップスを出力リンクに関連づけました。
To support the label ER-Hop, a node must check to see if the ER-Hop following its associate address/interface is a label ER-Hop. If it is, one ER-Hop is examined for unidirectional LSPs and two ER-Hops for bidirectional LSPs. If the U-bit of the ER-Hop being examined is clear (0), then value of the label is copied into a new Label Set TLV. This Label Set TLV MUST be included on the corresponding outgoing REQUEST message.
ラベルER-ホップを支持するなら、ノードは、副アドレス/インタフェースに続くER-ホップがラベルER-ホップであるかどうか確認するためにチェックしなければなりません。 それがそうなら、1つのER-ホップが双方向のLSPsのために単方向LSPsと2つのER-ホップがないかどうか調べられます。 調べられるER-ホップのU-ビットが明確な(0)であるなら、ラベルの値は新しいLabel Set TLVにコピーされます。 対応する送信するREQUESTメッセージにこのLabel Set TLVを含まなければなりません。
If the U-bit of the ER-Hop being examined is set (1), then value of the label is label to be used for upstream traffic associated with the bidirectional LSP. If this label is not acceptable, a "Bad EXPLICIT_ROUTE" error SHOULD be generated. If the label is acceptable, the label is copied into a new Upstream Label TLV. This Upstream Label TLV MUST be included on the corresponding outgoing REQUEST message.
調べられるER-ホップのU-ビットがセット(1)であるなら、ラベルの値は双方向のLSPに関連している上流の交通に使用されるべきラベルです。 このラベルが許容できるa「悪い明白な_ルート」誤りSHOULDでないなら、発生してください。 ラベルが許容できるなら、ラベルは新しいUpstream Label TLVにコピーされます。 対応する送信するREQUESTメッセージにこのUpstream Label TLVを含まなければなりません。
After processing, the label ER-Hops are removed from the ER.
処理の後に、ERからラベルER-ホップを取り除きます。
Note an implication of the above procedures is that the label ER-Hop should never be the first ER-Hop in a newly received message. If the label ER-Hop is the first ER-Hop an a received ER, then it SHOULD be treated as a "Bad strict node" error.
上の手順の含意がラベルER-ホップが新たに受け取られたメッセージで決して最初のER-ホップであるべきでないということであることに注意してください。 ラベルER-ホップがそうである、最初のER-ホップ、aはERを受けて、次に、それはSHOULD aとして扱われた「悪い厳しいノード」誤りです。
Procedures by which an LSR at the head-end of an LSP obtains the information needed to construct the Label ER-Hop are outside the scope of this document.
このドキュメントの範囲の外にLSPのギヤエンドのLSRがLabel ER-ホップを組み立てるのに必要である情報を得る手順があります。
6. Protection TLV
6. 保護TLV
The use of the Protection TLV is optional. The TLV is included to indicate specific protection attributes of an LSP.
Protection TLVの使用は任意です。 TLVは、LSPの特異的予防属性を示すために含まれています。
The format of Protection Information TLV is:
Protection情報TLVの形式は以下の通りです。
Ashwood-Smith & Berger Standards Track [Page 10] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[10ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x0835) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| タイプ(0×0835)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| 予約されます。| リンク旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
パラメタの記述に関して[RFC3471]を見てください。
6.1. Procedures
6.1. 手順
Transit nodes processing a REQUEST message containing a Protection TLV MUST verify that the requested protection can be satisfied by the outgoing interface or tunnel (FA). If it cannot, the node MUST generate a NOTIFICATION message, with a "Routing problem/Unsupported Link Protection" indication.
Protection TLVを含むREQUESTメッセージを処理するトランジットノードは、外向的なインタフェースかトンネル(FA)で要求された保護を満たすことができることを確かめなければなりません。 そうすることができないなら、ノードは「ルート設定の問題/サポートされないリンク保護」指示でNOTIFICATIONメッセージを発生させなければなりません。
7. Administrative Status Information
7. 管理状態情報
Administrative Status Information is carried in the Admin Status TLV. The TLV provides information related to the administrative state of a particular LSP. The information is used in two ways. In the first, the TLV is carried in REQUEST and MAPPING messages to indicate the administrative state of an LSP. In the second, the TLV is carried in Notification message to request a change to the administrative state of an LSP.
管理Status情報はAdmin Status TLVで運ばれます。 TLVは特定のLSPの管理州に関連する情報を提供します。 情報は2つの方法で使用されます。 1番目では、TLVはREQUESTとLSPの管理州を示すMAPPINGメッセージで運ばれます。 2番目では、TLVはLSPの管理州への変化を要求するNotificationメッセージで運ばれます。
7.1. Admin Status TLV
7.1. アドミン状態TLV
The use of the Admin Status TLV is optional. It uses Type = 0x082b. The format of the TLV is:
Admin Status TLVの使用は任意です。 それはType=0x082bを使用します。 TLVの形式は以下の通りです。
The format of Admin Status TLV in REQUEST, MAPPING and Notification Messages is:
REQUEST、MAPPING、およびNotification MessagesのAdmin Status TLVの形式は以下の通りです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x082b) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| (0x082b)をタイプしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| 予約されます。|T|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
パラメタの記述に関して[RFC3471]を見てください。
Ashwood-Smith & Berger Standards Track [Page 11] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[11ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
7.2. REQUEST and MAPPING Message Procedures
7.2. 要求とメッセージ手順を写像すること。
The Admin Status TLV is used to notify each node along the path of the status of the LSP. Each node processes status information based on local policy and then propagated in the corresponding outgoing messages. The TLV is inserted in REQUEST messages at the discretion of the ingress node. The absence of the TLV is the equivalent to receiving a TLV containing values all set to zero.
Admin Status TLVは、LSPの状態の経路に沿った各ノードに通知するのに使用されます。 各ノードはローカルの方針に基づいていて、次に対応する送信されるメッセージで伝播された状態情報を処理します。 TLVはイングレスノードの裁量でREQUESTメッセージに挿入されます。 TLVの不在はすべてがゼロに設定する値を含むTLVを受けるのと同等物です。
Transit nodes receiving a REQUEST message containing an Admin Status TLV, update their local state, take any appropriate local action based on the indicated status and then propagate the received Admin Status TLV in the outgoing REQUEST message.
トランジットノードがAdmin Status TLVを含むREQUESTメッセージを受け取って、地元の状態をアップデートしてください、そして、示された状態に基づくあらゆる適切な地方の行動を取ってください、そして、次に、送信するREQUESTメッセージで容認されたAdmin Status TLVを伝播してください。
Edge nodes receiving a REQUEST message containing an Admin Status TLV, also update their local state and take any appropriate local action based on the indicated status. When the ADMIN Status TLV is received with the R bit set, the receiving edge node should reflect the received values in a corresponding MAPPING message. Specifically, if an egress node receives a Request message with the R bit of the Admin_Status TLV set and the node the node SHOULD send a Mapping message containing an Admin_Status TLV with the same values set, with the exception of the R bit, as received in the corresponding Request message.
Admin Status TLVを含むREQUESTメッセージを受け取って、ノードを斜めに進ませてください、そして、また、地元の状態をアップデートしてください、そして、示された状態に基づくあらゆる適切な地方の行動を取ってください。 Rビットがセットした状態でADMIN Status TLVを受け取るとき、受信縁のノードは対応するMAPPINGメッセージに容認された値を反映するはずです。 明確に、出口ノードがStatus TLVが設定するAdmin_のRビットとノードSHOULDがMappingメッセージに含ませるノードでRequestメッセージを受け取るなら、同じ値があるAdmin_Status TLVはセットしました、Rビットを除いて、対応するRequestメッセージに受け取るように。
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.
いくつかの事情、特に光学のネットワークでは、それを取りこわす前にLSPの管理状態を設定するのは役に立ちます。
In such circumstances the procedure SHOULD be followed when deleting an LSP from the ingress:
そのような事情の手順SHOULD、イングレスからLSPを削除するときには、続かれてください:
o The ingress node precedes an LSP deletion by inserting an Admin
Status TLV in a Notification Message setting the Reflect (R) and
Delete (D) bits.
o Admin Status TLVを挿入することによって、イングレスノードはReflect(R)とDelete(D)ビットを設定しながら、Notification MessageでLSP削除に先行します。
o Transit nodes process the Admin Status TLV by passing the
Notification message. The egress node May respond with a
Notification message with the Admin Status TLV.
o トランジットノードは、Notificationメッセージを通過することによって、Admin Status TLVを処理します。 5月がAdmin Status TLVと共にNotificationメッセージで反応させる出口ノード。
o Upon receiving the Admin Status TLV with the Delete (D) bit set
in the Notification message, the egress SHOULD respond with a
LABEL WITHDRAW message and normal CR-LDP processing takes place.
o Notificationメッセージに設定されたDelete(D)ビットでAdmin Status TLVを受けると、出口SHOULDはLABEL WITHDRAWメッセージで応じます、そして、通常のCR-自由民主党の処理は行われます。
In such circumstances the procedure SHOULD be followed when deleting an LSP from the egress:
そのような事情の手順SHOULD、出口からLSPを削除するときには、続かれてください:
Ashwood-Smith & Berger Standards Track [Page 12] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[12ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
o The egress node indicates its desire for deletion by inserting an
Admin Status TLV in a Notification message and setting Delete (D)
bit.
o 出口ノードは、Notificationメッセージと設定Delete(D)ビットにAdmin Status TLVを挿入することによって、削除に関する願望を示します。
o Transit nodes process the Admin Status TLV as described above.
o トランジットノードは上で説明されるようにAdmin Status TLVを処理します。
o Upon receiving the Admin Status TLV with the Delete (D) bit set
in the Notification message, the ingress node sends a LABEL
RELEASE message downstream to remove the LSP and normal CR-LDP
processing takes place.
o Notificationメッセージに設定されたDelete(D)ビットでAdmin Status TLVを受けると、イングレスノードはLSPを取り外すためにLABEL RELEASEメッセージを川下に送ります、そして、通常のCR-自由民主党の処理は行われます。
7.3. Notification Message Procedures
7.3. 通知メッセージ手順
Subsequent messaging Admin Status messaging may be performed by Notification Messages. The ingress may begin the propagation of a Notification Message with an Admin Status TLV. Each subsequent node propagates the Notification with the Admin Status TLV from the ingress to the egress and then the egress node returns the Notification messages back Upstream carrying the Admin Status TLV.
その後のメッセージングAdmin StatusメッセージングはNotification Messagesによって実行されるかもしれません。 イングレスはAdmin Status TLVとのNotification Messageの伝播を始めるかもしれません。 それぞれのその後のノードはAdmin Status TLVと共にNotificationをイングレスから出口まで伝播します、そして、次に、出口ノードはAdmin Status TLVを運びながら、逆UpstreamをNotificationメッセージに返します。
Intermediate and egress nodes may trigger the setting of administrative status via the use of Notification messages. To accomplish this, an intermediate or egress node generates a Notification message with the corresponding upstream notify session information. The Admin Status TLV MUST be included in the session information, with the appropriate bit or bits set. The Reflect (R) bit MUST NOT be set.
中間介在物と出口ノードはNotificationメッセージの使用で管理状態の設定の引き金となるかもしれません。 これを達成するために、中間介在物か出口ノードが上流がセッション情報に通知する対応でNotificationメッセージを発生させます。 セッション情報に適切なビットでAdmin Status TLVを含まなければならない、さもなければ、ビットはセットしました。 Reflect(R)ビットを設定してはいけません。
An ingress or egress node receiving a Notification message containing an Admin Status TLV with the Delete (D) bit set, SHOULD initiate the deletion procedure described in the previous section.
Delete(D)ビットでAdmin Status TLVを含むNotificationメッセージを受け取るイングレスか出口ノードがセットして、SHOULDは前項で説明された削除手順に着手します。
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 TLV and other error conditions. Specifically, a node that sends a Notification message containing an Admin Status TLV with the Down (D) bit set MUST verify that it receives a corresponding LABEL RELEASE message within a configurable period of time. By default this period of time SHOULD be 30 seconds. If the node does not receive such a LABEL RELEASE message, it SHOULD send a Label Release message downstream and a LABEL WITHDRAW message upstream.
何らかの特別な処理が、Admin Status TLVを支えないノードと他のエラー条件に関するケースをカバーするのに必要です。 明確に、Down(D)ビットがセットした状態でAdmin Status TLVを含むNotificationメッセージを送るノードは、構成可能な期間以内に対応するLABEL RELEASEメッセージを受け取ることを確かめなければなりません。 デフォルトで、この期間SHOULD、30秒になってください。 ノードがそうしないなら、そのようなLABEL RELEASEメッセージを受け取ってください、それ。SHOULDはLabel Releaseメッセージ川下とLABEL WITHDRAWメッセージ上流を送ります。
Ashwood-Smith & Berger Standards Track [Page 13] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[13ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
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 REQUEST message. The choice of the data interface is indicated by the sender of the REQUEST message by including the data channel's interface identifier in the message using a new Interface TLV type. For bidirectional LSPs, the sender chooses the data interface in each direction. In all cases but bundling, the upstream interface is implied by the downstream interface. For bundling, the REQUEST sender explicitly identifies the component interface used in each direction.
使用するデータインタフェースの選択はいつもREQUESTメッセージの送付者によってされます。 データインタフェースの選択は、メッセージに新しいInterface TLVタイプを使用することでデータ・チャンネルのインタフェース識別子を含んでいることによって、REQUESTメッセージの送付者によって示されます。 双方向のLSPsのために、送付者は各方向にデータインタフェースを選びます。 すべてのケースにもかかわらず、バンドリングでは、上流のインタフェースは川下のインタフェースによって含意されます。 バンドリングのために、REQUEST送付者は明らかに各方向に使用されるコンポーネントインタフェースを特定します。
8.1.1. Interface ID TLV
8.1.1. インタフェースID TLV
The format of IPV4 Interface ID in REQUEST, MAPPING Messages is:
REQUESTのIPV4 Interface IDの形式であり、MAPPING Messagesは以下の通りです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x082d) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID TLVS see [RFC3471] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| (0x082d)をタイプしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4次/の前のホップアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 論理的なインタフェースID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェースID TLVSは[RFC3471]を見ます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of IPV6 Interface ID TLV in REQUEST, MAPPING Messages is:
REQUESTのIPV6 Interface ID TLVの形式であり、MAPPING Messagesは以下の通りです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x082e) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID TLVS see [RFC3471] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| (0x082e)をタイプしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6次/の前のホップアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 論理的なインタフェースID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェースID TLVSは[RFC3471]を見ます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ashwood-Smith & Berger Standards Track [Page 14] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[14ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
See [RFC3471] for a description of parameters.
パラメタの記述に関して[RFC3471]を見てください。
See [RFC3212] for a description of signaling address. See [RFC3471] for a description of parameters and encoding of TLVs.
シグナリングアドレスの記述に関して[RFC3212]を見てください。 パラメタの記述とTLVsのコード化に関して[RFC3471]を見てください。
8.1.2. Procedures
8.1.2. 手順
An IF_ID TLV is used on links where there is not a one-to-one association of a control channel to a data channel, see [RFC3471].
_ID TLVがデータ・チャンネルの制御チャンネルの1〜1つの協会がないリンクの上に使用されるなら、[RFC3471]を見てください。
The LDP session uses the IF_ID TLV to identify the data channel(s) associated with the LSP. For a unidirectional LSP, a downstream data channel MUST be indicated. For bidirectional LSPs, a common downstream and upstream data channel is normally indicated. In the special case where a bidirectional LSP that traverses a bundled link, it is possible to specify a downstream data channel that differs from the upstream data channel. Data channels are specified from the viewpoint of the sender of a REQUEST message. The IF_ID TLV SHOULD NOT be used when no TLVs are needed.
自由民主党のセッションが使用する、_データ・チャンネルを特定するID TLVがLSPと交際したなら。 LSP、川下のデータ・チャンネルがそうしなければならない単方向、示されてください。 双方向のLSPsに関しては、通常、川下で一般的で上流のデータ・チャンネルは示されます。 束ねられたリンクを横断する双方向のLSPであり川下を指定するのが可能であるデータが向ける特別な場合では、それは上流のデータ・チャンネルと異なっています。 データ・チャンネルはREQUESTメッセージの送付者の観点から指定されます。 TLVsは全く必要でないときに、_ID TLV SHOULD NOTであるなら、使用されてください。
A node receiving one or more IF_ID TLVs in a REQUEST message saves their values and returns them in the subsequent MAPPING message sent to the node that originated the TLVs.
_REQUESTメッセージのID TLVsがその後のMAPPINGメッセージで彼らの値を節約して、それらを返すなら1つか以上を受けるノードはTLVsを溯源したノードに発信しました。
Note, the node originating an IF_ID TLV MUST ensure that the selected outgoing interface, as specified in the IF_ID TLV, is consistent with an ERO. A node that receives an IF_ID TLV SHOULD check whether the information carried in this TLV is consistent with the information carried in a received ERO, and if not it MUST send a LABEL ABORT Message with the error code "Routing Error" and error value of "Bad Explicit Routing TLV Error" toward the sender. This check CANNOT be performed when the initial ERO subobject is not the incoming interface.
ノードが由来して、注意する、_ID TLV MUSTが選択された外向的な同じくらいインタフェースであって、中で同じくらい指定されていた状態でそれを確実にする、_ID TLVがEROと一致しているなら。 受信するノード、_ID TLV SHOULDが、情報が運び込んだかどうかチェックするなら、このTLVは容認されたEROで運ばれる情報と一致していて、そうでなければ、それは「悪い明白なルート設定TLV誤り」のエラーコード「ルート設定誤り」と誤り値があるLABEL ABORT 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 Status TLV are defined.
ケースが誤りに関連している特定のインタフェースを示すのが役に立つところにあります。 これらのケースを支える、_ID Status TLVが定義されるなら。
Ashwood-Smith & Berger Standards Track [Page 15] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[15ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
8.2.1. IF_ID Status TLVs
8.2.1. _ID状態TLVsです。
The format of the IPv4 IF_ID Status TLV is:
_ID Status TLVであるなら、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x082f) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| (0x082f)をタイプしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4次/の前のホップアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ステータスコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 IF_ID Status TLV is:
_ID Status TLVであるなら、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x0830) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Error Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| タイプ(0×0830)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6誤りノードアドレス| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ステータスコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3036] for a description of status code value fields. See [RFC3471] for a description of parameters and encoding of TLVs.
ステータスコード値の分野の記述に関して[RFC3036]を見てください。 パラメタの記述と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 Status TLV in the corresponding LABEL WITHDRAW or LABEL RELEASE message. IF_ID Status TLV SHOULD be generated and processed as any other Status TLV, see [RFC3036].
誤りが特定のインタフェースSHOULDに関連するのを示したがっているノードが_対応するLABEL WITHDRAWかLABEL RELEASEメッセージのID Status TLVであるなら好個を使用します。 _ID Status TLV SHOULDが発生していかなる他のStatus TLVとしても処理されているなら、[RFC3036]を見てください。
Ashwood-Smith & Berger Standards Track [Page 16] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[16ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
9. Fault Handling
9. 欠点取り扱い
In optical transport networks, failures in the out-of-fiber signaling communication or optical control plane should not have service impact on the existing optical connections. Under such circumstances, a mechanism MUST exist to detect a signaling communication failure and a recovery procedure SHALL guarantee connection integrity at both ends of the signaling channel.
光学転送ネットワークでは、ファイバーで出ているシグナリングコミュニケーションか光学制御飛行機での失敗で、サービスに既存の光の接続のときに影響を与えるべきではありません。 これでは、メカニズムは、シグナリングチャンネルの両端にシグナリング通信障害とリカバリ手順SHALL保証接続保全を検出するために存在しなければなりません。
The LDP Fault tolerant document [LDP-FT] specifies the procedures for recovering LDP and CR-LDP sessions under failure. Please refer to his document for procedures on recovering optical connections. Currently the Fault tolerant document covers many of the common failure modes for a separated control and data plane.
自由民主党のFaultの許容性があるドキュメント[自由民主党-FT]は失敗の下で自由民主党とCR-自由民主党のセッションを回復するための手順を指定します。 光の接続を回復するとき、手順のための彼のドキュメントを参照してください。 現在の、Faultの許容性があるドキュメントは切り離されたコントロールとデータ飛行機のために一般的な故障モードの多くをカバーしています。
10. Acknowledgments
10. 承認
This document is the work of numerous authors and consists of a composition of a number of previous documents in this area.
このドキュメントは、多数の作者の仕事であり、この領域での前の多くのドキュメントの構成から成ります。
Valuable comments and input were received from a number of people, notably Adrian Farrel.
多くの人々、著しくエードリアン・ファレルから貴重なコメントと入力を受け取りました。
11. Security Considerations
11. セキュリティ問題
This document introduces no new security considerations to [RFC3212].
このドキュメントはどんな新しいセキュリティ問題も[RFC3212]に紹介しません。
12. IANA Considerations
12. IANA問題
This document uses the LDP [RFC3036] name spaces, see http://www.iana.org/assignments/ldp-namespaces, which lists the assignments for the following TLVs:
http://www.iana.org/assignments/ldp-namespaces (以下のTLVsのために課題を記載する)は、このドキュメントが空間という自由民主党[RFC3036]名を使用するのを見ます:
o Generalized Label Request (TLV 0x0824) o Generalized Label (TLV 0x0825) o Upstream Label (TLV 0x0826) o Label Set (TLV 0x0827) o Waveband Label (TLV 0x0828) o ER-Hop (TLV 0x0829) o Acceptable Label Set (TLV 0x082a) o Admin Status (TLV 0x082b) o Interface ID (TLV 0x082c) o IPV4 Interface ID (TLV 0x082d) o IPV6 Interface ID (TLV 0x082e) o IPv4 IF_ID Status (TLV 0x082f) o IPv6 IF_ID Status (TLV 0x0830) o Protection (TLV 0x0835)
o Label Request(TLV0x0824)o Generalized Label(TLV0x0825)o Upstream Label(TLV0x0826)o Label Set(TLV0x0827)o Waveband Label(TLV0x0828)o ER-ホップ(TLV0x0829)o Acceptable Label Setを一般化する、(TLV 0x082a)o Admin Status(TLV 0x082b)o Interface ID(TLV 0x082c)o IPV4 Interface ID(TLV 0x082d)o IPV6 Interface ID(TLV 0x082e)o IPv4、_ID Status(TLV 0x082f)o IPv6である、_ID Status(TLV0x0830)o Protectionです。(TLV0x0835)
Ashwood-Smith & Berger Standards Track [Page 17] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[17ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
13. Intellectual Property Considerations
13. 知的所有権問題
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専務に情報を記述してください。
14. References
14. 参照
14.1. Normative References
14.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月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.
and B. Thomas, "LDP Specification", RFC 3036,
January 2001.
[RFC3036] アンデションとL.とDoolanとP.とフェルドマンとN.とFredetteとA.とB.トーマス、「自由民主党仕様」、RFC3036、2001年1月。
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R.,
Wu, L., Doolan, P., Worster, T., Feldman, N.,
Fredette, A., Girish, M., Gray, E., Heinanen, J.,
Kilty, T. and A. Malis, "Constraint-Based LSP Setup
using LDP", RFC 3212, January 2002.
[RFC3212] Jamoussi、B.、アンデション、L.、Callon、R.、Dantu、R.、ウー、L.、Doolan、P.、オースター、T.、フェルドマン、N.、Fredette、A.、Girish、M.、グレー、E.、Heinanen、J.、Kilty、T.、およびA.Malis、「自由民主党を使用して、規制ベースのLSPはセットアップします」、RFC3212、2002年1月。
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Functional
Description", RFC 3471, January 2003.
[RFC3471] バーガー、L.、エディタ、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、2003年1月。
Ashwood-Smith & Berger Standards Track [Page 18] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[18ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
14.2. Informative References
14.2. 有益な参照
[LDP-FT] Farrel, A., et al, "Fault Tolerance for LDP and CR-
LDP", Work in Progress.
[自由民主党-FT] ファレル、A.、他、「自由民主党とCR自由民主党のための耐障害性」、ProgressのWork。
[MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
MPLS TE", Work in Progress.
「MPLS TeがあるLSP階層構造」という[MPLS-階層構造]のKompella、K.、およびY.Rekhterは進行中で働いています。
[MPLS-UNNUM] Kompella, K., Rekhter, Y. and A. Kullberg,
"Signalling Unnumbered Links in CR-LDP", Work in
Progress.
[MPLS-UNNUM] 「CR-自由民主党における合図の無数のリンク」というKompella、K.、Rekhter、Y.、およびA.Kullbergは進行中で働いています。
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3," BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナー、S.、「インターネット規格は処理されます--改正3インチ、BCP9、RFC2026、10月1996日。
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling - Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE)
Extensions", RFC 3473, January 2003.
[RFC3473] バーガー、L.、エディタ、「マルチプロトコルで一般化されて、切り換え(GMPLS)をシグナリングとラベルしてください--資源予約プロトコル交通工学(RSVP-Te)拡大」、RFC3473、2003年1月。
15. Contributors
15. 貢献者
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
Ashwood-Smith & Berger Standards Track [Page 19] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[19ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
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
Greg Bernstein EMail: gregb@grotto-networking.com
グレッグバーンスタインEMail: gregb@grotto-networking.com
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
Don Fedyk Nortel Networks Corp. 600 Technology Park Billerica MA 01821
ドンFedykノーテルは社600の技術公園ビルリカMA 01821をネットワークでつなぎます。
Phone: +1 978 288 3041 Fax: +1 978 288 0620 EMail: dwfedyk@nortelnetworks.com
以下に電話をしてください。 +1 978 288、3041Fax: +1 0620年の978 288メール: dwfedyk@nortelnetworks.com
Jonathan P. Lang EMail: jplang@ieee.org
ジョナサンP.ラングメール: jplang@ieee.org
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
Ashwood-Smith & Berger Standards Track [Page 20] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[20ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
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
Debanjan Saha EMail: debanjan@acm.org
DebanjanシャハEMail: debanjan@acm.org
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
Ashwood-Smith & Berger Standards Track [Page 21] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[21ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
16. Editors' Addresses
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
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
Ashwood-Smith & Berger Standards Track [Page 22] RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003
Ashwood-スミスとバーガー標準化過程[22ページ]RFC3472GMPLSシグナリング--CR-自由民主党拡大2003年1月
17. Full Copyright Statement
17. 完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Ashwood-Smith & Berger Standards Track [Page 23]
Ashwood-スミスとバーガー標準化過程[23ページ]
一覧
スポンサーリンク
