Network Working Group A. Farrel, Ed.
Request for Comments: 4920 Old Dog Consulting
Category: Standards Track A. Satyanarayana
Cisco Systems, Inc.
A. Iwata
N. Fujita
NEC Corporation
G. Ash
AT&T
July 2007
Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
Status of This 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node.
分散、制約ベースのルーティング環境では、経路を計算するために使用される情報が古くなってもよいです。これは、マルチプロトコルラベルスイッチング（MPLS）と一般化MPLS（GMPLS）交通エンジニア（TE）ラベルスイッチパス（LSP）のセットアップ要求は十分な資源のないリンクまたはノードによってブロックされ得ることを意味します。クランクバックは、セットアップ障害情報が新しいセットアップの試みがブロックされたリソースを避けて行うことができるようにするために失敗した時点から戻される仕組みです。クランクバックはまた、故障したリンクまたはノードの位置を示すために、LSPの回復にも適用することができます。
This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3473. These extensions mean that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time.
このドキュメントは、で定義されたRSVP-TEを使用してMPLSシグナリングで使用するための拡張機能のシグナリングクランクバック指定：スイッチング汎用マルチプロトコルラベル」で定義され、RFC 3209、およびGMPLSシグナリング「RSVP-TE LSPトンネルのためのRSVPへの拡張」（GMPLS） 「機能の説明をシグナリング、RFC 3473.は、これらの拡張機能は、LSP設定要求が周りにブロックされたリンクまたはノードを迂回代替パスに再試行することができることを意味します。これは特に、セットアップ多数の要求を同時にトリガーされた状況では、LSPのための成功のセットアップとリカバリの比率が大幅に向上しています。
Table of Contents
目次
Section A: Problem Statement
セクションA：問題文
1. Introduction and Framework ......................................4
1.1. Background .................................................4
1.2. Control Plane and Data Plane Separation ....................5
1.3. Repair and Recovery ........................................5
1.4. Interaction with TE Flooding Mechanisms ....................6
1.5. Terminology ................................................7
2. Discussion: Explicit versus Implicit Re-Routing Indications .....7
3. Required Operation ..............................................8
3.1. Resource Failure or Unavailability .........................8
3.2. Computation of an Alternate Path ...........................8
3.2.1. Information Required for Re-Routing .................9
3.2.2. Signaling a New Route ...............................9
3.3. Persistence of Error Information ..........................10
3.4. Handling Re-Route Failure .................................11
3.5. Limiting Re-Routing Attempts ..............................11
4. Existing Protocol Support for Crankback Re-Routing .............11
4.1. RSVP-TE ...................................................12
4.2. GMPLS-RSVP-TE .............................................13
Section B: Solution
セクションB：ソリューション
5. Control of Crankback Operation .................................13
5.1. Requesting Crankback and Controlling In-Network
Re-Routing ................................................13
5.2. Action on Detecting a Failure .............................14
5.3. Limiting Re-Routing Attempts ..............................14
5.3.1. New Status Codes for Re-Routing ....................15
5.4. Protocol Control of Re-Routing Behavior ...................15
6. Reporting Crankback Information ................................15
6.1. Required Information ......................................15
6.2. Protocol Extensions .......................................16
6.3. Guidance for Use of IF_ID ERROR_SPEC TLVs .................20
6.3.1. General Principles .................................20
6.3.2. Error Report TLVs ..................................21
6.3.3. Fundamental Crankback TLVs .........................21
6.3.4. Additional Crankback TLVs ..........................22
6.3.5. Grouping TLVs by Failure Location ..................23
6.3.6. Alternate Path Identification ......................24
6.4. Action on Receiving Crankback Information .................25
6.4.1. Re-Route Attempts ..................................25
6.4.2. Location Identifiers of Blocked Links or Nodes .....25
6.4.3. Locating Errors within Loose or Abstract Nodes .....26
6.4.4. When Re-Routing Fails ..............................26
6.4.5. Aggregation of Crankback Information ...............26
6.5. Notification of Errors ....................................27
6.5.1. ResvErr Processing .................................27
6.5.2. Notify Message Processing ..........................28
6.6. Error Values ..............................................28
6.7. Backward Compatibility ....................................28
7. LSP Recovery Considerations ....................................29
7.1. Upstream of the Fault .....................................29
7.2. Downstream of the Fault ...................................30
8. IANA Considerations ............................................30
8.1. Error Codes ...............................................30
8.2. IF_ID_ERROR_SPEC TLVs .....................................31
8.3. LSP_ATTRIBUTES Object .....................................31
9. Security Considerations ........................................31
10. Acknowledgments ...............................................32
11. References ....................................................33
11.1. Normative References .....................................33
11.2. Informative References ...................................33
Appendix A.........................................................35
Section A : Problem Statement
セクションA：問題文
RSVP-TE (RSVP Extensions for LSP Tunnels) [RFC3209] can be used for establishing explicitly routed LSPs in an MPLS network. Using RSVP-TE, resources can also be reserved along a path to guarantee and/or control QoS for traffic carried on the LSP. To designate an explicit path that satisfies Quality of Service (QoS) guarantees, it is necessary to discern the resources available to each link or node in the network. For the collection of such resource information, routing protocols, such as OSPF and Intermediate System to Intermediate System (IS-IS), can be extended to distribute additional state information [RFC2702].
RSVP-TE（LSPトンネルのためのRSVP拡張）[RFC3209]はMPLSネットワークで明示的にルーティングされたLSPを確立するために使用することができます。 RSVP-TEを使用して、リソースもLSP上で伝送されるトラフィックのためおよび/または制御のQoSを保証するために、パスに沿って予約することができます。サービス品質（QoS）の保証を満足する明示的なパスを指定するには、ネットワーク内の各リンクまたはノードに利用可能なリソースを識別することが必要です。そのようなリソース情報の収集のために、中間システム（IS-IS）のようなOSPFや中間システムなどのルーティングプロトコルは、追加の状態情報[RFC2702]を配布するために拡張することができます。
Explicit paths can be computed based on the distributed information at the LSR (ingress) initiating an LSP and signaled as Explicit Routes during LSP establishment. Explicit Routes may contain 'loose hops' and 'abstract nodes' that convey routing through a collection of nodes. This mechanism may be used to devolve parts of the path computation to intermediate nodes such as area border LSRs.
明示的なパスはLSPを開始するLSR（入力）に配信された情報に基づいて計算され、LSPの確立中に、明示的なルートとしてシグナリングすることができます。明示的なルートは、「ゆるいホップ」とノードのコレクションを経由伝える「抽象ノード」を含んでいてもよいです。この機構は、エリア境界のLSRのような中間ノードに経路計算の一部を委譲するために使用することができます。
In a distributed routing environment, however, the resource information used to compute a constraint-based path may be out of date. This means that a setup request may be blocked, for example, because a link or node along the selected path has insufficient resources.
分散ルーティング環境では、しかし、制約ベースの経路を計算するために使用される資源情報は古くなってもよいです。これは、選択された経路に沿ったリンクまたはノードに十分なリソースを持っているので、設定要求は、例えば、ブロックされていてもよいことを意味します。
In RSVP-TE, a blocked LSP setup may result in a PathErr message sent to the ingress, or a ResvErr sent to the egress (terminator). These messages may result in the LSP setup being abandoned. In Generalized MPLS [RFC3473] the Notify message may additionally be used to expedite notification of failures of existing LSPs to ingress and egress LSRs, or to a specific "repair point" -- an LSR responsible for performing protection or restoration.
RSVP-TEにおいては、ブロックされたLSPセットアップは、入力、または出力（ターミネーター）に送信ResvErrに送信たPathErrメッセージをもたらすことができます。これらのメッセージは破棄されるLSP設定になることがあります。保護または回復を実行する責任LSR - 一般MPLS [RFC3473]に通知メッセージはさらに、または特定の「修理箇所」に進入するための既存のLSPの障害と出口のLSRの通知を促進するために使用することができます。
These existing mechanisms provide a certain amount of information about the path of the failed LSP.
これらの既存の機構は失敗したLSPの経路についての情報の一定量を提供します。
Generalized MPLS [RFC3471] and [RFC3473] extends MPLS into networks that manage Layer 2, TDM and lambda resources as well as packet resources. Thus, crankback routing is also useful in GMPLS networks.
一般MPLS [RFC3471]及び[RFC3473]は、レイヤ2、TDM及びラムダリソースならびにパケット・リソースを管理するネットワークにMPLSを拡張します。したがって、クランクバックルーティングは、GMPLSネットワークにおいても有用です。
In a network without wavelength converters, setup requests are likely to be blocked more often than in a conventional MPLS environment because the same wavelength must be allocated at each Optical Cross-
波長変換器なしのネットワークでは、セットアップ要求は、同じ波長が各光4クロスに割り当てなければならないので、従来のMPLS環境でより頻繁にブロックされる可能性が高いです
Connect on an end-to-end explicit path. This makes crankback routing all the more important in certain GMPLS networks.
エンド・ツー・エンドの明示的なパスに接続します。これは、特定のGMPLSネットワークにおけるルーティングのすべてのより重要なクランクバックになります。
Throughout this document, the processes and techniques are described as though the control plane and data plane elements that comprise a Label Switching Router (LSR) coreside and are related in a one-to-one manner. This is for the convenience of documentation only.
本明細書を通して、プロセスおよび技術は、ルータ（LSR）coresideスイッチングラベルを含み、一対一の方法で関連しているコントロールプレーンとデータプレーンエレメントものとして記載されています。これは、ドキュメントの便宜のためです。
It should be noted that GMPLS LSRs may be decomposed such that the control plane components are not physically collocated. Furthermore, one presence in the control plane may control more than one LSR in the data plane. These points have several consequences with respect to this document:
GMPLSのLSRは、制御プレーンの成分が物理的に同じ場所に配置されないように分解することができることに留意すべきです。さらに、制御プレーン内の1つの存在は、データプレーン内の複数のLSRを制御してもよいです。これらの点は、この文書に関して、いくつかの結果を持っています：
o The nodes, links, and resources that are reported as errors, are data plane entities.
エラーとして報告されているノード、リンク、およびリソースO、データ・プレーン・エンティティです。
o The nodes, areas, and Autonomous Systems (ASs) that report that they have attempted re-routing are control plane entities.
それらは、再ルーティングを試みていることを報告したノード、領域、および自律システム（ASの）O制御プレーンエンティティです。
o Where a single control plane entity is responsible for more than one data plane LSR, crankback signaling may be implicit in just the same way as LSP establishment signaling may be.
単一の制御プレーンエンティティは、複数のデータ・プレーンLSRの責任である場合、O、クランクバックシグナリングは、LSP確立シグナリングがあってもよいようにちょうど同じように、暗黙的であってもよいです。
The above points may be considered self-evident, but are stated here for absolute clarity.
上記の点は自明と考えることができるが、絶対明確にするためにここに記載されています。
The stylistic convenience of referring to both the control plane element responsible for a single LSR and the data plane component of that LSR simply as "the LSR" should not be taken to mean that this document is applicable only to a collocated one-to-one relationship. Furthermore, in the majority of cases, the control plane and data plane components are related in a 1:1 ratio and are usually collocated.
「LSR」は本書のみ併置一対一にも適用可能であることを意味するものと解釈されるべきではない単に単一LSRを担う制御プレーン素子及びそのLSRのデータプレーン成分の両方を参照の文体便宜関係。さらに、多くの場合に、制御プレーンとデータプレーンコンポーネントは1で関連している：1の比率と通常一緒に配置されています。
If the ingress LSR or intermediate area border LSR knows the location of the blocked link or node, it can designate an alternate path and then reissue the setup request. Determination of the identity of the blocked link or node can be achieved by the mechanism known as crankback routing [PNNI, ASH1]. In RSVP-TE, crankback signaling requires notifying the upstream LSR of the location of the blocked link or node. In some cases, this requires more information than is currently available in the signaling protocols.
入口LSRまたは中間領域境界LSRがブロックされたリンクまたはノードの位置を知っている場合は、代替パスを指定した後、設定要求を再発行することができます。ブロックされたリンクまたはノードのアイデンティティの決意は、クランクバックルーティング[PNNI、ASH1]として知られる機構によって達成することができます。 RSVP-TEにおいては、クランクバックシグナリングがブロックされたリンクまたはノードの位置の上流のLSRに通知する必要があります。いくつかのケースでは、これは、シグナリングプロトコルで現在利用可能であるよりも、より多くの情報が必要です。
On the other hand, various recovery schemes for link or node failures have been proposed in [RFC3469] and include fast re-routing. These schemes rely on the existence of a protecting LSP to protect the working LSP, but if both the working and protecting paths fail, it is necessary to re-establish the LSP on an end-to-end basis, avoiding the known failures. Similarly, fast re-routing by establishing a recovery path on demand after failure requires computation of a new LSP that avoids the known failures. End-to-end recovery for alternate routing requires the location of the failed link or node. Crankback routing schemes could be used to notify the upstream LSRs of the location of the failure.
一方、リンクまたはノードの障害のための様々な回収スキームは[RFC3469]で提案されていると高速再ルーティングを含むされています。これらのスキームは、作業LSPを保護するために保護LSPの存在に依存しているが、作業と保護パスの両方に障害が発生した場合、知られている障害を避け、エンドツーエンドでLSPを再確立する必要があります。同様に、障害が発生した後、必要に応じて回復経路を確立することにより、高速再ルーティングは、既知の障害を回避し、新たなLSPの計算を必要とします。代替ルーティングのためのエンドツーエンドの回復は、故障したリンクまたはノードの位置を必要とします。クランクバックルーティングスキームは、障害の位置の上流のLSRに通知するために使用することができます。
Furthermore, in situations where many link or node failures occur at the same time, the difference between the distributed routing information and the real-time network state becomes much greater than in normal LSP setups. LSP recovery might, therefore, be performed with inaccurate information, which is likely to cause setup blocking. Crankback routing could improve failure recovery in these situations.
さらに、多くのリンクまたはノードの障害が同時に発生した状況では、分散型ルーティング情報とリアルタイムネットワーク状態との間の差は、通常のLSPセットアップにおけるよりもはるかに大きくなります。 LSPの回復は、このため、セットアップブロッキングを引き起こす可能性がある不正確な情報、で実行されることがあります。クランクバックルーティングは、これらの状況では、障害回復を向上させることができます。
The requirement for end-to-end allocation of lambda resources in GMPLS networks without wavelength converters means that end-to-end recovery may be the only way to recover from LSP failures. This is because segment protection may be much harder to achieve in networks of photonic cross-connects where a particular lambda may already be in use on other links: End-to-end protection offers the choice of use of another lambda, but this choice is not available in segment protection.
波長変換せずGMPLSネットワークにおけるラムダリソースのエンドツーエンドの割り当てのための要件は、エンドツーエンドの回復は、LSP障害から回復する唯一の方法であり得ることを意味します。エンドツーエンドの保護は、別のラムダの使用の選択肢を提供していますが、この選択は次のとおりです。セグメント保護は、特定のラムダは、すでに他のリンク上で使用中の可能性がどこクロスコネクトフォトニックのネットワークで実現するために非常に難しくなる可能性があるためですセグメントの保護では使用できません。
This requirement makes crankback re-routing particularly useful in a GMPLS network, particularly in dynamic LSP re-routing cases (i.e., when there is no pre-establishment of the protecting LSP).
（保護LSPのいかなる事前確立がない場合、すなわち、）この要件は、特に動的LSPの再ルーティングする場合には、GMPLSネットワークにおけるクランクバック再ルーティングが特に有用です。
GMPLS uses Interior Gateway Protocols (IGPs) (OSPF and IS-IS) to flood traffic engineering (TE) information that is used to construct a traffic engineering database (TED) which acts as a data source for path computation.
GMPLSは、内部ゲートウェイプロトコル（のIGP）を使用する（OSPFおよびIS-IS）経路計算用のデータ・ソースとして作用するトラフィックエンジニアリングデータベース（TED）を構築するために使用されるトラフィック・エンジニアリング（TE）情報をフラッディングします。
Crankback signaling is not intended to supplement or replace the normal operation of the TE flooding mechanism, since these mechanisms are independent of each other. That is, information gathered from crankback signaling may be applied to compute an alternate path for the LSP for which the information was signaled, but the information is not intended to be used to influence the computation of the paths of other LSPs.
これらのメカニズムは、互いに独立しているので、クランクバックシグナリングは、TEフラッディング機構の通常の動作を補完または交換することを意図していません。すなわち、クランクバックシグナリングから収集された情報は、情報がシグナリングされたが、情報が他のLSPの経路の計算に影響を与えるために使用されることが意図されていないLSPのための代替経路を計算するために適用されてもよい、です。
Any requirement to rapidly flood updates about resource availability so that they may be applied as deltas to the TED and utilized in future path computations are out of the scope of this document.
それらはTEDのデルタとして適用され、将来の経路の計算に利用できるように迅速にリソース可用性に関する最新情報をフラッディングするために、任意の要件は、この文書の範囲外です。
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]に記載されているように解釈されます。
There have been problems in service provider networks when "inferring" from indirect information that re-routing is allowed. This document proposes the use of an explicit re-routing indication that authorizes re-routing, and contrasts it with the inferred or implicit re-routing indication that has previously been used.
再ルーティングが許可されている間接的な情報から「推測」サービスプロバイダーネットワークに問題がありました。この文書は、再ルーティングを許可する明示的な再ルーティング指示の使用を提案し、以前に使用されてきた推論または暗黙の再ルーティング指示でそれを対比します。
Various existing protocol options and exchanges, including the error values of PathErr message [RFC2205, RFC3209] and the Notify message [RFC3473], allow an implementation to infer a situation where re-routing can be performed. This allows for recovery from network errors or resource contention.
PathErrメッセージのエラー値を含む様々な既存のプロトコルオプションと交換、[RFC2205、RFC3209]と通知メッセージ[RFC3473]は、インプリメンテーションは、再ルーティングを行うことができる状況を推測することを可能にします。これは、ネットワークエラーやリソースの競合からの回復が可能になります。
However, such inference of recovery signaling is not always desirable since it may be doomed to failure. For example, experience of using release messages in TDM-based networks, for analogous implicit and explicit re-routing indications purposes provides some guidance. This background information is given in Appendix A.
それは失敗する運命にすることができるので、回復のシグナル伝達の、そのような推論は必ずしも望ましいことではありません。例えば、類似した暗黙的および明示的な再ルーティングの適応症のために、TDMベースのネットワークに解放メッセージを使用しての経験は、いくつかのガイダンスを提供します。この背景情報は、付録Aに記載されています
It is certainly the case that with topology information distribution, as performed with routing protocols such as OSPF, the ingress LSR could infer the re-routing condition. However, convergence of topology information using routing protocols is typically slower than the expected LSP setup times. One of the reasons for crankback is to avoid the overhead of available-link-bandwidth flooding, and to more efficiently use local state information to direct alternate routing to the path computation point.
確かに、トポロジ情報配信と、OSPFなどのルーティングプロトコルを用いて行われるように、入口LSRは、再ルーティング状態を推測可能性がある場合です。しかしながら、ルーティングプロトコルを使用して、トポロジ情報の収束は、典型的には、予想されるLSP設定時間よりも遅いです。クランクバック理由の1つは、利用可能なリンク帯域幅フラッディングのオーバーヘッドを回避するために、より効率的に経路計算点への代替ルーティングを指示するために局所的な状態情報を使用することです。
[ASH1] shows how event-dependent-routing can just use crankback, and not available-link-bandwidth flooding, to decide on the re-route path in the network through "learning models". Reducing this flooding reduces overhead and can lead to the ability to support much larger AS sizes.
[ASH1]イベント依存ルーティングがちょうどクランクバックを使用する方法を示しており、利用できないリンク帯域幅の氾濫、「学習モデル」を介してネットワーク内の再配線経路を決定します。この洪水を減らすことは、オーバーヘッド削減とサイズASはるかに大きくサポートする能力につながることができます。
Therefore, the use of alternate routing should be based on an explicit indication, and it is best to know the following information separately:
したがって、代替ルーティングの使用は、明示的な指示に基づくべきである、それは別々に、以下の情報を知ることが最良です。
- where blockage/congestion occurred.
- 閉塞/輻輳が発生した場所。
- whether alternate routing "should" be attempted.
- 代替ルーティングするかどうかを試みられる「べきです」。
Section 1 identifies some of the circumstances under which crankback may be useful. Crankback routing is performed as described in the following procedures, when an LSP setup request is blocked along the path or when an existing LSP fails.
セクション1は、クランクバックが有用であり得る状況下での一部を識別する。既存のLSPに障害が発生したときにLSP設定要求をパスに沿ってブロックされるかされ、以下の手順に記載のクランクバックルーティングが行われます。
When an LSP setup request is blocked due to unavailable resources, an error message response with the location identifier of the blockage should be returned to the LSR initiating the LSP setup (ingress LSR), the area border LSR, the AS border LSR, or some other repair point.
LSP設定要求が利用できないリソースが原因でブロックされたとき、閉塞の位置識別子とエラーメッセージ応答がLSP設定（入力LSR）を開始LSRに戻さなければならない、エリア境界LSR、AS境界LSR、またはいくつか他の修理ポイント。
This error message carries an error specification according to [RFC3209] -- this indicates the cause of the error and the node/link on which the error occurred. Crankback operation may require further information as detailed in Sections 3.2.1 and 6.
このエラーメッセージは、[RFC3209]に記載エラー仕様を運ぶ - これはエラーが発生したエラーおよびノード/リンクの原因を示しています。セクション3.2.1および6に詳述するようにクランクバック操作は、さらに情報を必要とするかもしれません。
A repair point (for example, an ingress LSR) that receives crankback information resulting from the failure of an established LSP may apply local policy to govern how it attempts repair of the LSP. For example, it may prioritize repair attempts between multiple LSPs that have failed, and it may consider LSPs that have been locally repaired ([RFC4090]) to be less urgent candidates for end-to-end repair. Furthermore, there is a likelihood that other LSRs are also attempting LSP repair for LSPs affected by the same fault which may give rise to resource contention within the network, so an LSR may stagger its repair attempts in order to reduce the chance of resource contention.
修復点（例えば、入口LSR）確立されたLSPの故障に起因するクランクバック情報を受け取ることがLSPの修復を試みる方法を支配するローカルポリシーを適用することができます。例えば、それは失敗している複数のLSP間の修復の試みを優先順位付けすることができる、それはエンド・ツー・エンドの修復のためのより少ない緊急候補とローカルに修復されていたLSP（[RFC4090]）を考慮することができます。 LSRは、リソース競合の可能性を低減するために、その修復の試みをずらすことができるように、また、他のLSRは、ネットワーク内で競合リソースに生じ得る同じ障害によって影響を受けたLSPのためのLSP修復を試みている可能性があります。
In a flat network without partitioning of the routing topology, when the ingress LSR receives the error message, it computes an alternate path around the blocked link or node to satisfy QoS guarantees using link state information about the network. If an alternate path is found, a new LSP setup request is sent over this path.
入口LSRは、エラーメッセージを受信するルーティングトポロジの分割せずにフラットネットワークでは、ネットワークについてのリンク状態情報を使用してQoS保証を満たすためにブロックされたリンクまたはノードの周りの代替経路を計算します。代替パスが見つかった場合、新しいLSP設定要求は、このパスを介して送信されます。
On the other hand, in a network partitioned into areas such as with OSPF, the area border LSR may intercept and terminate the error response, and perform alternate (re-)routing within the downstream area.
一方、OSPFと同様に領域に分割ネットワークにおいて、エリア境界LSRを傍受し、エラー応答を停止、および下流領域内の代替（再）ルーティングを実行することができます。
In a third scenario, any node within an area may act as a repair point. In this case, each LSR behaves much like an area border LSR as described above. It can intercept and terminate the error response and perform alternate routing. This may be particularly useful where domains of computation are applied within the (partitioned) network, where such domains are not coincident on the routing partition boundaries. However if, all nodes in the network perform re-routing it is possible to spend excessive network and CPU resources on re-routing attempts that would be better made only at designated re-routing nodes. This scenario is somewhat like 'MPLS fast re-route' [RFC4090], in which any node in the MPLS domain can establish 'local repair' LSPs upon failure notification.
第3のシナリオでは、エリア内の任意のノードは、修復点として作用することができます。上述したように、この場合に、各LSRは、はるかにエリア境界LSRのように振る舞います。これは、傍受し、エラー応答を終了し、代替ルーティングを行うことができます。計算のドメインはそのようなドメインは、ルーティングパーティションの境界に一致しない（パーティション）ネットワーク内で適用される場合、これは特に有用であり得ます。しかし、ネットワーク内のすべてのノードが実行し、あれば良いだけで指定された再ルーティングノードで行われることになるの再ルーティングの試みに過度のネットワークおよびCPUリソースを費やすことが可能である再ルーティングします。このシナリオとは、MPLSドメイン内の任意のノードが障害通知時に「ローカル修復」LSPを確立することができ、「MPLS高速再ルート」[RFC4090]のように幾分あります。
In order to correctly compute a route that avoids the blocking problem, a repair point LSR must gather as much crankback information as possible. Ideally, the repair node will be given the node, link, and reason for the failure.
正しく、ブロッキングの問題を回避した経路を計算するために、修理ポイントLSRは、できるだけ多くのクランクバックの情報を収集する必要があります。理想的には、修理のノードが障害のノード、リンク、およびその理由が与えられます。
The reason for the failure may provide an important discriminator to help decide what action should be taken. For example, a failure that indicates "No Route to Destination" is likely to give rise to a new path computation excluding the reporting LSR, but the reason "Temporary Control Plane Congestion" might lead to a simple retry after a suitable pause.
失敗の理由は、実行するアクションを決定するのを助けるために重要な弁別を提供することができます。例えば、「目的地へのルート」を示していない障害が報告LSRを除く新しい経路計算を生じさせる可能性があるが、その理由「一時的なコントロールプレーンの輻輳が」適当な一時停止した後、単純な再試行につながる可能性があります。
However, even this information may not be enough to help with re-computation. Consider for instance an explicit route that contains a non-explicit abstract node or a loose hop. In this case, the failed node and link are not necessarily enough to tell the repair point which hop in the explicit route has failed. The crankback information needs to indicate where, within the explicit route, the problem has occurred.
しかし、この情報は再計算を支援するために十分ではないかもしれません。例えば、非明示的な抽象ノードまたはルーズホップを含ま明示的ルートを考えます。この場合、故障したノードとリンクが必ずしも明示的なルートでのホップが失敗した修理ポイントを教えには十分ではありません。クランクバックの情報は、明示的なルートの中に、問題が発生した場所を、示す必要があります。
If the crankback information can be used to compute a new route avoiding the failed/blocking network resource, the route can be signaled as an Explicit Route.
クランクバック情報が失敗した/ブロッキングネットワークリソースを避けて新しいルートを計算するために使用することができた場合、ルートは明示的なルートとしてシグナリングすることができます。
However, it may be that the repair point does not have sufficient topology information to compute an Explicit Route that is guaranteed to avoid the failed link or node. In this case, Route Exclusions [RFC4874] may be particularly helpful. To achieve this, [RFC4874] allows the crankback information to be presented as route exclusions to force avoidance of the failed node, link, or resource.
しかし、それは修理ポイントが失敗したリンクまたはノードを回避するために保証されている明示的なルートを計算するために十分なトポロジ情報を持たないことかもしれません。この場合、ルート除外[RFC4874]は特に有用であり得ます。これを達成するために、[RFC4874]は、ルートの除外が失敗したノード、リンク、またはリソースの回避を強制するようにクランクバック情報が提示されることを可能にします。
The repair point LSR that computes the alternate path should store the location identifiers of the blockages indicated in the error message until the LSP is successfully established by downstream LSRs or until the repair point LSR abandons re-routing attempts. Since crankback signaling information may be returned to the same repair point LSR more than once while establishing a specific LSP, the repair point LSR SHOULD maintain a history table of all experienced blockages for this LSP (at least until the routing protocol updates the state of this information) so that the resulting path computation(s) can detour all blockages.
LSPが正常下流のLSRによって、または修理点LSR再ルーティング試行を放棄するまで確立されるまでの代替経路を計算修復ポイントLSRは、エラーメッセージに示された閉塞の位置識別子を保存するべきです。クランクバックシグナリング情報は、特定のLSPを確立しながら、修復ポイントLSRは、ルーティングプロトコルが、この状態を更新する少なくともまで、このLSP（のためのすべての経験豊富な閉塞の履歴テーブルを維持しなければならない回以上同じ修復点LSRに戻すことができるので情報）が得られた経路計算（S）は、すべての閉塞を迂回することができるように。
If a second error response is received by a repair point (while it is performing crankback re-routing) it should update the history table that lists all experienced blockages, and use the entire gathered information when making a further re-routing attempt.
第2のエラー応答が修復ポイントによって受信された場合は、すべての経験豊富な閉塞を一覧表示履歴テーブルを更新し、さらに再ルーティング試行の際全体が情報を収集し使用するべきである（それはクランクバック再ルーティングを行っている間）。
Note that the purpose of this history table is to correlate information when repeated retry attempts are made by the same LSR. For example, suppose that an attempt is made to route from A through B, and B returns a failure with crankback information, an attempt may be made to route from A through C, and this may also fail with the return of crankback information. The next attempt SHOULD NOT be to route from A through B, and this may be achieved by use of the history table.
この履歴テーブルの目的は、繰り返し再試行が同じLSRによって行われたときの情報を関連付けることであることに留意されたいです。例えば、試みがBを介してからルーティングするために作られ、そしてBは、クランクバック情報と失敗を返し、試みがCを介してからルーティングするために行うことができる、これはまた、クランクバック情報の戻りで失敗することがあり仮定する。次の試みは、Bを介してAからルーティングするべきではなく、これは、履歴テーブルの使用によって達成することができます。
The history table can be discarded by the signaling controller for A if the LSP is successfully established through A. The history table MAY be retained after the signaling controller for A sends an error upstream, however the value this provides is questionable since a future retry as a result of crankback re-routing should not attempt to route through A. If the history information is retained for a longer period it SHOULD be discarded after a local timeout has expired. This timer is required so that the repair point does not apply the history table to an attempt by the ingress to re-establish a failed LSP, but to allow the history table to be available for use in re-routing attempts before the ingress declares the LSP as failed.
LSPが正常にAのシグナリングコントローラは、上流エラーを送信した後、履歴テーブルは、将来のようにリトライするので、これが提供ただし値が疑わしい、保持されてもよいA.を介して確立されている場合、履歴テーブルは、Aのシグナリングコントローラによって廃棄することができます履歴情報は、ローカルのタイムアウトが経過した後にそれが破棄されるべき長い期間保持されている場合はクランクバックの再ルーティングの結果はA.経由ルートに試みるべきではありません。修理ポイントが失敗したLSPを再確立するために侵入の試みに履歴テーブルを適用しませんが、侵入を宣言する前に履歴テーブルが再ルーティングの試みで使用できるようにすることを可能にするように、このタイマーは必要とされます失敗したとしてLSP。
It is RECOMMENDED that the repair point LSR discard the history table using a timer no larger than the LSP retry timer configured on the ingress LSR. The correlation of the timers between the ingress and repair point LSRs is typically by manual configuration of timers local to each LSR, and is outside the scope of this document.
修理ポイントLSRがイングレスLSRに設定されたLSPリトライタイマーよりも大きくないタイマーを使用して履歴テーブルを破棄することが推奨されます。入口および修復ポイントのLSR間タイマーの相関は、各LSRへのローカルタイマーを手動で構成することにより、典型的には、この文書の範囲外です。
The information in the history table is not intended to supplement the TED for the computation of paths of other LSPs.
履歴テーブル内の情報は、他のLSPのパスの計算のためのTEDを補完するものではありません。
Multiple blockages (for the same LSP) may occur, and successive setup retry attempts may fail. Retaining error information from previous attempts ensures that there is no thrashing of setup attempts, and knowledge of the blockages increases with each attempt.
（同じLSPのための）複数の閉塞が発生する可能性があり、そして連続セットアップの再試行が失敗することがあります。以前の試みからのエラー情報を保持する設定試みはスラッシングが存在しないことを確実にし、閉塞の知識は、各試行に伴って増加します。
It may be that after several retries, a given repair point is unable to compute a path to the destination (that is, the egress of the LSP) that avoids all of the blockages. In this case, it must pass an error indication message upstream. It is most useful to the upstream nodes (and in particular to the ingress LSR) that may repair points for the LSP setup, if the error indication message identifies all of the downstream blockages and also the repair point that was unable to compute an alternate path.
これは、いくつかの試行後、所定の補修点は目的地までの経路を計算することができないことであり得る（すなわち、LSPの出口）閉塞の全てを回避します。この場合には、上流側のエラー表示メッセージを通過しなければなりません。これは、エラー表示メッセージは、代替経路を計算することができませんでした下流閉塞及び修理箇所の全てを識別する場合、LSPセットアップの点を修復することができる（入口LSRに特に）最も上流のノードに有用です。
It is important to prevent endless repetition of LSP setup attempts using crankback routing information after error conditions are signaled, or during periods of high congestion. It may also be useful to reduce the number of retries, since failed retries will increase setup latency and degrade performance by increasing the amount of signaling processing and message exchanges within the network.
エラー条件は、または高輻輳期間中に通知された後、ルーティング情報をクランクバックを使用してLSPセットアップ試行の無限の繰り返しを防止することが重要です。失敗した試行が設定待ち時間を増加させ、ネットワーク内の処理とメッセージ交換シグナリングの量を増加させることによって性能を劣化させるので、また、再試行の回数を減少させるのに有用であり得ます。
The maximum number of crankback re-routing attempts that are allowed may be limited in a variety of ways. This document allows an LSR to limit the retries per LSP, and assumes that such a limit will be applied either as a per-node configuration for those LSRs that are capable of re-routing, or as a network-wide configuration value.
許可されているクランクバック再ルーティング試行の最大数は、様々な方法で制限されてもよいです。この文書では、LSRは、LSPごとの再試行を制限することができ、そのような制限は、再ルーティングすることが可能であるもののLSRごとのノードの構成として、またはネットワーク全体の設定値のいずれかとして適用されることを想定しています。
When the number of retries at a particular LSR is exceeded, the LSR will report the failure in an upstream direction until it reaches the next repair point where further re-routing attempts may be attempted, or it reaches the ingress which may act as a repair point or declare the LSP as failed. It is important that the crankback information this is provided indicates that routing back through this node will not succeed; this situation is similar to that in Section 3.4.
特定のLSRでリトライ回数を超えた場合、それはさらに、再ルーティング試行が試行されてもよい次の修理ポイントに到達する、またはそれが修復として作用し得る入口に到達するまで、LSRは、上流方向に失敗を報告しますポイントまたは失敗したとしてLSPを宣言する。提供されてクランクバックの情報は、このノードを経由して戻ってルーティングが成功しないことを示していることが重要です。このような状況は、3.4節と同様です。
Crankback re-routing is appropriate for use with RSVP-TE.
クランクバック再ルーティングはRSVP-TEでの使用に適しています。
1) LSP establishment may fail because of an inability to route, perhaps because links are down. In this case a PathErr message is returned to the ingress.
1）LSPの確立は、リンクがダウンしているためか、なぜならルーティングすることができないことで失敗する可能性があります。この場合のPathErrメッセージは、侵入に返されます。
2) LSP establishment may fail because resources are unavailable. This is particularly relevant in GMPLS where explicit label control may be in use. Again, a PathErr message is returned to the ingress.
リソースが使用できないため、2）LSPの確立が失敗する可能性があります。これは明白なラベルコントロールが使用されている可能性がGMPLSに特に関連します。ここでも、たPathErrメッセージは、侵入に返されます。
3) Resource reservation may fail during LSP establishment, as the Resv is processed. If resources are not available on the required link or at a specific node, a ResvErr message is returned to the egress node indicating "Admission Control failure" [RFC2205]. The egress is allowed to change the FLOWSPEC and try again, but in the event that this is not practical or not supported (particularly in the non-PSC context), the egress LSR may choose to take any one of the following actions.
Resvが処理されるように3）リソース予約は、LSPの確立中に失敗する可能性があります。リソースが必要なリンクまたは特定のノードで利用できない場合、ResvErrメッセージは、「アドミッション制御不良」[RFC2205]を示す出口ノードに戻されます。出口は、FLOWSPECを変更して再試行を許可されていますが、これは（特に非PSC文脈で）サポート実用的でないでない場合には、出力LSRは次のアクションのいずれかを取ることを選択することができます。
- Ignore the situation and allow recovery to happen through Path refresh message and refresh timeout [RFC2205].
- 状況を無視して回復がパスのリフレッシュメッセージとリフレッシュタイムアウト[RFC2205]を通じて起こることができます。
- Send a PathErr message towards the ingress indicating "Admission Control failure".
- 「アドミッション制御の失敗」を示す入に向けたPathErrメッセージを送信します。
Note that in multi-area/AS networks, the ResvErr might be intercepted and acted on at an area/AS border router.
マルチエリア/ネットワークとして、ResvErrが傍受される可能性があり、境界ルータAS /地域での作用を受けることに注意してください。
4) It is also possible to make resource reservations on the forward path as the Path message is processed. This choice is compatible with LSP setup in GMPLS networks [RFC3471], [RFC3473]. In this case, if resources are not available, a PathErr message is returned to ingress indicating "Admission Control failure".
4）Pathメッセージが処理されるように、順方向パス上のリソースを予約することも可能です。この選択は、GMPLSネットワークにおけるLSP設定[RFC3471]、[RFC3473]と互換性があります。リソースが利用できない場合この場合、のPathErrメッセージは、「アドミッション制御の失敗」を示す進入することが返されます。
Crankback information would be useful to an upstream node (such as the ingress) if it is supplied on a PathErr or a Notify message that is sent upstream.
クランクバック情報は、それがのPathErrに供給または上流送信されるメッセージを通知された場合、上流ノード（例えば入口など）に有用であろう。
In RSVP-TE, a failed LSP setup attempt results in a PathErr message returned upstream. The PathErr message carries an ERROR_SPEC object, which indicates the node or interface reporting the error and the reason for the failure.
RSVP-TEにおいて、のPathErrメッセージに失敗したLSPセットアップの試行結果は、上流返さ。たPathErrメッセージは、エラーおよび障害の理由を報告しているノードまたはインタフェースを示すERROR_SPECオブジェクトを運びます。
Crankback re-routing can be performed explicitly avoiding the node or interface reported.
クランクバックの再ルーティングは、報告されたノードまたはインタフェースを回避明示的に行うことができます。
GMPLS extends the error reporting described above by allowing LSRs to report the interface that is in error in addition to the identity of the node reporting the error. This further enhances the ability of a re-computing node to route around the error.
GMPLSは、のLSRがエラーを報告しているノードの識別に加えて、エラーのあるインターフェースを報告できるようにすることで、上述したエラー報告を拡張します。これにより、エラーの周りにルートを再計算ノードの能力を高めます。
GMPLS introduces a targeted Notify message that may be used to report LSP failures direct to a selected node. This message carries the same error reporting facilities as described above. The Notify message may be used to expedite the propagation of error notifications, but in a network that offers crankback routing at multiple nodes there would need to be some agreement between LSRs as to whether PathErr or Notify provides the stimulus for crankback operation. This agreement is constrained by the re-routing behavior selection (as listed in Section 5.4). Otherwise, multiple nodes might attempt to repair the LSP at the same time, because:
GMPLSは、選択されたノードに直接LSP障害を報告するために使用されてもよい通知ターゲットメッセージを導入します。上述したように、このメッセージは、同じエラー報告機能を運びます。通知メッセージは、エラー通知の伝播を促進するために使用することができるが、複数のノードにルーティングクランクバックを提供するネットワークに存在するかどうかのPathErrに関してLSRの間にいくつかの合意する必要があり、またはクランクバック動作のための刺激を提供する通知だろう。この契約は、再ルーティング動作の選択（第5.4節に記載されている）によって制約されます。それ以外の場合は、複数のノードは、同時にLSPを修復しようとする理由かもしれません。
1) these messages can flow through different paths before reaching the ingress LSR, and
1）これらのメッセージは、入口LSRに到達する前に異なる経路を通って流れることができる、及び
2) the destination of the Notify message might not be the ingress LSR.
2）通知メッセージの宛先は、入口LSRではないかもしれません。
Section B : Solution
セクションB：ソリューション
When a request is made to set up an LSP tunnel, the ingress LSR should specify whether it wants crankback information to be collected in the event of a failure, and whether it requests re-routing attempts by any or specific intermediate nodes. For this purpose, a Re-routing Flag field is added to the protocol setup request messages. The corresponding values are mutually exclusive.
要求がLSPトンネルを設定するように構成されている場合、入口LSRは、クランクバック情報は、障害が発生した場合に収集することができることを望むかどうかを指定する必要があり、それは、任意のまたは特定の中間ノードによる再ルーティング試行を要求するかどうか。この目的のために、再ルーティングフラグフィールドは、プロトコル設定要求メッセージに追加されます。対応する値は、相互に排他的です。
No Re-routing The ingress node MAY attempt re-routing after failure. Intermediate nodes SHOULD NOT attempt re-routing after failure. Nodes detecting failures MUST report an error and MAY supply crankback information. This is the default and backwards compatible option.
いいえ入口ノードを再ルーティングしないと、障害が発生した後に再ルーティングを試みるかもしれません。中間ノードは、障害発生後に再ルーティングを試みるべきではありません。障害を検出ノードは、エラーを報告しなければなりませんし、クランクバックの情報を供給することができます。これがデフォルトと下位互換性オプションです。
End-to-end Re-routing The ingress node MAY attempt re-routing after failure. Intermediate nodes SHOULD NOT attempt re-routing after failure.
エンドツーエンドの入口ノードは、障害が発生した後に再ルーティングを試みるかもしれない再ルーティング。中間ノードは、障害発生後に再ルーティングを試みるべきではありません。
Nodes detecting failures MUST report an
error and SHOULD supply crankback
information.
Boundary Re-routing Intermediate nodes MAY attempt re-routing after failure only if they are Area Border Routers or AS Border Routers (ABRs/ASBRs). The boundary (ABR/ASBR) can either decide to forward the error message upstream to the ingress LSR or try to select another egress boundary LSR. Other intermediate nodes SHOULD NOT attempt re-routing. Nodes detecting failures MUST report an error and SHOULD supply crankback information.
境界中間ノードを再ルーティングすることは、彼らが（のABR / ASBRは）エリア境界ルータまたは境界ルータなどの場合にのみ、障害発生後に再ルーティングを試みるかもしれません。境界（ABR / ASBR）は、入口LSRに上流のエラーメッセージを転送するか、別の出口境界LSRを選択しようとすることを決定することができます。他の中間ノードは、再ルーティングを試みるべきではありません。障害を検出ノードは、エラーを報告しなければなりませんし、クランクバックの情報を提供する必要があります。
Segment-based Re-routing Any node MAY attempt re-routing after it receives an error report and before it passes the error report further upstream. Nodes detecting failures MUST report an error and SHOULD supply full crankback information.
セグメントベースの再ルーティングがエラーレポートを受信した後、再ルーティングを試みる可能性のあるノードを、それが通過する前に、エラーレポートがさらに上流。障害を検出ノードは、エラーを報告しなければなりませんし、完全なクランクバックの情報を提供する必要があります。
A node that detects the failure to setup an LSP or the failure of an established LSP SHOULD act according to the Re-routing Flag passed on the LSP setup request.
セットアップするLSPまたは確立されたLSPの故障を故障を検出したノードは、LSP設定要求に渡される再ルーティングフラグに応じて行動しなければなりません。
If Segment-based Re-routing is allowed, or if Boundary Re-routing is allowed and the detecting node is an ABR or ASBR, the detecting node MAY immediately attempt to re-route.
セグメントベースの再ルーティングが許可されている場合、または境界再ルーティングさせ、検出ノードがABRまたはASBRである場合、検出ノードは即座に再ルーティングすることを試みることができます。
If End-to-end Re-routing is indicated, or if Segment-based or Boundary Re-routing is allowed and the detecting node chooses not to make re-routing attempts (or has exhausted all possible re-routing attempts), the detecting node MUST return a protocol error indication and SHOULD include full crankback information.
エンドツーエンドの再ルーティングが示された場合、セグメント・ベースの場合や、または、検出する境界再ルーティングが許可され、検出ノードは、再ルーティング試行をしないように選択した（またはすべての可能な再ルーティング試行を使い果たしました）ノードは、プロトコルエラー表示を返す必要があり、完全なクランクバック情報を含めるべきです。
Each repair point SHOULD apply a locally configurable limit to the number of attempts it makes to re-route an LSP. This helps to prevent excessive network usage in the event of significant faults, and allows back-off to other repair points which may have a better chance of routing around the problem.
各リペアポイントは、LSP再ルーティングすることを可能にする試みの数に局所的に設定可能な制限が適用されるべきです。これは重大な障害が発生した場合に、過剰なネットワークの使用状況を防ぐのに役立ち、そして問題を回避ルーティングのよりよいチャンスを有することができる他の修理ポイントにバックオフすることができます。
An error code/value of "Routing Problem"/"Re-routing limit exceeded" (24/22) is used to identify that a node has abandoned crankback re-routing because it has reached a threshold for retry attempts.
「ルーティング問題」/「超過再ルーティング制限」（22分の24）のエラーコード/値は、それが再試行のための閾値に達したため、ノードは、クランクバック再ルーティングを放棄したことを識別するために使用されます。
A node receiving an error response with this status code MAY also attempt crankback re-routing, but it is RECOMMENDED that such attempts be limited to the ingress LSR.
このステータスコードとエラー応答を受信したノードは、クランクバック再ルーティングを試みるかもしれないが、このような試みは、入口LSRに限定されることが推奨されます。
The LSP_ATTRIBUTES object defined in [RFC4420] is used on Path messages to convey the Re-Routing Flag described in Section 4.1. Three bits are defined for inclusion in the LSP Attributes TLV as follows. The bit numbers below have been assigned by IANA.
[RFC4420]で定義されLSP_ATTRIBUTESオブジェクトは再ルーティングフラグは、セクション4.1に記載し伝達するためにPathメッセージに使用されます。次のようにLSPに含めることがTLV属性のための3つのビットが定義されています。以下のビット数は、IANAによって割り当てられています。
Bit Name and Usage Number
ビット名と使用数
1 End-to-end re-routing desired. This flag indicates the end-to-end re-routing behavior for an LSP under establishment. This MAY also be used for specifying the behavior of end-to-end LSP recovery for established LSPs.
1エンドツーエンドの再ルーティングが望ま。このフラグは、確立下LSPのエンドツーエンドの再ルーティング動作を示しています。また、これは確立したLSPのためのエンドツーエンドのLSP回復の動作を指定するために使用されるかもしれません。
2 Boundary re-routing desired. This flag indicates the boundary re-routing behavior for an LSP under establishment. This MAY also be used for specifying the segment-based LSP recovery through nested crankback for established LSPs. The boundary ABR/ASBR can either decide to forward the PathErr message upstream to an upstream boundary ABR/ASBR or to the ingress LSR. Alternatively, it can try to select another egress boundary LSR.
2境界再ルーティングが望ま。このフラグは、確立下LSPに対する境界再ルーティング動作を示しています。これはまた、確立されたLSPのためのネストされたクランクバックを介してセグメント・ベースのLSP回復を指定するために使用されるかもしれません。境界ABR / ASBRは、上流境界ABR / ASBRにまたはイングレスLSRに上流のPathErrメッセージを転送することを決定することができます。また、それは別の出口境界LSRを選択しようとすることができます。
3 Segment-based re-routing desired. This flag indicates the segment-based re-routing behavior for an LSP under establishment. This MAY also be used to specify the segment-based LSP recovery for established LSPs.
3セグメント・ベースの再ルーティングが望ま。このフラグは、確立下LSPのためのセグメント・ベースの再ルーティング動作を示しています。また、これは確立したLSPのためのセグメントベースのLSP回復を指定するために使用されるかもしれません。
As described above, full crankback information SHOULD indicate the node, link, and other resources, which have been attempted but have failed because of allocation issues or network failure.
上述したように、完全なクランクバック情報が試みられているが、理由割当の問題やネットワーク障害の失敗したノード、リンク、およびその他のリソースを示すべきです。
The default crankback information SHOULD include the interface and the node address.
デフォルトのクランクバックの情報は、インタフェースとノードアドレスを含むべきです。
Any address reported in such crankback information SHOULD be an address that was distributed by the routing protocols (OSPF and IS-IS) in their TE link state advertisements. However, some additional information such as component link identifiers is additional to this.
そのようなクランクバック情報に報告任意のアドレスは、そのTEリンク状態アドバタイズメントにルーティングプロトコルによって分配（OSPFおよびIS-IS）したアドレスでなければなりません。しかし、そのようなコンポーネントリンク識別子として、いくつかの追加情報がこれに追加されます。
[RFC3473] defines an IF_ID ERROR_SPEC object that can be used on PathErr, ResvErr and Notify messages to convey the information carried in the Error Spec Object defined in [RFC3209]. Additionally, the IF_ID ERROR_SPEC Object has the scope for carrying TLVs that identify the link associated with the error.
[RFC3473]は[RFC3209]で定義されたオブジェクト仕様のPathErr、ResvErrに使用され、エラーで搬送される情報を伝えるためのメッセージを通知することができるIF_ID ERROR_SPECオブジェクトを定義します。また、IF_ID ERROR_SPECオブジェクトは、エラーに関連付けられたリンクを特定TLVを運ぶための範囲を有しています。
The TLVs for use with this object are defined in [RFC3471], and are listed below. They are used in two places. In the IF_ID RSVP_HOP object they are used to identify links. In the IF_ID ERROR_SPEC object they are used to identify the failed resource which is usually the downstream resource from the reporting node.
この目的で使用するためのTLVは[RFC3471]で定義され、以下に記載されています。彼らは2つの場所で使用されています。 IF_ID RSVP_HOPオブジェクトでは、彼らはリンクを識別するために使用されています。 IF_ID ERROR_SPECオブジェクトでは、それらは通常、レポートノードから下流のリソースである失敗したリソースを識別するために使用されます。
Type Length Format Description
--------------------------------------------------------------------
1 8 IPv4 Addr. IPv4 (Interface address)
2 20 IPv6 Addr. IPv6 (Interface address)
3 12 Compound IF_INDEX (Interface index)
4 12 Compound COMPONENT_IF_DOWNSTREAM (Component interface)
5 12 Compound COMPONENT_IF_UPSTREAM (Component interface)
Note that TLVs 4 and 5 are obsoleted by [RFC4201] and SHOULD NOT be used to identify component interfaces in IF_ID ERROR_SPEC objects.
TLVの4及び5は、[RFC4201]によって廃止されIF_ID ERROR_SPECオブジェクト内のコンポーネントのインターフェイスを識別するために使用されるべきではないことに注意してください。
In order to facilitate reporting of crankback information, the following additional TLVs are defined.
クランクバック情報の報告を容易にするために、次の追加のTLVが定義されています。
Type Length Format Description
--------------------------------------------------------------------
6 var See below DOWNSTREAM_LABEL (GMPLS label)
7 var See below UPSTREAM_LABEL (GMPLS label)
8 8 See below NODE_ID (TE Router ID)
9 x See below OSPF_AREA (Area ID)
10 x See below ISIS_AREA (Area ID)
11 8 See below AUTONOMOUS_SYSTEM (Autonomous system)
12 var See below ERO_CONTEXT (ERO subobject)
13 var See below ERO_NEXT_CONTEXT (ERO subobjects)
14 8 IPv4 Addr. PREVIOUS_HOP_IPv4 (Node address)
15 20 IPv6 Addr. PREVIOUS_HOP_IPv6 (Node address)
16 8 IPv4 Addr. INCOMING_IPv4 (Interface address)
17 20 IPv6 Addr. INCOMING_IPv6 (Interface address)
18 12 Compound INCOMING_IF_INDEX (Interface index)
19 var See below INCOMING_DOWN_LABEL (GMPLS label)
20 var See below INCOMING_UP_LABEL (GMPLS label)
21 8 See below REPORTING_NODE_ID (Router ID)
22 x See below REPORTING_OSPF_AREA (Area ID)
23 x See below REPORTING_ISIS_AREA (Area ID)
24 8 See below REPORTING_AS (Autonomous system)
25 var See below PROPOSED_ERO (ERO subobjects)
26 var See below NODE_EXCLUSIONS (List of nodes)
27 var See below LINK_EXCLUSIONS (List of interfaces)
For types 1, 2, and 3 the format of the Value field is already defined in [RFC3471].
タイプ1、2、及び3の値フィールドのフォーマットは、すでに[RFC3471]で定義されています。
For types 14 and 16, the format of the Value field is the same as for type 1.
タイプ14及び16の場合、値フィールドのフォーマットは、タイプ1の場合と同じです。
For types 15 and 17, the format of the Value field is the same as for type 2.
タイプ15及び17の場合、値フィールドのフォーマットは、タイプ2の場合と同じです。
For type 18, the format of the Value field is the same as for type 3.
タイプ18のために、値フィールドのフォーマットは、タイプ3の場合と同じです。
For types 6, 7, 19, and 20, the length field is variable and the Value field is a label as defined in [RFC3471]. As with all uses of labels, it is assumed that any node that can process the label information knows the syntax and semantics of the label from the context. Note that all TLVs are zero-padded to a multiple of four octets so that if a label is not itself a multiple of four octets, it must be disambiguated from the trailing zero pads by knowledge derived from the context.
タイプ6、7、19、及び20のため、長さフィールドは、可変であり、値フィールドは、[RFC3471]で定義されたラベルです。ラベルのすべての使用と同じように、ラベル情報を処理できる任意のノードが文脈からラベルの構文と意味を知っているものとします。ラベルは4つのオクテットの倍数自体でない場合、それは文脈から誘導された知識によって後続ゼロパッドから明確化されなければならないように、すべてのTLVは4つのオクテットの倍数にゼロパディングであることに留意されたいです。
For types 8 and 21, the Value field has the format:
タイプ8と21の場合、値フィールドの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router ID: 32 bits
ルータID：32ビット
The TE Router ID (TLV type 8) or the Router ID (TLV type 21) used to identify the node within the IGP.
TEルータID（TLVタイプ8）またはルータID（TLVタイプ21）がIGP内のノードを識別するために使用されます。
For types 9 and 22, the Value field has the format:
タイプ9および22の場合は、値フィールドの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Area Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OSPF Area Identifier
OSPFエリア識別子
The 4-octet area identifier for the node. This identifies the area where the failure has occurred.
ノードの4オクテット領域識別子。これは、障害が発生している地域を特定します。
For types 10 and 23, the Value field has the format:
タイプ10と23の場合は、値フィールドの形式は次のとおりです。
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 | IS-IS Area Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IS-IS Area Identifier (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
長さ
Length of the actual (non-padded) IS-IS Area Identifier in octets. Valid values are from 2 to 11 inclusive.
（非パディング）の実際の長さをオクテット単位でエリア識別子-あります。有効な値は2から11包括的にしています。
IS-IS Area Identifier
エリア識別子IS-IS
The variable-length IS-IS area identifier. Padded with trailing zeroes to a four-octet boundary.
可変長領域識別子です。 4オクテット境界にゼロを末尾で埋め。
For types 11 and 24, the Value field has the format:
タイプ11と24の場合は、値フィールドの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Autonomous System Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Autonomous System Number: 32 bits
自律システム番号：32ビット
The AS Number of the associated Autonomous System. Note that if 16-bit AS numbers are in use, the low order bits (16 through 31) should be used and the high order bits (0 through 15) should be set to zero.
関連する自律システムのAS番号。 AS番号16ビットが使用されている場合、下位ビット（31 16〜）が使用されるべきであり、上位ビット（0〜15）がゼロに設定されるべきであることに留意されたいです。
For types 12, 13, and 25, the Value field has the format:
タイプ12、13、及び25の場合、値フィールドのフォーマットを有します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ERO Subobjects ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ERO Subobjects:
EROサブオブジェクト：
A sequence of Explicit Route Object (ERO) subobjects. Any ERO subobjects are allowed whether defined in [RFC3209], [RFC3473], or other documents. Note that ERO subobjects contain their own types and lengths.
明示的ルート・オブジェクト（ERO）サブオブジェクトの配列。任意EROサブオブジェクトは、[RFC3473]、[RFC3209]で定義されたか否かを許可、または他の文書です。 EROサブオブジェクトが自分のタイプと長さが含まれていることに注意してください。
For type 26, the Value field has the format:
タイプ26の場合は、値フィールドの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Node Identifiers ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node Identifiers:
ノード識別子：
A sequence of TLVs as defined here of types 1, 2, or 8 that indicates downstream nodes that have already participated in crankback attempts and have been declared unusable for the current LSP setup attempt. Note that an interface identifier may be used to identify a node.
既にクランクバックの試みに参加しており、現在のLSPセットアップの試行のために使用不可能と宣言されている下流ノードを示すタイプ1,2、または8のここで定義した通りのTLVの配列。インターフェース識別子がノードを識別するために使用されてもよいことに留意されたいです。
For type 27, the Value field has the format:
タイプ27の場合は、値フィールドの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Link Identifiers ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link Identifiers:
リンク識別子：
A sequence of TLVs as defined here of the same format as type 1, 2 or 3 TLVs that indicate incoming interfaces at downstream nodes that have already participated in crankback attempts and have been declared unusable for the current LSP setup attempt.
タイプ1と同じ形式でここで定義した通りのTLVの配列、既にクランクバックの試みに参加しており、現在のLSPセットアップの試行のために使用不可能と宣言されている下流ノードの受信インターフェイスを示す2つまたは3つのTLV。
If crankback is not being used, inclusion of an IF_ID ERROR_SPEC object in PathErr, ResvErr, and Notify messages follows the processing rules defined in [RFC3473] and [RFC4201]. A sender MAY include additional TLVs of types 6 through 27 to report crankback information for informational/monitoring purposes.
クランクバックが使用されていない場合、のPathErr、ResvErrにIF_ID ERROR_SPECオブジェクトの包含、および通知メッセージは、[RFC3473]及び[RFC4201]で定義された処理規則に従います。送信者は、情報提供/監視目的のためにクランクバック情報を報告するために27を介してタイプ6の追加のTLVを含むかもしれません。
If crankback is being used, the sender of a PathErr, ResvErr, or Notify message MUST use the IF_ID ERROR_SPEC object and MUST include at least one of the TLVs in the range 1 through 3 as described in [RFC3473], [RFC4201], and the previous paragraph. Additional TLVs SHOULD also be included to report further information. The following section gives advice on which TLVs should be used under different circumstances, and which TLVs must be supported by LSRs.
クランクバックはIF_ID ERROR_SPECオブジェクトを使用しなければならなくて、[RFC3473]に記載されているように3までの範囲1のTLVの少なくとも一つを含まなければなりません、[RFC4201]、および、のPathErr、ResvErrの送信者を使用する、またはメッセージを通知されている場合前の段落。追加のTLVは、さらなる情報を報告するために含まれるべきです。次のセクションでは、のTLVは、異なる状況下で使用されるべきで助言を与え、これのTLVは、LSRのによってサポートされなければなりません。
Note that all such additional TLVs are optional and MAY be omitted. Inclusion of the optional TLVs SHOULD be performed where doing so helps to facilitate error reporting and crankback. The TLVs fall into three categories: those that are essential to report the error, those that provide additional information that is or may be fundamental to the utility of crankback, and those that provide additional information that may be useful for crankback in some circumstances.
すべてのそのような追加のTLVはオプションであり、省略してもよいです。そうすることがエラー報告とクランクバックを容易にすることができますどこのオプションのTLVを含めると、実行する必要があります。 TLVは、次の3つのカテゴリに分類されます。エラーを報告するために不可欠なものであり、またはクランクバックの有用性に基本的なことがあり、追加情報を提供するもの、およびいくつかの状況でクランクバックのために有用である可能性がある追加情報を提供するもの。
Note that all LSRs MUST be prepared to receive and forward any TLV as per [RFC3473]. This includes TLVs of type 4 or 5 as defined in [RFC3473] and obsoleted by [RFC4201]. There is, however, no requirement for an LSR to actively process any but the TLVs defined in [RFC3473]. An LSR that proposes to perform crankback re-routing SHOULD support receipt and processing of all of the fundamental crankback TLVs, and is RECOMMENDED to support the receipt and processing of the additional crankback TLVs.
全てのLSRは、[RFC3473]に従って、任意のTLVを受信し、転送するために用意しなければならないことに留意されたいです。 [RFC3473]で定義されており、[RFC4201]によって廃止、これはタイプ4または5のTLVを含みます。積極的に[RFC3473]で定義されたTLVが、どのを処理するLSRのための要件は、しかし、ありません。クランクバック再ルーティングを実行することを提案するLSRは、基本クランクバックのTLVのすべての受信および処理をサポートする必要があり、追加のクランクバックのTLVの受信および処理をサポートすることが推奨されます。
It should be noted, however, that some assumptions about the TLVs that will be used MAY be made based on the deployment scenarios. For example, a router that is deployed in a single-area network does not need to support the receipt and processing of TLV types 22 and 23. Those TLVs might be inserted in an IF_ID ERROR_SPEC object, but would not need to be processed by the receiver of a PathErr message.
使用されたTLVに関するいくつかの仮定が展開シナリオに基づいて行われてもよいことに留意すべきです。例えば、シングル・エリア・ネットワークに配備されているルータは、これらのTLVはIF_ID ERROR_SPECオブジェクトに挿入されるかもしれない、しかしで処理する必要はないであろうTLVタイプ22および23の受信および処理をサポートする必要がありませんPathErrメッセージの受信機。
Error Report TLVs are those in the range 1 through 3. (Note that the obsoleted TLVs 4 and 5 may be considered in this category, but SHOULD NOT be used.)
エラー報告のTLV 3までの範囲1のものである（時代遅れのTLV 4及び5は、このカテゴリでは考慮されてもよいが、使用してはならないこと。注意してください）
As stated above, when crankback information is reported, the IF_ID ERROR_SPEC object MUST be used. When the IF_ID ERROR_SPEC object is used, at least one of the TLVs in the range 1 through 3 MUST be present. The choice of which TLV to use will be dependent on the circumstance of the error and device capabilities. For example, a device that does not support IPv6 will not need the ability to create a TLV of type 2. Note, however, that such a device MUST still be prepared to receive and process all error report TLVs.
上述したようにクランクバック情報が通知された場合、IF_ID ERROR_SPECオブジェクトが使用されなければなりません。 IF_ID ERROR_SPECオブジェクトが使用される場合、3までの範囲1のTLVの少なくとも一方が存在しなければなりません。 TLVを使用するかの選択は誤りとデバイスの機能の状況に依存することになります。たとえば、IPv6をサポートしていないデバイスは、そのようなデバイスは、まだすべてのエラーレポートTLVを受信し処理するために準備しなければなりませんこと、ただし、タイプ2ノートのTLVを作成する機能を必要としません。
Many of the TLVs report the specific resource that has failed. For example, TLV type 1 can be used to report that the setup attempt was blocked by some form of resource failure on a specific interface identified by the IP address supplied. TLVs in this category are 1 through 11, although TLVs 4 and 5 may be considered to be excluded from this category by dint of having been obsoleted.
TLVの多くが失敗した特定のリソースを報告しています。例えば、TLVタイプ1は、セットアップの試みが供給IPアドレスによって識別される特定のインタフェース上のリソースの障害のいくつかの形態によってブロックされたことを報告するために使用することができます。 TLVの4及び5は、廃止されたのくぼみにより、このカテゴリーから除外されると考えることができるが、このカテゴリでのTLVは、1〜11です。
These TLVs SHOULD be supplied whenever the node detecting and reporting the failure with crankback information has the information available. (Note that some of these TLVs MUST be included as described in the previous two sections.)
これらのTLVは、検出およびクランクバック情報と失敗を報告しているノードは、利用可能な情報を持っているときは常に供給されなければなりません。 （前の2つのセクションで説明したように、これらのTLVの一部が含まれなければならないことに留意されたいです。）
The TLVs of type 8, 9, 10, and 11 MAY, however, be omitted according to local policy and relevance of the information.
タイプ8のTLVの、9、10、及び5月11日には、しかし、ローカルポリシー情報の関連性に応じて省略すること。
Some TLVs help to locate the fault within the context of the path of the LSP that was being set up. TLVs of types 12, 13, 14, and 15 help to set the context of the error within the scope of an explicit path that has loose hops or non-precise abstract nodes. The ERO context information is not always a requirement, but a node may notice that it is a member of the next hop in the ERO (such as a loose or non-specific abstract node) and deduce that its upstream neighbor may have selected the path using next hop routing. In this case, providing the ERO context will be useful to the upstream node that performs re-routing.
いくつかのTLVは設定されていたLSPのパスのコンテキスト内で障害を見つけるのに役立ちます。タイプ12、13、14、及びルーズホップまたは非精密抽象ノードが明示的なパスの範囲内にエラーのコンテキストを設定するために、15ヘルプのTLV。 EROコンテキスト情報は必ずしも必要ではなく、ノードは、それが（例えばルース又は非特定の抽象ノードなど）EROの次のホップのメンバーであることがわかり、その上流隣接パスを選択したかもしれないと推論することができますネクストホップルーティングを使用しました。この場合、EROのコンテキストを提供する再ルーティングを実行上流ノードに有用であろう。
Note the distinction between TLVs 12 and 13 is the distinction between "this is the hop I was trying to satisfy when I failed" and "this is the next hop I was trying to reach when I failed".
TLVの12と13の間に区別は「私が失敗したときに、これは私が満足しようとしていたのホップである」や「これは私が失敗したときに到達しようとしていた次のホップである」との違いであることに注意してください。
Reporting nodes SHOULD also supply TLVs from the range 12 through 20 as appropriate for reporting the error. The reporting nodes MAY also supply TLVs from the range 21 through 27.
レポートノードは、エラーを報告するために適当に20を介して範囲12からTLVを供給すべきです。レポートノードも27を介して範囲21からTLVを供給してもよいです。
Note that in deciding whether a TLV in the range 12 through 20 "is appropriate", the reporting node should consider amongst other things, whether the information is pertinent to the cause of the failure. For example, when a cross-connection fails, it may be that the outgoing interface is faulted, in which case only the interface (for example, TLV type 1) needs to be reported, but if the problem is that the incoming interface cannot be connected to the outgoing interface because of temporary or permanent cross-connect limitations, the node should also include reference to the incoming interface (for example, TLV type 16).
情報は、障害の原因に適切であるかどうかを20までの範囲で12 TLVは「適切である」かどうかを決定する際に、報告ノードは、とりわけ考慮すべきであることに注意してください。例えば、相互接続が失敗したとき、それは発信インターフェイスのみインターフェース（たとえば、TLVタイプ1）が報告する必要がある場合には、故障していることかもしれないが、問題がある場合、着信インターフェイスができないことなぜなら一時的または永久的なクロスコネクトの制限の発信インターフェイスに接続され、ノードは、（例えば、TLVタイプ16）、着信インターフェースへの参照を含める必要があります。
Four TLVs (21, 22, 23, and 24) allow the location of the reporting node to be expanded upon. These TLVs would not be included if the information is not of use within the local system, but might be added by ABRs relaying the error. Note that the Reporting Node ID (TLV 21) need not be included if the IP address of the reporting node as indicated in the ERROR_SPEC itself, is sufficient to fully identify the node.
四つのTLV（21、22、23、及び24）は報告しているノードの位置が上に展開することを可能にします。情報はローカルのシステム内で使用されていませんが、エラーを中継するのABRによって追加される可能性があります場合は、これらのTLVは含まれません。 ERROR_SPEC自体に示されるように報告しているノードのIPアドレスが、完全にノードを識別するのに十分である場合に報告しているノードID（TLV 21）が含まれる必要はないことに留意されたいです。
The last three TLVs (25, 26, and 27) provide additional information for recomputation points. The reporting node (or a node forwarding the error) MAY make suggestions about how the error could have been avoided, for example, by supplying a partial ERO that would cause the LSP to be successfully set up if it were used. As the error propagates back upstream and as crankback routing is attempted and fails, it is beneficial to collect lists of failed nodes and links so that they will not be included in further computations performed at upstream nodes. These lists may also be factored into route exclusions [RFC4874].
最後の三つのTLV（25、26、及び27）は、再計算点のための追加情報を提供します。報告ノード（またはエラーを転送するノード）は、エラーは、それが使用された場合、LSPが正常に設定される原因となる部分EROを供給することにより、例えば、回避されている可能性が方法についての提案を行うことができます。エラーは、上流バック伝播し、クランクバックルーティングが試み及び失敗したとして、上流のノードで実行さらに計算に含まれないように失敗したノードとリンクのリストを収集することが有益である。ようにこれらのリストはまた、ルートの除外[RFC4874]に織り込ますることができます。
Note that there is no ordering requirement on any of the TLVs within the IF_ID Error Spec, and no implication should be drawn from the ordering of the TLVs in a received IF_ID Error Spec.
IF_IDエラースペック内のTLVのいずれにも発注要件が存在しないことに注意してください、と何の意味するところは、受信IF_IDエラースペックでのTLVの順序から引き出されるべきではありません。
The decision of precisely which TLV types a reporting node includes is dependent on the specific capabilities of the node, and is outside the scope of this document.
レポートノードが含ま正確れるTLVタイプの決定は、ノードの特定の機能に依存して、この文書の範囲外です。
Further guidance as to the inclusion of crankback TLVs can be given by grouping the TLVs according to the location of the failure and the context within which it is reported. For example, a TLV that reports an area identifier would only need to be included as the crankback error report transits an area boundary.
クランクバックのTLVを含めることについてのさらなるガイダンスは、障害の位置と、それが報告されている内文脈に応じTLVをグループ化することによって与えられることができます。クランクバックエラーレポートがエリア境界を通過するよう例えば、エリア識別子を報告するTLVのみが含まれる必要があるであろう。
Resource Failure 6 DOWNSTREAM_LABEL 7 UPSTREAM_LABEL Interface Failures 1 IPv4 2 IPv6 3 IF_INDEX 4 COMPONENT_IF_DOWNSTREAM (obsoleted) 5 COMPONENT_IF_UPSTREAM (obsoleted) 12 ERO_CONTEXT 13 ERO_NEXT_CONTEXT 14 PREVIOUS_HOP_IPv4 15 PREVIOUS_HOP_IPv6 16 INCOMING_IPv4 17 INCOMING_IPv6 18 INCOMING_IF_INDEX 19 INCOMING_DOWN_LABEL 20 INCOMING_UP_LABEL Node Failures 8 NODE_ID 21 REPORTING_NODE_ID Area Failures 9 OSPF_AREA 10 ISIS_AREA 22 REPORTING_OSPF_AREA 23 REPORTING_ISIS_AREA 25 PROPOSED_ERO 26 NODE_EXCLUSIONS 27 LINK_EXCLUSIONS AS Failures 11 AUTONOMOUS_SYSTEM 24 REPORTING_AS
リソース失敗6 DOWNSTREAM_LABEL 7つのUPSTREAM_LABELインタフェース障害1のIPv4 2 IPv6の3 IF_INDEX 4 COMPONENT_IF_DOWNSTREAM（廃止）5 COMPONENT_IF_UPSTREAM（廃止）12 ERO_CONTEXT 13 ERO_NEXT_CONTEXT 14 PREVIOUS_HOP_IPv4 15 PREVIOUS_HOP_IPv6 16 INCOMING_IPv4 17 INCOMING_IPv6 18 INCOMING_IF_INDEX 19 INCOMING_DOWN_LABEL 20 INCOMING_UP_LABELノード障害8 NODE_ID 21 REPORTING_NODE_IDエリア障害9 OSPF_AREA 10 ISIS_AREA 22 REPORTING_OSPF_AREA 23 REPORTING_ISIS_AREA 25 PROPOSED_ERO 26 NODE_EXCLUSIONS 27 LINK_EXCLUSIONS障害など11 AUTONOMOUS_SYSTEM 24 REPORTING_AS
Although discussion of aggregation of crankback information is out of the scope of this document, it should be noted that this topic is closely aligned to the information presented here. Aggregation is discussed further in Section 6.4.5.
クランクバック情報の集約の議論は、この文書の範囲外ですが、このトピックは密接にここに提示された情報に整列されることに留意すべきです。集計は、6.4.5項で詳しく説明されています。
No new object is used to distinguish between Path/Resv messages for an alternate LSP. Thus, the alternate LSP uses the same SESSION and SENDER_TEMPLATE/FILTER_SPEC objects as the ones used for the initial LSP under re-routing.
新しいオブジェクトは、代替LSPのためのパス/ RESVメッセージを区別するために使用されていません。したがって、代替のLSPは、再ルーティングの下で最初のLSPのために使用されるものと同じSESSIONとSENDER_TEMPLATE / FILTER_SPECオブジェクトを使用します。
As described in Section 2, a node receiving crankback information in a PathErr must first check to see whether it is allowed to perform re-routing. This is indicated by the Re-routing Flags in the LSP_ATTRIBUTES object during an LSP setup request.
第2節で説明したように、のPathErrにクランクバック情報を受信したノードは最初、再ルーティングを実行することを許可されているかどうかを確認しなければなりません。これは、LSP設定要求中にオブジェクトLSP_ATTRIBUTESに再ルーティングフラグによって示されています。
If a node is not allowed to perform re-routing it should forward the PathErr message, or if it is the ingress report the LSP as having failed.
ノードが再ルーティングを実行することを許可されていない場合には、のPathErrメッセージを転送、またはそれが失敗したように、入口レポートLSPであるならなければなりません。
If re-routing is allowed, the node should attempt to compute a path to the destination using the original (received) explicit path and excluding the failed/blocked node/link. The new path should be added to an LSP setup request as an explicit route and signaled.
再ルーティングが許可されている場合、ノードは、元の（受信）明示的なパスを使用して、失敗した/ブロックされたノード/リンクを除いた宛先への経路を計算することを試みるべきです。新しいパスは、明示的な経路としてLSP設定要求に加え、シグナリングされなければなりません。
LSRs performing crankback re-routing should store all received crankback information for an LSP until the LSP is successfully established or until the node abandons its attempts to re-route the LSP. On the next crankback re-routing path computation attempt, the LSR should exclude all the failed nodes, links and resources reported from previous attempts.
ノードは、LSP経路を再するその試みを放棄するまで、クランクバックの再ルーティングを行うのLSRは、LSPが正常に確立されるまで、LSPのためにすべての受信されたクランクバック情報を格納またはなければなりません。次のクランクバックの再ルーティング経路計算の試みでは、LSRが以前の試みから報告されたすべての失敗したノード、リンクとリソースを除外する必要があります。
It is an implementation decision whether the crankback information is discarded immediately upon a successful LSP establishment or retained for a period in case the LSP fails.
クランクバック情報が成功したLSPの確立後すぐに廃棄されるか、またはLSPに障害が発生した場合の期間保持されているかどうかを実装決定です。
In order to compute an alternate path by crankback re-routing, it is necessary to identify the blocked links or nodes and their locations. The common identifier of each link or node in an MPLS network should be specified. Both protocol-independent and protocol-dependent identifiers may be specified. Although a general identifier that is independent of other protocols is preferable, there are a couple of restrictions on its use as described in the following subsection.
クランクバック再ルーティングすることによって、代替経路を計算するためには、ブロックされたリンクまたはノードとそれらの位置を識別することが必要です。 MPLSネットワークの各リンクまたはノードの共通の識別子が指定されなければなりません。プロトコル独立型およびプロトコル依存の識別子の両方が指定されてもよいです。他のプロトコルとは独立している一般的な識別子は好ましいが、以下のサブセクションで説明したように、その使用上の制限がいくつか存在します。
In link state protocols such as OSPF and IS-IS, each link and node in a network can be uniquely identified, for example, by the context of a TE Router ID and the Link ID. If the topology and resource information obtained by OSPF advertisements is used to compute a constraint-based path, the location of a blockage can be represented by such identifiers.
例えばOSPFやIS-IS、ネットワーク内の各リンクとノードとリンク状態プロトコルで一意TEルータIDのコンテキストとリンクIDによって、例えば、同定することができます。 OSPF広告によって得られたトポロジーおよびリソース情報は、制約ベースの経路を計算するために使用される場合、閉塞の位置は、このような識別子によって表すことができます。
Note that when the routing-protocol-specific link identifiers are used, the Re-routing Flag on the LSP setup request must have been set to show support for boundary or segment-based re-routing.
ルーティングプロトコル固有のリンク識別子が使用される場合、LSP設定要求で再ルーティングフラグは、境界またはセグメントベースの再ルーティングのためのサポートを示すために設定されていなければならないことに注意してください。
In this document, we specify routing protocol specific link and node identifiers for OSPFv2, OSPFv3, and IS-IS for IPv4 and IPv6. These identifiers may only be used if segment-based re-routing is supported, as indicated by the Routing Behavior flag on the LSP setup request.
この文書では、我々はOSPFv2の、OSPFv3のためのルーティングプロトコル固有のリンクやノードの識別子を指定し、IPv4とIPv6のためのIS-IS。 LSP設定要求のルーティング動作フラグによって示されるように、セグメントベースの再ルーティングは、サポートされている場合、これらの識別子のみを使用することができます。
The explicit route on the original LSP setup request may contain a loose or an Abstract Node. In these cases, the crankback information may refer to links or nodes that were not in the original explicit route.
元のLSP設定要求で明示的ルートが緩んまたは抽象ノードを含んでいてもよいです。これらの場合では、クランクバック情報は、元の明示的経路ではなかったリンクまたはノードを指すことができます。
In order to compute a new path, the repair point may need to identify the pair of hops (or nodes) in the explicit route between which the error/blockage occurred.
新しい経路を計算するために、修復ポイントはエラー/閉塞が発生したとの間の明示的な経路でホップ（またはノード）の組を特定する必要があるかもしれません。
To assist this, the crankback information reports the top two hops of the explicit route as received at the reporting node. The first hop will likely identify the node or the link, the second hop will identify a 'next' hop from the original explicit route.
これを支援するために、クランクバック情報は、報告ノードで受信され、明示的なルートの上位2つのホップをレポートします。最初のホップがありそうな第2のホップは、「次へ」を識別し、ノードまたはリンクを識別し、元の明示的経路からホップ。
When a node cannot or chooses not to perform crankback re-routing, it must forward the PathErr message further upstream.
ノードまたはクランクバック再ルーティングを実行しないことを選択することができない場合、それはのPathErrメッセージがさらに上流に転送しなければなりません。
However, when a node was responsible for expanding or replacing the explicit route as the LSP setup was processed, it MUST update the crankback information with regard to the explicit route that it received. Only if this is done will the upstream nodes stand a chance of successfully routing around the problem.
ノードがLSPセットアップが処理されたように、明示的なルートを拡大または交換を担当した場合しかし、それは受信された明示的経路に関してクランクバック情報を更新する必要があります。これが行われる場合にのみ、上流のノードが正常に問題を回避ルーティングのチャンスを立ちます。
When a setup blocking error or an error in an established LSP occurs and crankback information is sent in an error notification message, an upstream node may choose to attempt crankback re-routing. If that node's attempts at re-routing fail, the node will accumulate a set of failure information. When the node gives up, it MUST propagate the failure message further upstream and include crankback information when it does so.
確立されたLSPでセットアップブロッキングエラーまたはエラーが発生してクランクバック情報はエラー通知メッセージで送信された場合、上流ノードは、再ルーティングクランクバックを試みることを選択することができます。再ルーティングにおけるそのノードの試みが失敗した場合、ノードは障害情報の組を蓄積します。ノードは断念するとき、それはさらに上流の失敗メッセージを伝播する必要があり、それがそうするときクランクバック情報を含みます。
Including a full list of all failures that have occurred due to multiple crankback failures by multiple repair point LSRs downstream could lead to too much signaled information using the protocol extensions described in this document. A compression mechanism for such information is available using TLVs 26 and 27. These TLVs allow for a more concise accumulation of failure information as crankback failures are propagated upstream.
複数の修理ポイントのLSRによって、複数のクランクバックの障害に起因して発生したすべての障害の完全なリストを含めると、下流本書に記載されているプロトコルの拡張機能を使用して、あまりにも多くの合図情報につながる可能性があります。そのような情報の圧縮機構は、クランクバック障害が上流側に伝播されるように、これらのTLVは、障害情報のより簡潔な蓄積を可能にするのTLV 26および27を使用して利用可能です。
Aggregation may involve reporting all links from a node as unusable by flagging the node as unusable, flagging an ABR as unusable when there is no downstream path available, or including a TLV of type 9 which results in the exclusion of the entire area, and so on. The precise details of how aggregation of crankback information is performed are beyond the scope of this document.
凝集は、全領域の排除をもたらすタイプ9のTLVがない下流経路の利用可能であり、又は含む場合、使用不能としてノードフラグを立てることにより、使用不能であるノードからのすべてのリンクを報告として使用不可能ABRフラグを立てる含むなどしてもよいですオン。クランクバック情報の集約がどのように行われるかの正確な詳細は、このドキュメントの範囲を超えています。
As described above, the resource allocation failure for RSVP-TE may occur on the reverse path when the Resv message is being processed. In this case, it is still useful to return the received crankback information to the ingress LSR. However, when the egress LSR receives the ResvErr message, per [RFC2205] it still has the option of re-issuing the Resv with different resource requirements (although not on an alternate path).
上記のようにResvメッセージが処理されている場合に、RSVP-TEのためのリソース割り当ての失敗は逆の経路で発生してもよいです。この場合、まだイングレスLSRに受け取ったクランクバック情報を返すのに便利です。出口LSRは、[RFC2205]あたりResvErrメッセージを受信した場合しかし、それはまだオプションを有する再発行する（しない代替パス上が）異なるリソース要件とのResvを。
When a ResvErr carrying crankback information is received at an egress LSR, the egress LSR MAY ignore this object and perform the same actions that it would perform for any other ResvErr. However, if the egress LSR supports the crankback extensions defined in this document, and after all local recovery procedures have failed, it SHOULD generate a PathErr message carrying the crankback information and send it to the ingress LSR.
ResvErr搬送クランクバック情報が出口LSRで受信されると、出口LSRは、このオブジェクトを無視し、それが他のResvErrに対して実行するのと同じアクションを実行することができます。しかし、出口LSRは、この文書で定義されたクランクバック拡張をサポートしている場合、すべてのローカル・リカバリー手順が失敗した後で、それはクランクバックの情報を運ぶのPathErrメッセージを生成し、イングレスLSRに送信すべきです。
If a ResvErr reports on more than one FILTER_SPEC (because the Resv carried more than one FILTER_SPEC) then only one set of crankback information should be present in the ResvErr and it should apply to all FILTER_SPEC carried. In this case, it may be necessary per [RFC2205] to generate more than one PathErr.
ResvErrが複数のFILTER_SPEC（のResvが複数のFILTER_SPECを実施しているため）に報告された場合、その後クランクバック情報の1セットだけResvErrに存在すべきであり、それはFILTER_SPECが行わすべてに適用されなければなりません。この場合、複数のPathErrを生成するために、[RFC2205]あたりに必要であるかもしれません。
[RFC3473] defines the Notify message to enhance error reporting in RSVP-TE networks. This message is not intended to replace the PathErr and ResvErr messages. The Notify message is sent to addresses requested on the Path and Resv messages. These addresses could (but need not) identify the ingress and egress LSRs, respectively.
[RFC3473]はRSVP-TEネットワークでエラー報告を強化する通知メッセージを定義します。このメッセージは、のPathErrとResvErrメッセージに代わるものではありません。通知メッセージは、パスとRESVメッセージで要求されたアドレスに送信されます。これらのアドレスは（必要ではないが）、それぞれ、入力および出力のLSRを特定することができました。
When a network error occurs, such as the failure of link hardware, the LSRs that detect the error MAY send Notify messages to the requested addresses. The type of error that causes a Notify message to be sent is an implementation detail.
ネットワークエラーが、このようなリンクのハードウェアの障害など、発生した場合、エラーを検出するのLSRは、要求されたアドレスにメッセージを通知送るかもしれません。通知メッセージが送信されるようにするエラーのタイプは、実装の詳細です。
In the event of a failure, an LSR that supports [RFC3473] and the crankback extensions defined in this document MAY choose to send a Notify message carrying crankback information. This would ensure a speedier report of the error to the ingress and/or egress LSRs.
障害が発生した場合、[RFC3473]をサポートしていLSRでは、この文書で定義されたクランクバックエクステンションは、クランクバックの情報を運ぶ通知メッセージを送信することを選ぶかもしれません。これは、入力および/または出口のLSRにエラーのより迅速な報告を保証するであろう。
Error values for the Error Code "Admission Control Failure" are defined in [RFC2205]. Error values for the error code "Routing Problem" are defined in [RFC3209] and [RFC3473].
エラーコード「アドミッション制御の失敗」のエラー値は、[RFC2205]で定義されています。エラーコード「ルーティング問題」のエラー値は、[RFC3209]及び[RFC3473]で定義されています。
A new error value is defined for the error code "Routing Problem". "Re-routing limit exceeded" indicates that re-routing has failed because the number of crankback re-routing attempts has gone beyond the predetermined threshold at an individual LSR.
新しいエラー値は、エラーコード「ルーティング問題」のために定義されています。クランクバック再ルーティング試行の数は、個々のLSRに所定の閾値を超えてしまったので、再ルーティングが失敗したことを示す「再ルーティング制限を超過しました」。
It is recognized that not all nodes in an RSVP-TE network will support the extensions defined in this document. It is important that an LSR that does not support these extensions can continue to process a PathErr, ResvErr, or Notify message even if it carries the newly defined IF_ID ERROR_SPEC information (TLVs).
RSVP-TEネットワーク内のすべてのノードがこの文書で定義された拡張をサポートするわけではないことが認識されています。これらの拡張機能をサポートしていないLSRはのPathErr、ResvErrの処理を続行し、またはそれは、新たに定義されたIF_ID ERROR_SPEC情報（TLVを）運ぶ場合でも、メッセージを通知することが重要です。
This document does not introduce any backward compatibility issues provided that existing implementations conform to the TLV processing rules defined in [RFC3471] and [RFC3473].
この文書では、既存の実装は、[RFC3471]及び[RFC3473]で定義されたTLV処理規則に従うことを条件とする任意の下位互換性の問題を導入しません。
LSP recovery is performed to recover an established LSP when a failure occurs along the path. In the case of LSP recovery, the extensions for crankback re-routing explained above can be applied for improving performance. This section gives an example of applying the above extensions to LSP recovery. The goal of this example is to give a general overview of how this might work, and not to give a detailed procedure for LSP recovery.
LSP回復は障害が経路に沿って発生したときに確立されたLSPを回復するために行われます。 LSPの回復の場合には、クランクバックの再ルーティングのための拡張機能は、上述の性能を改善するために適用することができます。このセクションでは、LSPの回復に上記の拡張を適用した例を示します。この例の目的は、これはうまくいくかもしれない、とLSP回復のための詳細な手順を与えない方法の概要を与えることです。
Although there are several techniques for LSP recovery, this section explains the case of on-demand LSP recovery, which attempts to set up a new LSP on demand after detecting an LSP failure.
LSP回復のためのいくつかの手法がありますが、このセクションでは、LSPの障害を検出した後、必要に応じて新しいLSPを設定しようとしたオンデマンドLSPの回復、の場合について説明します。
When an LSR detects a fault on an adjacent downstream link or node, a PathErr message is sent upstream. In GMPLS, the ERROR_SPEC object may carry a Path_State_Remove_Flag indication. Each LSR receiving the message then releases the corresponding LSP. (Note that if the state removal indication is not present on the PathErr message, the ingress node MUST issue a PathTear message to cause the resources to be released.) If the failed LSP has to be recovered at an upstream LSR, the IF_ID ERROR SPEC that includes the location information of the failed link or node is included in the PathErr message. The ingress, intermediate area border LSR, or indeed any repair point permitted by the Re-routing Flags, that receives the PathErr message can terminate the message and then perform alternate routing.
LSRは隣接する下流リンクまたはノードの障害を検出した場合、のPathErrメッセージが上流に送られます。 GMPLSにおいて、ERROR_SPECオブジェクトはPath_State_Remove_Flag指示を運ぶことができます。メッセージを受信し、各LSRは、次いで、対応するLSPを解放します。 （状態除去指示がのPathErrメッセージに存在しない場合、入口ノードがリソースを解放させるようにPathTearメッセージを発行しなければならないことに注意してください。）故障LSP上流LSR、IF_IDエラーSPECで回収されなければならない場合すなわち、故障したリンクまたはノードの位置情報は、のPathErrメッセージに含まれる含みます。メッセージを終了した後、代替ルーティングを実行することができたPathErrメッセージを受信した再ルーティングフラグによって許可入力、中間領域の境界LSR、または実際に任意の修復ポイント。
In a flat network, when the ingress LSR receives the PathErr message with the IF_ID ERROR_SPEC TLVs, it computes an alternate path around the blocked link or node satisfying the QoS guarantees. If an alternate path is found, a new Path message is sent over this path toward the egress LSR.
入口LSRはIF_ID ERROR_SPECのTLVとのPathErrメッセージを受信したフラットネットワークでは、QoS保証を満足するブロックされたリンクまたはノードの周りの代替経路を計算します。代替パスが見つかった場合、新たなPathメッセージは、出口LSRに向かってこのパスを介して送信されます。
In a network segmented into areas, the following procedures can be used. As explained in Section 5.4, the LSP recovery behavior is indicated in the Flags field of the LSP_ATTRIBUTES object of the Path message. If the Flags indicate "End-to-end re-routing", the PathErr message is returned all the way back to the ingress LSR, which may then issue a new Path message along another path, which is the same procedure as in the flat network case above.
領域に分割ネットワークにおいて、以下の手順を使用することができます。 5.4節で説明したように、LSPの回復挙動はPathメッセージのLSP_ATTRIBUTESオブジェクトのFlagsフィールドに示されています。フラグは、「エンドツーエンドの再ルーティング」を示す場合は、のPathErrメッセージが当時のフラットと同様の手順で別のパスに沿って、新たなPathメッセージを、発行することができる入口LSR、にすべての方法を返します上記のネットワークケース。
If the Flags field indicates Boundary re-routing, the ingress area border LSR MAY terminate the PathErr message and then perform alternate routing within the area for which the area border LSR is the ingress LSR.
Flagsフィールドは、再ルーティング境界を示している場合、入口領域境界LSRはのPathErrメッセージを終了した後、エリア境界LSRは、入口LSRされた領域内に代替ルーティングを実行することができます。
If the Flags field indicates segment-based re-routing, any node MAY apply the procedures described above for Boundary re-routing.
Flagsフィールドがセグメント・ベースの再ルーティングを示している場合、任意のノードが境界再ルーティングのための上記の手順を適用してもよいです。
This section only applies to errors that occur after an LSP has been established. Note that an LSR that generates a PathErr with Path_State_Remove Flag SHOULD also send a PathTear downstream to clean up the LSP.
このセクションでは、唯一のLSPが確立された後に発生したエラーに適用されます。 Path_State_Remove旗とのPathErrを生成LSRはまた、LSPをクリーンアップするために下流PathTearを送るべきであることに注意してください。
A node that detects a fault and is downstream of the fault MAY send a PathErr and/or Notify message containing an IF_ID ERROR SPEC that includes the location information of the failed link or node, and MAY send a PathTear to clean up the LSP at all other downstream nodes.
障害を検出し、障害の下流にあるノードは、のPathErrを送信及び/又は故障したリンクまたはノードの位置情報を含むIF_IDエラーSPECを含むメッセージを通知し、そして全くLSPをクリーンアップするPathTearを送信してもよいです他の下流のノード。
However, if the reservation style for the LSP is Shared Explicit (SE) the detecting LSR MAY choose not to send a PathTear -- this leaves the downstream LSP state in place and facilitates make-before-break repair of the LSP re-utilizing downstream resources. Note that if the detecting node does not send a PathTear immediately, then the unused state will timeout according to the normal rules of [RFC2205].
LSPの予約スタイルが明示共有されている場合ただし、（SE）を検出するLSRはPathTearを送信しないことを選択することができる - これは場所で下流LSP状態を出て、LSPが下流の再利用のメイク前切断修復を促進します資源。検出ノードは直ちにPathTearを送信しない場合、未使用の状態は、[RFC2205]の通常の規則に従ってタイムアウトすることに留意されたいです。
At a well-known merge point, an ABR or an ASBR, a similar decision might also be made so as to better facilitate make-before-break repair. In this case, a received PathTear might be 'absorbed' and not propagated further downstream for an LSP that has an SE reservation style. Note, however, that this is a divergence from the protocol and might severely impact normal tear-down of LSPs.
よく知られた合流点、ABRまたはASBRでは、同様の決定はまた、より良いメイク・ビフォア・ブレークの修復を促進するように作られている可能性があります。この場合、受信PathTearは「吸収」とSE予約スタイルを持っているLSPのためのさらに下流に伝播ない可能性があります。このプロトコルから発散され、深刻なLSPの正常ティアダウンに影響を与える可能性があること、しかし、注意してください。
IANA maintains a registry called "RSVP Parameters" with a subregistry called "Error Codes and Globally-Defined Error Value Sub-Codes". This subregistry includes the RSVP-TE "Routing Problem" error code that is defined in [RFC3209].
IANAは、「エラーコードおよびグローバル定義のエラー値サブコード」と呼ばれる副登録して「RSVPパラメータ」と呼ばれるレジストリを維持します。この副登録は[RFC3209]で定義されているRSVP-TE「ルーティング問題」エラーコードを含みます。
IANA has assigned a new error value for the "Routing Problem" error code as follows:
次のようにIANAは、「ルーティングの問題」のエラーコードのための新しいエラー値を割り当てています：
22 Re-routing limit exceeded.
22再ルーティング制限を超え。
The IF_ID_ERROR_SPEC TLV type values defined in [RFC3471] are maintained by IANA in the "Interface_ID Types" subregistry of the "GMPLS Signaling Parameters" registry.
[RFC3471]で定義されIF_ID_ERROR_SPEC TLVタイプ値は、「GMPLSシグナリングパラメータ」レジストリの「Interface_IDタイプ」副登録にIANAによって維持されています。
IANA has made new assignments from this subregistry for the new TLV types defined in Section 6.2 of this document.
IANAはこのドキュメントのセクション6.2で定義された新しいTLVタイプのため、この副登録から新しい割り当てを行っています。
IANA maintains an "RSVP TE Parameters" registry with an "Attributes Flags" subregistry. IANA has made three new allocations from this registry as listed in Section 5.4.
IANAは、「属性フラグ」副登録して「RSVP TEパラメータ」のレジストリを維持します。 5.4節に記載されているようにIANAは、このレジストリから3つの新しい割り当てを行いました。
These bits are defined for inclusion in the LSP Attributes TLV of the LSP_ATTRIBUTES. The values shown have been assigned by IANA.
これらのビットは、LSPに含まれるように定義されているLSP_ATTRIBUTESのTLV属性。表示される値は、IANAによって割り当てられています。
The RSVP-TE trust model assumes that RSVP-TE neighbors and peers trust each other to exchange legitimate and non-malicious messages. This assumption is necessary in order that the signaling protocol can function.
RSVP-TEの信頼モデルは、RSVP-TEの隣人や仲間が正当なものと悪意のないメッセージを交換するためにお互いを信頼していることを前提としています。この仮定は、シグナリングプロトコルが機能できるようにするために必要です。
Note that this trust model is assumed to cascade. That is, if an LSR trusts its neighbors, it extends this trust to all LSRs that its neighbor trusts. This means that the trust model is usually applied across the whole network to create a trust domain.
この信頼モデルをカスケードに想定していることに注意してください。これはLSRがその隣人を信頼している場合、それはその隣人が信頼するすべてのLSRにこの信頼を拡張し、あります。これは、信頼モデルは、通常、信頼ドメインを作成するために、ネットワーク全体に適用されることを意味します。
Authentication of neighbor identity is already a standard provision of RSVP-TE, as is the protection of messages against tampering and spoofing. Refer to [RFC2205], [RFC3209], and [RFC3473] for a description of applicable security considerations. These considerations and mechanisms are applicable to hop-by-hop message exchanges (such as used for crankback propagation on PathErr messages) and directed message exchanges (such as used for crankback propagation on Notify messages).
改ざんやなりすましに対するメッセージの保護があるとして、近隣のアイデンティティの認証は、既にRSVP-TEの標準提供することです。該当するセキュリティ上の考慮事項の説明については、[RFC2205]、[RFC3209]、および[RFC3473]を参照してください。これらの考察及びメカニズムは、ホップバイホップに適用可能であり、（そのようなメッセージを受け取るにクランクバックプロパゲーションのために使用されるような）指向メッセージ交換（例えばのPathErrメッセージのクランクバックプロパゲーションのために使用されるような）メッセージ交換。
Key management may also be used with RSVP-TE to help to protect against impersonation and message content falsification. This requires the maintenance, exchange, and configuration of keys on each LSR. Note that such maintenance may be especially onerous to operators, hence it is important to limit the number of keys while ensuring the required level of security.
鍵管理も偽装し、メッセージ内容の改ざんから保護するために役立つようにRSVP-TEで使用することができます。これは、メンテナンス、交換、および各LSR上のキーの設定が必要です。このようなメンテナンスがオペレータに特に厄介であってもよいことに留意されたい。従って、セキュリティの必要なレベルを確保しつつ、キーの数を制限することが重要です。
This document does not introduce any protocol elements or message exchanges that change the operation of RSVP-TE security.
この文書では、RSVP-TEのセキュリティの動作を変更する任意のプロトコル要素やメッセージ交換を導入しません。
However, it should be noted that crankback is envisaged as an inter-domain mechanism, and as such it is likely that crankback information is exchanged over trust domain borders. In these cases, it is expected that the information from within a neighboring domain would be of little or no value to the node performing crankback re-routing and would be ignored. In any case, it is highly likely that the reporting domain will have applied some form of information aggregation in order to preserve the confidentiality of its network topology.
しかし、クランクバックは、ドメイン間メカニズムとして想定され、そのように、クランクバックの情報は信頼ドメイン境界上で交換されている可能性があることに留意すべきです。これらの場合には、隣接ドメイン内の情報は、ノード実行クランクバック再ルーティングにほとんど又は全く価値があると無視されることが予想されます。いずれにせよ、報告ドメインはそのネットワークトポロジの機密性を保持するために、情報の集約のいくつかのフォームを適用している可能性が高いです。
The issue of a direct attack by one domain upon another domain is possible and domain administrators should apply policies to protect their domains against the results of another domain attempting to thrash LSPs by allowing them to set up before reporting them as failed. On the whole, it is expected that commercial contracts between trust domains will provide a degree of protection.
別のドメイン上に1つのドメインによる直接攻撃の問題が可能であり、ドメイン管理者は、彼らが失敗したとして、それらを報告する前に設定できるようにすることで、LSPをスラッシュしようとすると、別のドメインの結果に対する彼らのドメインを保護するためのポリシーを適用する必要があります。全体的に、信頼ドメイン間の商業契約は保護の程度を提供することが期待されます。
A more serious threat might arise if a domain reports that neither it nor its downstream neighbor can provide a path to the destination. Such a report could be bogus in that the reporting domain might not have allowed the downstream domain the chance to attempt to provide a path. Note that the same problem does not arise for nodes within a domain because of the trust model. This type of malicious behavior is hard to overcome, but may be detected by use of indirect path computation requests sent direct to the falsely reported domain using mechanisms such as the Path Computation Element [RFC4655].
ドメインは、それもその下流の隣人どちらが先へのパスを提供することができることを報告した場合、より深刻な脅威が発生する可能性があります。報告ドメインは下流のドメインにパスを提供しようとする機会を許可していない可能性があることで、このようなレポートが偽である可能性があります。同じ問題は、信頼モデルのドメイン内のノードのために生じていないことに注意してください。悪意のある行動のこのタイプの克服が困難であるが、そのようなパス計算要素[RFC4655]などのメカニズムを使用して、誤って報告されたドメインに直接送信される間接経路計算リクエストを使用することによって検出することができます。
Note that a separate document describing inter-domain MPLS and GMPLS security considerations will be produced.
ドメイン間MPLSとGMPLSセキュリティの考慮事項を記載し、別のドキュメントが生成されることに注意してください。
Finally, it should be noted that while the extensions in this document introduce no new security holes in the protocols, should a malicious user gain protocol access to the network, the crankback information might be used to prevent establishment of valid LSPs. Thus, the existing security features available in RSVP-TE should be carefully considered by all deployers and SHOULD be made available by all implementations that offer crankback. Note that the implementation of re-routing attempt thresholds are also particularly useful in this context.
最後に、この文書の拡張子はプロトコルに新たなセキュリティホールを導入していない一方で、ネットワークへの悪意のあるユーザのゲインプロトコルアクセス、クランクバック情報が有効LSPの確立を防ぐために使用されるかもしれない必要があることに留意すべきです。このように、RSVP-TEで利用可能な既存のセキュリティ機能は慎重にすべてのデプロイヤによって考慮されるべきであるとクランクバックを提供するすべての実装で利用できるようにすべきです。再ルーティング試行しきい値の実装は、この文脈において特に有用であることに留意されたいです。
We would like to thank Juha Heinanen and Srinivas Makam for their review and comments, and Zhi-Wei Lin for his considered opinions. Thanks, too, to John Drake for encouraging us to resurrect this document and consider the use of the IF_ID ERROR SPEC object. Thanks for a welcome and very thorough review by Dimitri Papadimitriou.
私たちは、彼と考える意見をユハHeinanenとスリニバスMakam債彼らのレビューとコメントのための、そして志偉林に感謝したいと思います。おかげで、あまりにも、ジョン・ドレイクにこの文書を復活し、IF_IDエラーSPECオブジェクトの使用を検討するために私達を促します。ディミトリPapadimitriouによって歓迎と非常に徹底した見直しをありがとう。
Stephen Shew made useful comments for clarification through the ITU-T liaison process.
スティーブン供えは、ITU-Tのリエゾンプロセスを通じて明確化のために有益なコメントが寄せられています。
Simon Marshall-Unitt made contributions to this document.
サイモン・マーシャル-UNITTはこのドキュメントへの貢献をしました。
SecDir review was provided by Tero Kivinen. Thanks to Ross Callon for useful discussions of prioritization of crankback re-routing attempts.
SecDirレビューはTERO Kivinenによって提供されました。クランクバック再ルーティング試行の優先順位付けの有益な議論のためのロスCallonに感謝します。
[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月。
[RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A. Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006.
[RFC4420]ファレル、A.編、Papadimitriou、D.、Vasseur、J.-P.、およびA. Ayyangar、「マルチプロトコルラベルスイッチングのための属性のエンコーディング（MPLS）リソース予約を使用したラベルスイッチパス（LSP）の確立をプロトコル - トラフィックエンジニアリング（RSVP-TE）」、RFC 4420、2006年2月。
[ASH1] G. Ash, ITU-T Recommendations E.360.1 --> E.360.7, "QoS Routing & Related Traffic Engineering Methods for IP-, ATM-, & TDM-Based Multiservice Networks", May, 2002.
[ASH1] G.アッシュ、ITU-T勧告E.360.1 - > E.360.7、2002年5月、 "IP-、ATM-、＆TDMベースのマルチサービスネットワークのためのQoSルーティング＆関連トラフィックエンジニアリング方法"。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702] Awduche、D.、マルコム、J.、Agogbua、J.、オデル、M.、およびJ.マクマナス、 "トラフィックエンジニアリングオーバーMPLSのための要件"、RFC 2702、1999年9月。
[RFC3469] Sharma, V., Ed., and F. Hellstrand, Ed., "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.
[RFC3469]シャルマ、V.、エド。、およびF. Hellstrandは、エド。、RFC 3469、2003年2月、 "マルチプロトコルラベルのためのフレームワークは、回復をベーススイッチング（MPLS）"。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]パン、P.、エド。、ツバメ、G.、エド。、およびA.アトラス編、 "高速リルート機能拡張LSPトンネルのための-TEをRSVPする"、RFC 4090、2005年5月。
[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月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（PCE）ベースのアーキテクチャ"、RFC 4655、2006年8月。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4874]リー、CY、ファレル、A.、およびS.デCnodderは、 "ルートの除外 - 拡張をリソースへの予約プロトコル - トラフィックエンジニアリング（RSVP-TE）"、RFC 4874、2007年4月。
[PNNI] ATM Forum, "Private Network-Network Interface Specification Version 1.0 (PNNI 1.0)", <af-pnni-0055.000>, May 1996.
[DOM] ATMフォーラム、 "プライベートネットワーク - ネットワークインターフェイス仕様バージョン1.0（1.0人）"、<AF-DOM-0055.000>、1996年5月。
Appendix A. Experience of Crankback in TDM-Based Networks
TDMベースのネットワークでクランクバックの付録A.体験
Experience of using release messages in TDM-based networks for analogous repair and re-routing purposes provides some guidance.
類似の修理および再ルーティングの目的のためにTDMベースのネットワークに解放メッセージを使用しての経験は、いくつかのガイダンスを提供します。
One can use the receipt of a release message with a Cause Value (CV) indicating "link congestion" to trigger a re-routing attempt at the originating node. However, this sometimes leads to problems.
一つは、発信元ノードの再ルーティング試行をトリガする「リンク輻輳」を示す原因値（CV）と解放メッセージの受信を使用することができます。しかし、これは時々問題につながります。
*--------------------* *-----------------*
| | | |
| N2 ----------- N3-|--|----- AT--- EO2 |
| | | \| | / | |
| | | |--|- / | |
| | | | | \/ | |
| | | | | /\ | |
| | | |--|- \ | |
| | | /| | \ | |
| N1 ----------- N4-|--|----- EO1 |
| | | |
*--------------------* *-----------------*
A-1 A-2
Figure 1. Example of network topology
ネットワークトポロジの図1の例
Figure 1 illustrates four examples based on service-provider experiences with respect to crankback (i.e., explicit indication) versus implicit indication through a release with CV. In this example, N1, N2,N3, and N4 are located in one area (A-1), and AT, EO1, and EO2 are in another area (A-2).
図1は、CVと放出を介して暗黙の指示対（すなわち、明示的な指示）をクランクバックに対してサービスプロバイダーの経験に基づいて、4つの例を示す図です。この例では、N1、N2、N3、およびN4は、一つの領域（A-1）に配置され、そしてAT、EO1、EO2とは別の領域（A-2）です。
Note that two distinct areas are used in this example to clearly expose the issues. In fact, the issues are not limited to multi-area networks, but arise whenever path computation is distributed throughout the network, for example, where loose routes, AS routes, or path computation domains are used.
二つの異なる領域が明確な問題を公開するために、この例で使用されていることに注意してください。実際には、問題はマルチエリア・ネットワークに限定されるものではなく、経路計算が緩いルートは、経路、または経路計算ドメインとして使用され、例えば、のために、ネットワーク全体に分散されたときに生じていません。
1. A connection request from node N1 to EO1 may route to N4 and then find "all circuits busy". N4 returns a release message to N1 with CV34 indicating all circuits busy. Normally, a node such as N1 is programmed to block a connection request when receiving CV34, although there is good reason to try to alternately route the connection request via N2 and N3.
1. EO1へのノードN1からの接続要求は、N4へのルートとは「すべての回路忙しい」かもしれません。 N4は忙しいすべての回路を示すCV34とN1に解放メッセージを返します。通常、そのようなN1等のノードはCV34を受信したときに交互経路N2及びN3を介して接続要求をしようとする正当な理由があるが、接続要求をブロックするようにプログラムされています。
Some service providers have implemented a technique called Route Advance (RA), where if a node that is RA capable receives a release message with CV34, it will use this as an implicit re-route indication and try to find an alternate route for the connection request if possible. In this example, alternate route N1-N2-N3-EO1 can be tried and may well succeed.
一部のサービスプロバイダは、RA可能なノードは、CV34と解放メッセージを受信した場合、それは暗黙の再経路指標としてこれを使用して、接続のための代替ルートを見つけることを試みるルートアドバンス（RA）と呼ばれる技術を実装しています可能であればお願いします。この例では、代替経路N1-N2-N3-EO1を試すことができ、十分に成功してもよいです。
2. Suppose a connection request goes from N2 to N3 to AT while trying to reach EO2 and is blocked at link AT-EO2. Node AT returns a CV34 and with RA, N2 may try to re-route N2-N1-N4-AT-EO2, but of course this fails again. The problem is that N2 does not realize where this blocking occurred based on the CV34, and in this case there is no point in further alternate routing.
2. EO2に到達しようとAT-EO2リンクでブロックされている間、接続要求がATにN2からN3に行くとします。ノードでは、CV34を返し、RAで、N2はN2-N1-N4-AT-EO2-ルートを再しようとするかもしれませんが、もちろん、これは再び失敗します。問題は、このブロッキングがCV34に基づいて発生した場所N2が実現しないことがあり、この場合、さらに代替ルーティングにはポイントが存在しません。
3. However, in another case of a connection request from N2 to E02, suppose that link N3-AT is blocked. In this case N3 should return crankback information (and not CV34) so that N2 can alternate route to N1-N4-AT-EO2, which may well be successful.
3.しかし、N2からE02への接続要求の別のケースでは、リンクN3-ATがブロックされているものとします。 N2がうまく成功する可能性がある、N1-N4-AT-EO2への経路を交互にすることができるように、この場合には、N3（CV34としない）クランクバック情報を返すべきです。
4. In a final example, for a connection request from EO1 to N2, EO1 first tries to route the connection request directly to N3. However, node N3 may reject the connection request even if there is bandwidth available on link N3-EO1 (perhaps for priority routing considerations, e.g., reserving bandwidth for high priority connection requests). However, when N3 returns CV34 in the release message, EO1 blocks the connection request (a normal response to CV34 especially if E01-N4 is already known to be blocked) rather than trying to alternate route through AT-N3-N2, which might be successful. If N3 returns crankback information, EO1 could respond by trying the alternate route.
最終的な例においては、EO1からN2への接続要求を、EO1は、最初N3に直接ルーティングする接続要求を試みます。しかし、ノードN3は、リンクN3-EO1上で利用可能な帯域幅（おそらく優先ルーティングを考慮して、例えば、優先度の高い接続要求のための帯域幅を予約）がある場合でも、接続要求を拒否することができます。 N3は、解放メッセージ、EO1ブロック（E01-N4は、すでにブロックされることが知られている場合は特にCV34に正常応答）接続要求にCV34を返すのではなくAT-N3-N2を介してルートを交互しようとすると、であるかもしれないが、場合成功しました。 N3は、クランクバックの情報を返した場合、EO1は代替ルートを試みることによって応答することができます。
It is certainly the case that with topology exchange, such as OSPF, the ingress LSR could infer the re-routing condition. However, convergence of routing information is typically slower than the expected LSP setup times. One of the reasons for crankback is to avoid the overhead of available-link-bandwidth flooding, and to more efficiently use local state information to direct alternate routing at the ingress-LSR.
確かOSPFなどトポロジ交換と、入口LSRは、再ルーティング条件を推論できた場合です。しかし、ルーティング情報の収束が期待されるLSP設定時間よりも一般的に遅くなります。クランクバック理由の1つは、利用可能なリンク帯域幅フラッディングのオーバーヘッドを回避するために、より効率的に進入-LSRに代替ルーティングを指示するために局所的な状態情報を使用することです。
[ASH1] shows how event-dependent-routing can just use crankback, and not available-link-bandwidth flooding, to decide on the re-route path in the network through "learning models". Reducing this flooding reduces overhead and can lead to the ability to support much larger AS sizes.
[ASH1]イベント依存ルーティングがちょうどクランクバックを使用する方法を示しており、利用できないリンク帯域幅の氾濫、「学習モデル」を介してネットワーク内の再配線経路を決定します。この洪水を減らすことは、オーバーヘッド削減とサイズASはるかに大きくサポートする能力につながることができます。
Therefore, the alternate routing should be indicated based on an explicit indication (as in examples 3 and 4), and it is best to know the following information separately:
したがって、代替ルーティング（実施例3及び4のように）明示的な指示に基づいて示されるべきであり、それは個別に以下の情報を知ることが最良です。
a) where blockage/congestion occurred (as in examples 1-2)
a）は、閉塞/輻輳が発生した場所（）1-2の例のように
and
そして
b) whether alternate routing "should" be attempted even if there is no "blockage" (as in example 4).
B）代替ルーティング（）は実施例4と全く「閉塞」が存在しない場合でも試みられる「べきである」かどうか。
Authors' Addresses
著者のアドレス
Adrian Farrel (Editor) Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
エイドリアン・ファレル（編集）老犬のコンサルティング電話：+44（0）1978 860944 Eメール：adrian@olddog.co.uk
Arun Satyanarayana Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 Phone: +1 408 853-3206 EMail: asatyana@cisco.com
アルンSatyanarayanaシスコシステムズ、株式会社170西タスマン博士サンノゼ、CA 95134電話：+1 408 853から3206 Eメール：asatyana@cisco.com
Atsushi Iwata NEC Corporation System Platforms Research Laboratories 1753 Shimonumabe Nakahara-ku, Kawasaki, Kanagawa, 211-8666, JAPAN Phone: +81-(44)-396-2744 Fax: +81-(44)-431-7612 EMail: a-iwata@ah.jp.nec.com
Atsushi Iwata NEC Corporation System Platforms Research Laboratories 1753 Shimonumabe Nakahara-ku, Kawasaki, Kanagawa, 211-8666, JAPAN Phone: +81-(44)-396-2744 Fax: +81-(44)-431-7612 EMail: a-iwata@ah.jp.nec.com
Norihito Fujita NEC Corporation System Platforms Research Laboratories 1753 Shimonumabe Nakahara-ku, Kawasaki, Kanagawa, 211-8666, JAPAN Phone: +81-(44)-396-2091 Fax: +81-(44)-431-7644 EMail: n-fujita@bk.jp.nec.com
Norihito Fujita NEC Corporation System Platforms Research Laboratories 1753 Shimonumabe Nakahara-ku, Kawasaki, Kanagawa, 211-8666, JAPAN Phone: +81-(44)-396-2091 Fax: +81-(44)-431-7644 EMail: n-fujita@bk.jp.nec.com
Gerald R. Ash AT&T EMail: gash5107@yahoo.com
ジェラルドR.アッシュAT＆T Eメール：gash5107@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。