Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 5710 LabN
Category: Standards Track D. Papadimitriou
ISSN: 2070-1721 Alcatel Lucent
JP. Vasseur
Cisco
January 2010
PathErr Message Triggered MPLS and GMPLS LSP Reroutes
Abstract
抽象
This document describes how Resource ReserVation Protocol (RSVP) PathErr messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases, including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. While existing protocol definitions can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute-application-specific error values.
この文書では、リソース予約プロトコル（RSVP）のPathErrメッセージは（MPLS）をマルチプロトコルラベルスイッチングの再ルーティングトリガするために使用することができると一般化MPLS（GMPLS）、ポイントツーポイントトラフィックエンジニアリング（TE）ラベルなし（LSPを）パスの交換方法について説明し最初のLSPの状態やリソースを削除します。そのようなLSPの再ルーティングは、例えば、ソフトプリエンプションおよび正常なシャットダウンを含むケースの数、に望ましいかもしれません。この文書では、LSPの再ルーティングをサポートするために、標準化過程のメカニズムを既存の使用方法について説明します。この場合には、既にRSVP-TEの一部として定義されたメカニズムに依存しており、単に実行すべきアクションのシーケンスを記述する。既存のプロトコル定義がリルートアプリケーションをサポートするために使用することができるが、この文書はまた、リルートアプリケーション固有のエラー値の将来の定義を可能にするために、新たなリルート固有のエラーコードを定義します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5710.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5710で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Reroute Requests ................................................4
2.1. Processing at Requesting Node ..............................4
2.1.1. Reroute Request Timeouts ............................5
2.2. Processing at Upstream Node ................................6
2.3. Processing at Ingress ......................................6
3. Example Reroute Requests ........................................7
3.1. Node Reroute Request .......................................7
3.2. Interface Reroute Request ..................................7
3.3. Component Reroute Request ..................................8
3.4. Label Reroute Request ......................................9
4. IANA Considerations .............................................9
5. Security Considerations ........................................10
6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................11
7. Acknowledgments ................................................11
The Resource ReserVation Protocol (RSVP), see [RFC2205], has been extended to support the control of Traffic Engineering (TE) Label Switched Paths (LSPs) for both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) in, respectively, [RFC3209] and [RFC3473]. In all cases, a PathErr message is used to report errors to nodes upstream of the error-detecting node. As defined in [RFC2205] and left unmodified by [RFC3209], PathErr messages "do not change path state in the nodes through which they pass". Notwithstanding this definition, PathErr messages are most commonly used to report errors during LSP establishment, i.e., the RSVP-TE processing that occurs prior to the ingress receiving a Resv message. (See [RFC5711] for a broader discussion on PathErr message handling.) Support for such usage was enhanced via the introduction of the Path_State_Removed flag in [RFC3473], which enables a processing node to free related LSP state and resources. The usage of PathErr messages during LSP establishment was further covered in [RFC4920], which describes in detail how a node may indicate that it or one of its associated resources should be avoided, i.e., routed around, during LSP establishment.
リソース予約プロトコル（RSVP）、[RFC2205]を参照してくださいは、トラフィックエンジニアリング（TE）ラベルは、の両方でマルチプロトコルラベルスイッチング（MPLS）と一般化MPLS（GMPLS）のために（LSPを）パスのスイッチの制御をサポートするように拡張されましたそれぞれ、[RFC3209]及び[RFC3473]。全ての場合において、のPathErrメッセージは、エラー検出ノードの上流のノードにエラーを報告するために使用されます。 [RFC2205]で定義されており、[RFC3209]によって修飾されていない左のように、のPathErrメッセージは、「彼らが通過するノードのパス状態を変更しません」。この定義にもかかわらず、のPathErrメッセージは、最も一般的にLSPの確立中にエラーを報告するために使用されている、すなわち、前Resvメッセージを受信した入力に発生RSVP-TE処理。 （たPathErrメッセージ処理に関するより広範な議論のために[RFC5711]を参照。）このような使用のためのサポートは、関連するLSPの状態とリソースを解放する処理ノードを有効に[RFC3473]でPath_State_Removedフラグの導入を介して増強されました。 LSPの確立中のPathErrメッセージの使用は、さらに、ノードは、それまたはその関連したリソースのいずれかが、回避、すなわち、LSPの確立中に、周りにルーティングされるべきであることを示すことができる方法を詳細に説明[RFC4920]で覆われていました。
PathErr messages can also be used to support a number of other cases that can occur after an LSP is established. This document focuses on the cases where PathErr messages can be used for a node to indicate that it desires an upstream node to reroute an LSP around the indicating node or resources associated with the indicating node. Some examples of such cases are soft-preemption and graceful shutdown (see [RFC5712] and [GRACEFUL]).
たPathErrメッセージは、LSPが確立された後に発生することができ、他の場合の数をサポートするために使用することができます。この文書は、のPathErrメッセージは、それが示すノードに関連付けられ示すノードまたはリソースの周りにLSPを再ルーティングするために上流のノードを望むことを示すためにノードのために使用することができる場合に焦点を当てています。このような場合のいくつかの例は、（[RFC5712]及び[GRACEFUL]を参照）ソフトプリエンプションおよび正常なシャットダウンされています。
This document uses the terminology "reroute request" to refer to the indication by a node that an upstream reroute should take place. This document describes how a node can initiate a reroute request without disrupting LSP data traffic or, when so desired, with the disruption of data traffic and removal of LSP-associated state and resources. The applicability of this document is limited to point-to-point LSPs. Support for point-to-multipoint LSPs are for further study.
この文書では、上流の再ルーティングが行われるべきノードによって表示を参照するための「要求を再ルーティング」の用語を使用しています。この文書は、ノードがデータトラフィックとLSPに関連する状態およびリソースの除去の中断で、所望の場合、LSPデータトラフィックを中断せずに、または再ルーティング要求を開始する方法について説明します。この文書の適用は、ポイント・ツー・ポイントのLSPに限定されています。ポイント・ツー・マルチポイントのLSPのサポートは、今後の検討課題です。
The mechanisms used to indicate reroute requests are derived from the mechanisms described in [RFC4920] and the error codes defined in [RFC4736]. This document describes (1) how a non-disruptive reroute request may be issued and, (2) based on an optional "timeout" period, how rerouting may be forced by removing LSP state and associated resources and signaling such removal. While this document describes how existing protocol definitions can be used to support rerouting, it also defines a new reroute-specific error code to allow for the future definition of reroute-application-specific error values.
リルート要求を示すために使用されるメカニズムは、[RFC4920]に記載の機構及び[RFC4736]で定義されたエラーコードに由来します。この文書では、（1）無停止リルート要求を発行することができる方法、（2）任意の「タイムアウト」期間に基づいて、どのように再ルーティングは、LSPの状態と関連するリソースを除去し、そのような除去をシグナリングすることによって強制することができる記述する。この文書は、既存のプロトコル定義が再ルーティングをサポートするために使用することができる方法を説明しますが、それはまた、リルートアプリケーション固有のエラー値の将来の定義を可能にするために、新たに再ルーティング固有のエラーコードを定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This section describes how a downstream node can indicate that it desires a node upstream (along the LSP path) to initiate the rerouting of an LSP, and how the upstream nodes can respond to such a request. Initiating nodes, transit nodes, and ingress nodes are described separately.
このセクションでは、下流ノードがLSPの再ルーティングを開始する（LSP経路に沿って）上流のノードを望むことを示すことができる方法、及び上流のノードは、このような要求に応答する方法について説明します。開始ノード、中継ノード、および入力ノードが別々に記載されています。
When a transit or egress node desires to request the rerouting of an established LSP, it first determines if it can act on the reroute request locally. Such a check MUST be performed on the condition that the Explicit Route Object (ERO), see [RFC3209], received in the LSP's incoming Path message does not preclude LSP rerouting. Examples of requests that may trigger reroutes are avoiding an outgoing interface, a component, label resource, or a next hop not explicitly listed in the ERO. In all cases, the actual repair action SHOULD be performed after verification that the local policy allows local repair for that LSP/state. That is, any traffic-rerouting action (associated to this state) must be initiated and completed only as allowed by local node policy.
トランジットまたは出口ノードは、確立されたLSPの再ルーティングを要求することを望む場合、それはローカルリルート要求に作用することができるならば、それは最初に決定します。そのようなチェックは、[RFC3209]を参照して明示的ルート・オブジェクト（ERO）という条件で実行する必要があり、LSPの再ルーティングを排除するものではないLSPの受信Pathメッセージで受信しました。再ルーティングをトリガすることができる要求の例は、出力インターフェース、コンポーネント、ラベルリソース、または明示的にEROに記載されていない次のホップを回避しています。全ての場合において、実際の修復アクションはローカルポリシーは、そのLSP /状態のローカル修復を可能にすることを検証した後に行われるべきです。すなわち、（この状態に関連する）、任意のトラフィック再ルーティングアクションがローカル・ノードポリシーによって許可された唯一のように開始され完了されなければなりません。
When the node cannot act locally, it MUST issue a PathErr message indicating its inability to perform local rerouting. The PathErr message MUST contain an ERROR_SPEC object of the format defined in [RFC2205] or [RFC3473]. Such a message MUST include one of the following combinations of error codes and error values:
ノードはローカルに行動することはできません場合は、ローカルの再ルーティングを実行することができないことを示すのPathErrメッセージを発行しなければなりません。たPathErrメッセージは、[RFC2205]または[RFC3473]で定義されたフォーマットのERROR_SPECオブジェクトを含まなければなりません。そのようなメッセージは、エラーコードとエラー値の以下の組み合わせのいずれかを含める必要があります。
1. "Notify/Local node maintenance required" to support backwards compatibility and to reroute around the local node.
1.「通知/ローカル・ノードの保守に必要な」後方互換性をサポートし、ローカル・ノードの周りに再ルーティングします。
2. "Notify/Local link maintenance required" to support backwards compatibility and to reroute around a local interface.
2.「通知/ローカルリンクのメンテナンスに必要な」後方互換性をサポートし、ローカルインタフェース周りリルートします。
3. "Reroute/<any Reroute error value>" for future compatibility and when backwards compatibility is not a concern.
3.「再ルーティング/ <任意の再ルーティングエラー値>」将来の互換性とするとき、後方互換性が問題にならないために。
The rest of the ERROR_SPEC object is constructed based on the local rerouting decision and the resource that is to be avoided by an upstream node. It is important to note that the address and TLVs carried by the ERROR_SPEC object identify the resource to be avoided and not the error code and value.
ERROR_SPECオブジェクトの残りの部分は、ローカル再ルーティング決定および上流ノードによって回避されるリソースに基づいて構築されています。 ERROR_SPECオブジェクトによって運ばれたアドレスとのTLVを回避するためのリソースではなく、エラーコードと値を識別することを注意することが重要です。
When the reroute decision redirects traffic around the local node, the local node MUST be indicated in the ERROR_SPEC object. Otherwise, i.e., when the reroute decision does not redirect traffic around the local node, the impacted interface MUST be indicated in the ERROR_SPEC object and the IF_ID [RFC3473] ERROR_SPEC object formats SHOULD be used to indicate the impacted interface.
リルート判断は、ローカルノードの周囲のトラフィックをリダイレクトする場合、ローカルノードはERROR_SPECオブジェクトで示されなければなりません。そうでない場合、すなわち、ローカルノードの周囲のトラフィックをリダイレクトしないリルート決定は、影響を受けるインターフェイスはERROR_SPECオブジェクトとに示されなければならない場合IF_ID [RFC3473] ERROR_SPECオブジェクトフォーマットは影響を受けるインタフェースを示すために使用されるべきです。
The IF_ID [RFC3473] ERROR_SPEC object format MUST be used to indicate a reroute request that is more specific than an interface. The TLVs defined in [RFC3471], as updated by [RFC3477], [RFC4201], and [RFC4920] MAY be used to provide specific, additional reroute request information, e.g., reroute around a specific label. The principles related to ERROR_SPEC object construction, defined in Section 6.3.1 of [RFC4920], SHOULD be followed.
IF_ID [RFC3473] ERROR_SPECオブジェクトフォーマットは、インターフェースよりも特異的であるリルート要求を示すために使用されなければなりません。 [RFC3471]で定義されたTLVは、[RFC3477]、[RFC4201]及び[RFC4920]で更新され、例えば、特定のラベルの周りに再ルーティング、特定の、追加のリルート要求情報を提供するために使用され得ます。 [RFC4920]のセクション6.3.1で定義されたERROR_SPECオブジェクト構造に関連する原理は、その後されるべきです。
Reroute request timeouts are used to remove an LSP when there is no response to a reroute request. A reroute request timeout is used when an LSP is to be removed at the expiration of the reroute request timeout period. When such LSP removal is desired, and after initiating a reroute request, the initiating node MUST initiate a timeout during which it expects to receive a response to the reroute request. Valid responses are a PathTear message or a trigger Path message with an ERO, avoiding the resource that was indicated in the reroute request. If either type of message is received, the timeout period MUST be canceled and no further action is needed. Note, normal refresh processing is not modified by the introduction of reroute request timeouts. Such processing may result in Path state being removed during the timeout period, in which case the timeout period MUST also be canceled.
再ルーティング要求のタイムアウトがリルート要求に対する応答がない場合にLSPを除去するために使用されます。リルート要求タイムアウトは、LSPがリルート要求タイムアウト期間の満了時に除去されるときに使用されます。そのようなLSPの除去が所望される場合、および再ルーティング要求を開始した後、開始ノードは、リルート要求に対する応答を受信することを期待その間タイムアウトを開始しなければなりません。有効な応答は、経路変更要求に示されたリソースを回避PathTearメッセージまたはEROとトリガPathメッセージです。メッセージのいずれかのタイプを受信した場合、タイムアウト期間をキャンセルしなければならなくて、それ以上のアクションは必要ありません。ノートは、通常のリフレッシュ処理がリルート要求のタイムアウトの導入によって修飾されていません。このような処理は、タイムアウト期間もキャンセルしなければならない場合にはタイムアウト期間中に除去されるパスの状態をもたらすことができます。
If the reroute request timeout is reached, the initiating node MUST remove the LSP and its associated state and resources. Removal of LSP state is indicated downstream via a corresponding PathTear message. Removal is indicated upstream via a PathErr message with the error code of "Service preempted". The Path_State_Removed flag MUST be set if supported. When the Path_State_Removed flag is not supported, a corresponding ResvTear MUST also be sent.
リルート要求タイムアウトに達した場合は、開始ノードは、LSPおよびそれに関連する状態とリソースを削除する必要があります。 LSP状態の除去は、対応PathTearメッセージを介して下流側に示されています。除去は、「サービスは先取り」のエラーコードでのPathErrメッセージを介して上流示されています。サポートされている場合Path_State_Removedフラグを設定しなければなりません。 Path_State_Removedフラグがサポートされていない場合、対応たResvTearも送らなければなりません。
When a transit node's policy permits it to support reroute request processing and local repair, the node MUST examine incoming PathErr messages to see it the node can perform a requested reroute. A reroute request is indicated in a received PathErr message, which carries one of the error code and value combinations listed above in Section 2.1. Note that a conformant implementation MUST check for any of the three combinations listed in Section 2.1.
トランジットノードのポリシーは、リルート要求処理およびローカル修復をサポートするためにそれを許可した場合、ノードは、ノードが要求され、リルートを行うことができます見に入ってくるのPathErrメッセージを調べる必要があります。リルート要求はセクション2.1で上記のエラーコードと値の組み合わせのいずれかを運ぶ受信たPathErrメッセージに示されています。準拠の実装は2.1節に記載されている3つの組み合わせのいずれかをチェックしなければならないことに注意してください。
A transit node MAY act on a reroute request locally when the ERO received in the LSP's incoming Path message does not preclude the reroute. As before, examples include loosely routed LSP next hops. When the reroute request can be processed locally, standard, local repair processing MUST be followed. The node SHOULD limit the number of local repair attempts. Again, the expected norm is for local repair, and thereby this case, to be precluded due to policy.
EROは、リルートを排除するものではないLSPの入って来るPathメッセージで受信したときにトランジットノードは、ローカルリルート要求に作用することができます。前述のように、例が緩くルーティングされたLSPのネクストホップが含まれます。リルート要求をローカルで処理することができる場合、標準的な、ローカルリペア処理が続かなければなりません。ノードは、ローカル修復の試行回数を制限する必要があります。再び、予想されるノルムは、ローカル修復のためであり、これによりこの場合、ポリシーのために除外されます。
When the transit node supports [RFC4920] and is a boundary node, and Boundary rerouting is allowed, it SHOULD use a route request as a trigger to reroute the LSP. (Per [RFC4920], the Flags field of the LSP_ATTRIBUTES object of the initial Path message indicates "Boundary rerouting".) In the case the node triggers rerouting, it first MUST identify an alternate path within the domain. When such a path is available, the node MUST terminate the PathErr message and issue a Path message reflecting the identified alternate path. Processing then continues per [RFC4920]. When an alternate path is not available, the node cannot act on the reroute request.
トランジットノードサポート[RFC4920]及び境界ノードであり、境界再ルーティングが許可されると、LSPを再ルーティングするためのトリガとしてルート要求を使用すべきです。ここで、ノードは、再ルーティングトリガー（パー[RFC4920]、最初のPathメッセージのLSP_ATTRIBUTESオブジェクトのFlagsフィールドが「境界が再ルーティング」を示す。）、それは最初のドメイン内の代替パスを識別しなければなりません。そのようなパスが利用可能である場合、ノードは、のPathErrメッセージを終了し、識別された代替パスを反映したPathメッセージを発行しなければなりません。次に、処理は、[RFC4920]あたりに続きます。代替パスが利用できない場合、ノードは、リルート要求に作用することができません。
When a transit node cannot act on a reroute request locally, per standard processing, it MUST propagate the received PathErr message to the previous hop.
トランジットノードは、局所的にリルート要求に作用することができない場合、標準的な処理ごとに、それが前のホップに受信したPathErrメッセージを伝達しなければなりません。
When reroute processing is supported, an ingress node MUST check received PathErr messages to identify them as indicating reroute requests. A reroute request is indicated in a received PathErr message, which carries one of the error code and value combinations listed above in Section 2.1. Note that a conformant implementation MUST check for any of the three combinations listed in Section 2.1.
リルート処理がサポートされているときに、入口ノードは、リルート要求を示すようにそれらを識別するために、受信したPathErrメッセージをチェックしなければなりません。リルート要求はセクション2.1で上記のエラーコードと値の組み合わせのいずれかを運ぶ受信たPathErrメッセージに示されています。準拠の実装は2.1節に記載されている3つの組み合わせのいずれかをチェックしなければならないことに注意してください。
Upon receiving a reroute request, the ingress MUST attempt to identify an alternate path, avoiding the node, interface, resource, etc. identified within the ERROR_SPEC object. When an alternate path cannot be identified, the reroute request MUST be discarded. When an alternate path is identified, a corresponding make-before-break LSP SHOULD be initiated and standard make-before-break procedures MUST be followed.
リルート要求を受信すると、入口ノードを回避する、代替パスを識別しようとしなければならない、インターフェイス、リソース、等ERROR_SPECオブジェクト内で識別しました。代替パスが特定できない場合、リルート要求を捨てなければなりません。代替パスが識別されると、対応するビフォアブレークLSPが開始されるべきであり、標準的なメーク・ビフォア・ブレーク手順に従わなければなりません。
This section provides example reroute requests. This section is informative rather than prescriptive. Reroute requests are always sent via PathErr messages. As described above, a PathErr message may contain either an [RFC2205] format ERROR_SPEC object, or an IF_ID [RFC3473] format ERROR_SPEC object; it is the address and TLVs carried by the ERROR_SPEC object, and not the error value, that indicates the resource that is to be avoided by the reroute.
このセクションでは、例の要求を再ルーティングを提供します。このセクションは参考情報ではなく、規範です。再ルーティング要求は常にのPathErrメッセージを介して送信されます。上記のように、のPathErrメッセージは、[RFC2205]形式ERROR_SPECオブジェクト、またはIF_ID [RFC3473]形式ERROR_SPECオブジェクトのいずれかを含んでいてもよいです。それはそれは、リルートすることで回避されるリソースを示し、アドレスとERROR_SPECオブジェクトによって運ばれたTLVはなく、エラー値です。
To indicate that the node should be avoided by an upstream node, the node originating the reroute may format the ERROR_SPEC per [RFC2205], for example:
ノードは、上流ノードによって回避されるべきであることを示すために、リルートを発信ノードは、例えば、[RFC2205]あたりERROR_SPECをフォーマットすることができます。
o IPv4 ERROR_SPEC object: Class = 6, C-Type = 1
OのIPv4 ERROR_SPECオブジェクト：クラス= 6、Cタイプ= 1
+-------------+-------------+-------------+-------------+
| IPv4 Error Node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
The node address is set to the local node's TE router address. Error code is set to either "Notify/Local node maintenance required" or "Reroute/<any Reroute error value>".
ノードアドレスは、ローカル・ノードのTEルータアドレスに設定されています。エラーコードは、「必要な通知/ローカル・ノードのメンテナンス」または「再ルーティング/ <任意の再ルーティングエラー値>」のいずれかに設定されています。
To indicate that a numbered interface should be avoided by an upstream node, the node originating the reroute may format the ERROR_SPEC per [RFC3473], for example:
番号インタフェースは上流ノードによって回避されるべきであることを示すために、リルートを発信ノードは、例えば、[RFC3473]あたりERROR_SPECをフォーマットすることができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The node address is set to the local node's TE router address. Error code is set to either "Notify/Local link maintenance required" or "Reroute/<any Reroute error value>". IP address is set to the TE address of the interface to be avoided.
ノードアドレスは、ローカル・ノードのTEルータアドレスに設定されています。エラーコードは、「必要な通知/ローカルリンクのメンテナンス」または「再ルーティング/ <任意の再ルーティングエラー値>」のいずれかに設定されています。 IPアドレスは避けるべきインタフェースのTEアドレスに設定されています。
To indicate that an unnumbered component should be avoided by an upstream node, the node originating the reroute formats the ERROR_SPEC per [RFC4201], for example:
無数の成分が上流ノードによって回避されるべきであることを示すために、リルートを発信ノードは、例えば、[RFC4201]あたりERROR_SPECをフォーマット：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (3) | Length (12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The node address is set to the local TE address used in the advertisement of the bundle associated with the component. Error code is set to either "Notify/Local link maintenance required" or "Reroute/<any Reroute error value>". Router ID is set to the local router ID, and Interface ID is the identifier assigned to the component link by the local node.
ノードアドレスは、コンポーネントに関連付けられた束の広告で使用されるローカルTEアドレスに設定されています。エラーコードは、「必要な通知/ローカルリンクのメンテナンス」または「再ルーティング/ <任意の再ルーティングエラー値>」のいずれかに設定されています。ルータIDは、ローカルルータのIDに設定され、インタフェースIDは、ローカル・ノードがコンポーネントリンクに割り当てられた識別子です。
To indicate that a label should be avoided by an upstream node, the node originating the reroute may format the ERROR_SPEC per [RFC4920], for example:
ラベルは、上流ノードによって回避されるべきであることを示すために、リルートを発信ノードは、例えば、[RFC4920]あたりERROR_SPECをフォーマットすることができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (6) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DOWNSTREAM_LABEL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The node address is set to the local node's TE router address. Error code is set to either "Notify/Local link maintenance required" or "Reroute/<any Reroute error value>". IP address is set to the TE address of the interface that supports the label to be avoided. DOWNSTREAM_LABEL indicates the label to be avoided.
ノードアドレスは、ローカル・ノードのTEルータアドレスに設定されています。エラーコードは、「必要な通知/ローカルリンクのメンテナンス」または「再ルーティング/ <任意の再ルーティングエラー値>」のいずれかに設定されています。 IPアドレスは、ラベルを回避するためにサポートしているインタフェースのTEアドレスに設定されています。 DOWNSTREAM_LABELはラベルが回避されるように示しています。
IANA assigned values for namespaces defined in this document and reviewed in this section.
IANAは、この文書で定義された名前空間の値が割り当てられ、このセクションで検討しました。
IANA made the assignment in the "Error Codes and Globally-Defined Error Value Sub-Codes" section of the "RSVP Parameters" registry:
IANAは、「RSVPパラメータ」レジストリの「エラーコードおよびグローバル定義のエラー値サブコード」セクションに割り当てを行いました。
34 Reroute [RFC5710]
34リルート[RFC5710]
This error code has the following defined Error Value sub-code:
このエラーコードは次のように定義エラー値サブコードがあります。
0 = Generic LSP reroute request
0 =汎用LSPは、要求を再ルーティング
Reroute error values should be allocated based on the following allocation policy as defined in [RFC5226].
再ルーティングエラー値は[RFC5226]で定義されるように、次の割り当てポリシーに基づいて割り当てられるべきです。
Range Registration Procedures
-------- ------------------------
0-32767 IETF Consensus
32768-65535 Private Use
Sections 9 of [RFC4920] and [RFC4736] should be used as the starting point for reviewing the security considerations related to the formats and mechanisms discussed in this document. This document introduces a new error code, but this code is functionally equivalent to existing semantics, in particular, the error code/error value combinations of "Notify/Local node maintenance required" and "Notify/Local link maintenance required". As such, this document introduces no new security considerations beyond what already applies to these existing formats and mechanisms. Future documents may define new error values; any considerations specific to those values should be discussed in the document defining them. 6. References
[RFC4920]及び[RFC4736]のセクション9は、本文書で論じフォーマットとメカニズムに関連するセキュリティ問題を検討するための出発点として使用されるべきです。 「必要なローカル/通知ノードの保守」と「必要な通知/ローカルリンクのメンテナンス」の組み合わせをこの文書は、新しいエラーコードを紹介しますが、このコードは、特に、既存のセマンティクスと機能的に同等である、エラーコード/エラー値。そのため、この文書は、すでにこれらの既存のフォーマットやメカニズムに適用されるものを超えてどんな新しいセキュリティ問題も紹介しません。将来の文書が新しいエラー値を定義することができ、これらの値に固有の考慮事項は、それらを定義する文書で議論されるべきです。 6.参照
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、エド。は、 "一般化マルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K.とY. Rekhter、 "資源予約プロトコルでアンナンバードリンクシグナリング - トラフィックエンジニアリング（RSVP-TE）"、RFC 3477、2003年1月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201] Kompella、K.、Rekhter、Y.、およびL.バーガー、 "MPLSでのリンクバンドルトラフィックエンジニアリング（TE）"、RFC 4201、2005年10月。
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC4920]ファレル、A.編、Satyanarayana、A.、岩田、A.、藤田、N.、およびG.アッシュ、 "MPLSおよびGMPLS RSVP-TEのためのクランクバックシグナリング拡張"、RFC 4920、2007年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, November 2006.
[RFC4736] Vasseur、JP。、エド。、池尻、Y.、およびR.張は、 "マルチプロトコルラベルの再最適化スイッチング（MPLS）トラフィックエンジニアリング（TE）緩くルーティングラベルスイッチパス（LSP）"、RFC 4736、2006年11月。
[GRACEFUL] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton, "Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", Work in Progress, September 2009.
[GRACEFUL]アリ、Z.、Vasseur、JP。、Zamfir、A.、およびJ.ニュートン、 "MPLSおよび一般化MPLSトラフィックエンジニアリングネットワークの正常なシャットダウン"、進歩、2009年9月での作業。
[RFC5711] Vasseur, JP., Ed., Swallow, G., and I. Minei, "Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages", RFC 5711, January 2010.
[RFC5711] Vasseur、JP。、エド。、ツバメ、G.、およびI. Minei、 "発信時にノードの動作と受信リソース予約プロトコル（RSVP）パスのエラーメッセージ"、RFC 5711、2010年1月。
[RFC5712] Meyer, M., Ed. and JP. Vasseur, Ed., "MPLS Traffic Engineering Soft Preemption", RFC 5712, January 2010.
[RFC5712]マイヤー、M.、エド。そして、JP。 Vasseur、エド。、 "MPLSトラフィックエンジニアリングソフトプリエンプション"、RFC 5712、2010年1月。
This document was conceived along with Matthew Meyer. George Swallow provided valuable feedback. The General Area Review Team (Gen-ART) review was performed by Francis Dupont.
この文書は、マシュー・メイヤーと一緒に考案されました。ジョージ・ツバメは貴重なフィードバックを提供します。 - エリアレビューチーム（ジェン・ART）レビューはフランシス・デュポンによって行われました。
Authors' Addresses
著者のアドレス
Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net
ルー・バーガーLabNコンサルティング、L.L.C.電話：+ 1-301-468-9228 Eメール：lberger@labn.net
Dimitri Papadimitriou Alcatel Lucent Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: Dimitri.Papadimitriou@alcatel-lucent.be
ディミトリPapadimitriouアルカテルLykentフランシスVellesplein 1 B-2018アントワープ、Velgiomボイス：X2 + 3 240から8491 Eメール：Δημήτρη.Παπαδημητρίου@αλκατελ-λυκεντ.βε
JP Vasseur Cisco Systems, Inc 11, Rue Camille Desmoulins L'Atlantis 92782 Issy Les Moulineaux France EMail: jpv@cisco.com
JP Vasseurシスコシステムズ社11、ルーカミーユ・デムーランアトランティス92782イシレムリノーフランスEメール：jpv@cisco.com