Internet Engineering Task Force (IETF) JP. Vasseur, Ed.
Request for Comments: 5711 G. Swallow
Updates: 3209 Cisco Systems, Inc.
Category: Standards Track I. Minei
ISSN: 2070-1721 Juniper Networks
January 2010
Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages
発信およびリソース予約プロトコル（RSVP）パスのエラーメッセージを受信すると、ノードの動作
Abstract
抽象
The aim of this document is to describe a common practice with regard to the behavior of nodes that send and receive a Resource Reservation Protocol (RSVP) Traffic Engineering (TE) Path Error messages for a preempted Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP). (For reference to the notion of TE LSP preemption, see RFC 3209.) This document does not define any new protocol extensions.
このドキュメントの目的は、送信ノードの動作に関しては一般的な方法を説明し、先取りマルチプロトコルラベルスイッチング（MPLS）または一般化MPLS（のためのリソース予約プロトコル（RSVP）トラフィックエンジニアリング（TE）パスのエラーメッセージを受信しますGMPLS）トラフィックエンジニアリングラベルスイッチパス（TE LSP）。このドキュメントはどんな新しいプロトコルの拡張を定義していません（TE LSPのプリエンプションの概念を参照するために、RFC 3209を参照してください）。
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/rfc5711.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5711で取得することができます。
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. Requirements Language ......................................3
2. Protocol Behavior ...............................................3
2.1. Behavior at Detecting Nodes ................................4
2.2. Behavior at Receiving Nodes ................................5
2.3. Data-Plane Behavior ........................................5
3. RSVP PathErr Messages for a Preempted TE LSP ....................5
4. Security Considerations .........................................5
5. Acknowledgements ................................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
The aim of this document is to describe a common practice with regard to the behavior of a node sending a Resource Reservation Protocol (RSVP) Traffic Engineering (TE) Path Error message and to the behavior of a node receiving an RSVP Path Error message for a preempted Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP). (For reference to the notion of TE LSP preemption, see [RFC3209]).
このドキュメントの目的は、リソース予約プロトコル（RSVP）トラフィックエンジニアリング（TE）パスのエラーメッセージを送信するノードの行動へとAのためのRSVPパスのエラーメッセージを受信したノードの動作に関しては一般的な方法を記述することです横取りマルチプロトコルラベルスイッチング（MPLS）と一般化MPLS（GMPLS）トラフィックエンジニアリングラベルスイッチパス（TE LSP）。 （TE LSPプリエンプションの概念を参照するために、[RFC3209]を参照）。
[RFC2205] defines two RSVP error message types: PathErr and ResvErr that are generated when an error occurs. Path Error messages (PathErr) are used to report errors and travel upstream toward the head-end of the flow. Resv Error messages (ResvErr) travel downstream toward the tail-end of the flow.
たPathErrとResvErrエラーが発生したときに生成される：[RFC2205は、2つのRSVPエラーメッセージ・タイプを定義します。パスエラーメッセージ（のPathErr）がエラーを報告し、流れのヘッドエンドに向かって上流に移動するために使用されています。 RESVエラーメッセージ（ResvErr）は、フローの最後尾に向かって下流に移動します。
This document describes only PathErr message processing for the specific case of a preempted TE LSP, where the term preemption is defined in [RFC3209].
この文書では、用語プリエンプションは[RFC3209]で定義されている先取りTE LSPの特定の場合についてのみのPathErrメッセージ処理について説明します。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
PathErr messages are routed hop-by-hop using the path state established when a Path message is routed through the network from the head-end to its tail-end.
たPathErrメッセージは、Pathメッセージは、その末尾に、ヘッドエンドからネットワークを介してルーティングされるときに確立されたパスの状態を使用してホップバイホップルーティングされます。
As stated in [RFC2205], PathErr messages do not modify the state of any node through which they pass; they are only reported to the head-end of the TE LSP (Traffic Engineering Label Switched Path).
[RFC2205]に記載されているように、のPathErrメッセージは、それらが通過する任意のノードの状態を変更しません。彼らは唯一のTE LSP（トラフィックエンジニアリングラベルスイッチパス）のヘッドエンドに報告されています。
The format of the PathErr message is defined in Section 3. of [RFC2205].
PathErrメッセージのフォーマットは、[RFC2205]のセクション3で定義されています。
The ERROR_SPEC object includes the IP address of the node that detected the error (Error Node Address), and specifies the error through two fields. The Error Code field encodes the category of the error, for example, Policy Control Failure or Unknown object class. The Error Value field qualifies the error code to indicate the error with more precision. [RFC3209] extends RSVP as defined in [RFC2205] for the management of MPLS-TE LSPs. [RFC3209] specifies several additional conditions that trigger the sending of a RSVP PathErr message for which new error codes and error values have been defined that extend the list defined in [RFC2205]. The exact circumstances under which a TE LSP is preempted and such PathErr messages are sent are defined in [RFC3209] and will not be repeated here.
ERROR_SPECオブジェクトは、エラー（エラーノードアドレス）を検出したノードのIPアドレスが含まれており、二つのフィールドを介してエラーを特定します。エラーコード欄には、エラー、例えば、ポリシー制御の失敗または不明なオブジェクトクラスのカテゴリを符号化します。エラー値のフィールドには、より正確にエラーを示すエラーコードを修飾します。 MPLS-TE LSPの管理のために[RFC2205]で定義されるように[RFC3209]はRSVPを拡張します。 [RFC3209]は[RFC2205]で定義されたリストを拡張する新しいエラーコード及びエラー値が定義されているためのRSVPのPathErrメッセージの送信をトリガするいくつかの追加の条件を指定します。 TE LSPをプリエンプトされると、このようなのPathErrメッセージが送信されるの下で正確な状況は、[RFC3209]で定義されており、ここでは繰り返しません。
Values for the Error Code and Error Value fields defined in [RFC2205], [RFC3209], and other documents are maintained in a registry by the IANA.
エラーコードとエラー値[RFC2205]で定義されたフィールド、[RFC3209]、および他の文書の値はIANAによってレジストリに維持されています。
The error conditions fall into two categories:
エラー条件は、2つのカテゴリに分類されます。
o Fatal errors represent disruptive conditions for a TE LSP.
O致命的なエラーは、TE LSPのために破壊的条件を表します。
o Non-fatal errors are non-disruptive conditions that have occurred for this TE LSP.
O非致命的なエラーは、このTE LSPのために発生した無停止条件です。
PathErr messages may be used in two circumstances:
たPathErrメッセージは、2つの状況で使用することができます。
o during TE LSP establishment, and
TE LSPの確立中、O、及び
o after a TE LSP has been successfully established.
O TE LSPが正常に確立された後。
Nodal behavior is dependent on which combination of the four cases listed above applies. The following sections describe the expected behavior at nodes that perform a preemption action for a TE LSP (and therefore report using error PathErr messages), and at nodes that receive PathErr messages. This text is a clarification and restatement of the procedures set out in [RFC3209] and does not define any new behavior.
節点動作が適用され、上記4例どの組み合わせに依存しています。以下のセクションでは、TE LSPのプリエンプションアクションを実行する（したがって、エラーのPathErrメッセージを使用してレポート）ノードの予想される動作を記述し、そしてのPathErrメッセージを受信ノードに。このテキストは、[RFC3209]に記載された手順の明確化および修正再表示され、任意の新しい動作を定義しません。
In the case of fatal errors ("Hard Preemption"; see Section 4.7.3 of [RFC3209] ), the detecting node MUST send a PathErr message reporting the error condition, and MUST clear the corresponding Path and Resv (control plane) states. A direct implication is that the data-plane resources of such a TE LSP are also released, thus resulting in traffic disruption. It should be noted, however, that in fatal error cases, the LSP has usually already failed in the data plane, and traffic has already been disrupted. When the error arises during LSP establishment, the implications are different to when it arises on an active LSP since no traffic flows until the LSP has been fully established. In the case of non-fatal errors, the detecting node should send a PathErr message, and must not clear control plane or data plane state.
致命的なエラー（「ハードプリエンプション」[RFC3209]のセクション4.7.3を参照）の場合には、検出ノードは、エラー状態を報告したPathErrメッセージを送らなければなりません、そして対応するパスとのResv（制御プレーン）の状態をクリアする必要があります。直接的な含意は、TE LSPのデータプレーンリソースは、トラフィックの中断を生じる、したがって、解放されることです。致命的なエラーの場合には、LSPは通常、すでにデータプレーンに失敗した、とトラフィックがすでに破壊されていることに留意すべきです。エラーがLSPの確立中に発生した場合、影響はLSPが完全に確立されるまでトラフィックが流れないので、それがアクティブLSP上に生じた場合に異なっています。非致命的なエラーの場合には、検出ノードは、のPathErrメッセージを送信する必要があり、制御プレーンまたはデータプレーンの状態クリアしてはなりません。
Nodes that receive PathErr messages are all of the nodes along the path of the TE LSP upstream of the node that detected the error. This includes the head-end node. In accordance with Section 3.7.1 of [RFC2205], a node receiving a PathErr message takes no action upon it, and consequently the node must not clear Path or Resv control-plane or data-plane state. This is true regardless of whether the error condition reported by the PathErr is fatal or non-fatal. RSVP states should only be affected upon receiving a PathTear or ResvTear message, or in the event of a Path or Resv state timeout. Further discussion of the processing of these events is outside the scope of this document.
PathErrメッセージを受信するノードがエラーを検出したノードの上流のTE LSPの経路に沿ったすべてのノードです。これは、ヘッドエンドノードとを含みます。 [RFC2205]のセクション3.7.1に従って、のPathErrメッセージを受信したノードは、その上に何もアクションを取らず、その結果、ノードはならない明確なパスやたResvコントロールプレーンまたはデータプレーン状態。これは関係なく、のPathErrによって報告されたエラー条件が致命的または非致命的であるかどうかの事実です。 RSVP状態のみ、またはパスまたはのResv状態のタイムアウトが発生した場合にPathTearやたResvTearメッセージを受信すると、影響を受けるべきです。これらのイベントの処理のさらなる議論は、この文書の範囲外です。
Note that [RFC3473] defines a Path_State_Removed flag in the ERROR_SPEC object carried on a PathErr message. This field may be set to change the behavior of upstream nodes that receive the PathErr message. When set, the flag indicates that the message sender has removed Path state (and any associated Resv and data-plane state) for the TE LSP. The message receiver should do likewise before forwarding the message, but may retain state and clear the flag before forwarding the message.
[RFC3473]はのPathErrメッセージに担持ERROR_SPECオブジェクト内Path_State_Removedフラグを定義することに留意されたいです。このフィールドは、のPathErrメッセージを受信する上流ノードの動作を変更するように設定してもよいです。設定した場合、フラグは、メッセージ送信者がパス状態（および関連のResv及びデータプレーン状態）TE LSPのために除去したことを示します。メッセージ受信機は、メッセージを転送する前に、同様に行うべきであるが、状態を保持し、メッセージを転送する前にフラグをクリアすることができます。
Any node clearing either or both the Path or the Resv state of a TE LSP MUST also free up the data-plane resources allocated to the corresponding TE LSP.
またはパスまたはTE LSPののResv状態のいずれかの両方をクリアする任意のノードは、対応するTE LSPに割り当てられたデータ・プレーンのリソースを解放しなければなりません。
Two Error Codes have been defined to report a preempted TE LSP:
2つのエラー・コードは、プリエンプトTE LSPを報告するように定義されています。
o As defined in [RFC2750]: Error Code=2: "Policy Control Failure", Error Value=5: "Flow was preempted"
Oで定義されているように、[RFC2750]：エラーコード= 2：「ポリシー制御の失敗」、エラー値= 5：「フローが横取りされました」
o As defined in [RFC2205], Error Code=12: "Service preempted"
[RFC2205]、エラーコード= 12で定義されているように（O）「サービス先取り」
They are both fatal errors.
彼らは両方の致命的なエラーです。
This document does not define any new procedures, but clarifies those defined in other documents where security considerations are already specified in [RFC3209] and [RFC3473]. This document does not raise specific security issues beyond those of existing MPLS-TE. By clarifying the procedures, this document reduces the security risk introduced by non-conformant implementations. See [SEC_FMWK] for further discussion of MPLS security issues.
このドキュメントは、新しい手順を定義しますが、セキュリティ上の配慮がすでに[RFC3209]と[RFC3473]で指定されている他のドキュメントで定義されたものを明確にしません。この文書では、既存のMPLS-TEのそれを超えて特定のセキュリティ上の問題を提起しません。手順を明確にすることで、この文書は、非準拠の実装により導入されたセキュリティ上のリスクを軽減します。 MPLSのセキュリティ問題のさらなる議論のための[SEC_FMWK]を参照してください。
The authors would like to thank Carol Iturralde, Ashok Narayanan, Rom Reuther, and Reshad Rahman.
著者はキャロルIturralde、アショク・ナラヤナン、ROMルーサー、およびReshadラーマンに感謝したいと思います。
[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, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC2750]ヘルツォーク、S.、 "ポリシー制御のためのRSVP拡張機能"、RFC 2750、2000年1月。
[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。
[RFC3473] Berger, L., "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月。
[SEC_FMWK] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, October 2009.
[SEC_FMWK]牙、L.、エド。、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク"、進歩、2009年10月に作業。
Authors' Addresses
著者のアドレス
JP Vasseur (editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP Vasseur（エディタ）シスコ・システムズ・インク1414年マサチューセッツアベニューボックスボロー、MA 01719 USA
EMail: jpv@cisco.com
メールアドレス：jpv@cisco.com
George Swallow Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA
ジョージツバメシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719 USA
EMail: swallow@cisco.com
メールアドレス：swallow@cisco.com
Ina Minei Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 USA
伊那Mineiジュニパーネットワークスの1194北マチルダアベニュー。サニーベール、CA 94089 USA
EMail: ina@juniper.net
メールアドレス：ina@juniper.net