[要約] 要約： RFC 5710は、MPLSおよびGMPLS LSPの再ルートをトリガーするためのPathErrメッセージに関する仕様です。目的： このRFCの目的は、ネットワークの障害時に効果的なLSP再ルートを実現するためのPathErrメッセージの使用方法を定義することです。
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
Patherrメッセージは、MPLSおよび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の一部として既に定義されているメカニズムに依存し、実行される一連のアクションを単に説明します。既存のプロトコル定義を使用してRerouteアプリケーションをサポートできますが、このドキュメントでは、新しいReroute固有のエラーコードを定義して、Reroute-Application固有のエラー値の将来の定義を可能にします。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
[RFC2205]を参照するリソース予約プロトコル（RSVP）は、マルチプロトコルラベルスイッチング（MPLS）と一般化されたMPLS（GMPL）の両方のトラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）の制御をサポートするために拡張されています。それぞれ[RFC3209]および[RFC3473]。すべての場合において、Patherrメッセージを使用して、エラー検出ノードの上流のノードにエラーを報告します。[RFC2205]で定義され、[RFC3209]によって修正されていないままにしているように、Patherrメッセージは「通過するノードのパス状態を変更しない」。この定義にもかかわらず、Patherrメッセージは、LSPの確立中にエラーを報告するために最も一般的に使用されます。つまり、RESVメッセージを受信する前に発生するRSVP-TE処理です。（[RFC5711]を参照してください。PatherRメッセージ処理に関するより広範な議論については、そのような使用法のサポートは、[RFC3473]のPATH_STATE_REMOVEDフラグの導入によって強化されました。LSP施設中のPATHERRメッセージの使用は、[RFC4920]でさらにカバーされています。これは、ノードがそれまたは関連するリソースの1つを避けるべきであることを示す方法を詳細に説明しています。
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.
このドキュメントでは、用語「Rerouteリクエスト」を使用して、上流のRerouteが行われることをノードで示すことを指します。このドキュメントでは、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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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の再ルーティングを要求したい場合、最初にリルートリクエストにローカルで動作できるかどうかを判断します。このようなチェックは、LSPの着信パスメッセージで受信された[RFC3209]を参照してください。LSPの再ルーティングを排除しない[RFC3209]を参照してください。リルートをトリガーする可能性のあるリクエストの例は、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. 将来の互換性と後方互換性が懸念事項ではない場合、「Reroute/<Any Reroute Error Value>」。
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.
Reroute決定がローカルノードの周りのトラフィックをリダイレクトする場合、ローカルノードを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.
REROUTEリクエストタイムアウトは、REROUTEリクエストへの応答がない場合にLSPを削除するために使用されます。Reroute Request Timeout期間の有効期限時にLSPを削除する場合、Reroute Request Timeoutが使用されます。このようなLSPの削除が必要な場合、およびRerouteリクエストを開始した後、開始ノードはタイムアウトを開始する必要があります。その間、ルートリクエストへの応答を受信すると予想されます。有効な応答は、PATHTEARメッセージまたはEROを使用したトリガーパスメッセージであり、Rerouteリクエストに示されたリソースを回避します。どちらのタイプのメッセージを受信した場合、タイムアウト期間をキャンセルする必要があり、それ以上のアクションは必要ありません。注意してください。通常の更新処理は、Reroute Request Timeoutの導入によって変更されません。このような処理により、タイムアウト期間中にパス状態が削除される場合があります。この場合、タイムアウト期間もキャンセルする必要があります。
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.
Reroute Request Timeoutに到達した場合、開始ノードは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メッセージを調べて、ノードが要求されたルートを実行できることを確認する必要があります。REROUTEリクエストは、セクション2.1に上記のエラーコードと値の組み合わせの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.
トランジットノードは、LSPの着信パスメッセージで受け取ったEROがルーアウトを排除しない場合に、ローカルで再ルートリクエストに基づいて動作する場合があります。前と同様に、例には、緩やかにルーティングされたLSP Next Hopsが含まれます。ルートリクエストをローカルで処理できる場合、標準のローカル修理処理に従う必要があります。ノードは、ローカル修理の試みの数を制限する必要があります。繰り返しになりますが、予想される規範は地元の修理であり、それにより、この場合は政策のために排除されます。
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]によると、初期パスメッセージのLSP_ATTRIBUTESオブジェクトのフラグフィールドは、「境界再ルーティング」を示します。）ノードが再ルーティングをトリガーする場合、最初にドメイン内の代替パスを識別する必要があります。そのようなパスが利用可能な場合、ノードはPatherRメッセージを終了し、識別された代替パスを反映したパスメッセージを発行する必要があります。[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.
標準処理ごとに、トランジットノードがローカルでルートリクエストに基づいて動作できない場合、受信したPatherメッセージを前のホップに伝播する必要があります。
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.
Reroute処理がサポートされている場合、Ingressノードは受信したPATHERRメッセージをチェックして、リルートリクエストを示すものとして識別する必要があります。REROUTEリクエストは、セクション2.1に上記のエラーコードと値の組み合わせの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.
Rerouteリクエストを受信すると、Ingressは、エラー_Specオブジェクト内で識別されるノード、インターフェイス、リソースなどを避けて、代替パスを識別しようとする必要があります。代替パスを識別できない場合、Rerouteリクエストを破棄する必要があります。代替パスが識別される場合、対応するメイクブレイク前の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.
このセクションでは、Rerouteリクエストの例を示します。このセクションは、規範的ではなく有益です。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:
アップストリームノードによってノードを避ける必要があることを示すために、Rerouteを発信するノードは、[RFC2205]ごとにERROR_SPECをフォーマットする場合があります。
o IPv4 ERROR_SPEC object: Class = 6, C-Type = 1
o ipv4 error_specオブジェクト：class = 6、c-type = 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ルーターアドレスに設定されています。エラーコードは、「通知/ローカルノードのメンテナンスが必要」または「reroute/<任意のルーアウトエラー値>」に設定されています。
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:
上流ノードによって番号付きインターフェイスを避ける必要があることを示すために、Rerouteを発信するノードは、[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ルーターアドレスに設定されています。エラーコードは、「通知/ローカルリンクのメンテナンスが必要」または「reroute/<任意のルーアウトエラー値>」のいずれかに設定されています。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:
Upstreamノードによって非自己負担コンポーネントを回避する必要があることを示すために、Rerouteを発信するノードは、[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アドレスに設定されます。エラーコードは、「通知/ローカルリンクのメンテナンスが必要」または「reroute/<任意のルーアウトエラー値>」のいずれかに設定されています。ルーター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ルーターアドレスに設定されています。エラーコードは、「通知/ローカルリンクのメンテナンスが必要」または「reroute/<任意のルーアウトエラー値>」のいずれかに設定されています。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 Reroute [RFC5710]
This error code has the following defined Error Value sub-code:
このエラーコードには、次の定義されたエラー値サブコードがあります。
0 = Generic LSP reroute request
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（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] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（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. Berger、「MPLS Traffic Engineering（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] Farrel、A.、Ed。、Satyanarayana、A.、Iwata、A.、Fujita、N.、およびG. Ash、「MPLSおよびGMPLS RSVP-TEのクランクバックシグナル伝達拡張」、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。、ed。、ekejiri、Y。、およびR. Zhang、「マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）の再オプチミー化（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] Ali、Z.、Vasseur、JP。、Zamfir、A。、およびJ. Newton、「MPLSおよびGeneralized MPLS Traffic Engineering Networksの優雅なシャットダウン」、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。、ed。、ed。、swallow、G。、and I. Misei、「リソース予約プロトコル（RSVP）パスエラーメッセージの発信および受信時のノード動作」、RFC 5711、2010年1月。
[RFC5712] Meyer, M., Ed. and JP. Vasseur, Ed., "MPLS Traffic Engineering Soft Preemption", RFC 5712, January 2010.
[RFC5712] Meyer、M.、ed。とjp。Vasseur、ed。、「MPLS Traffic Engineering Soft Preemption」、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.
この文書は、マシュー・マイヤーとともに考案されました。ジョージ・スワローは貴重なフィードバックを提供しました。一般エリアレビューチーム（Gen-ART）レビューは、フランシスデュポンによって実行されました。
Authors' Addresses
著者のアドレス
Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net
Lou Berger Labn Consulting、L.L.C。電話：1-301-468-9228メール：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
Dimitri Papadimitriou Alcatel Lucent Francis Wellesplein 1、B-2018 Antwerpen、Belgium電話：32 3 240-8491メール：Dimitri.papadimitriou@alcatel-lucent.be
JP Vasseur Cisco Systems, Inc 11, Rue Camille Desmoulins L'Atlantis 92782 Issy Les Moulineaux France EMail: jpv@cisco.com
JP Vasseur Cisco Systems、Inc 11、Rue Camille Desmoulins L'Atlantis 92782 Issy Les Moulineaux France Email：jpv@cisco.com