[要約] RFC 4920は、MPLSおよびGMPLS RSVP-TEにおけるクランクバックシグナリングの拡張に関するものであり、クランクバックメカニズムを提供することで、ネットワークの信頼性と効率を向上させることを目的としています。
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
MPLSおよび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）The IETF Trust（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）セットアップリクエストは、十分なリソースなしでリンクまたはノードによってブロックされる可能性があることを意味します。Crankbackは、セットアップ障害情報が、ブロックされたリソースを避けるために新しいセットアップの試みを許可することを許可しないという点から返されるスキームです。クランクバックを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：LSPトンネルのRSVPへの拡張」、RFC 3209、および「一般化されたマルチプロトコルラベルスイッチング（GMPLS）で定義されているGMPLSシグナル伝達で定義されているように、RSVP-TEを使用したMPLSシグナル伝達で使用するためのクランクバックシグナリング拡張機能を指定します。シグナル伝達機能の説明 "、RFC3473。これらの拡張は、ブロックされたリンクまたはノードの周りを迂回する代替パスで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
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）保証を満たす明示的なパスを指定するには、ネットワーク内の各リンクまたはノードが利用できるリソースを識別する必要があります。このようなリソース情報の収集では、OSPFや中間システムへのルーティングプロトコル（IS-IS）を拡張して、追加の状態情報を配布することができます[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（Ingress）の分散情報に基づいて計算し、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セットアップにより、侵入に送信されるPatherrメッセージ、またはEgress（ターミネーター）に送信されるResverrが発生する場合があります。これらのメッセージにより、LSPのセットアップが放棄される可能性があります。一般化されたMPLS [RFC3473]では、Notifyメッセージを使用して、既存のLSPの障害の通知を、LSRを侵入および出力するか、特定の「修復ポイント」（保護または修復の実行を担当する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]は、MPLSをレイヤー2、TDM、およびLAMBDAリソースとパケットリソースを管理するネットワークに拡張します。したがって、Crankbackルーティングは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- Connect on an end-to-end explicit path. This makes crankback routing all the more important in certain GMPLS networks.
波長コンバーターのないネットワークでは、セットアップ要求は、従来のMPLS環境よりも頻繁にブロックされる可能性があります。これにより、特定の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）コアサイドを含み、1対1の方法で関連している制御プレーンとデータプレーン要素のように説明されています。これは、ドキュメントの便利さのみのためです。
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.
o 再ルーティングを試みたことを報告するノード、エリア、および自律システム（ASS）は、制御プレーンエンティティです。
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.
o 単一のコントロールプレーンエンティティが複数のデータプレーンLSRを担当している場合、クランクバックシグナリングは、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のコロークされたものにのみ適用可能であることを意味すると考えるべきではありません。関係。さらに、ほとんどの場合、コントロールプレーンとデータプレーンのコンポーネントは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.
Ingress 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ネットワークでのLambDAリソースのエンドツーエンドの割り当ての要件は、エンドツーエンドの回復が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).
この要件により、GMPLSネットワーク、特に動的な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は、インテリアゲートウェイプロトコル（IGPS）（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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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]およびNotifyメッセージ[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]は、イベント依存のルーティングが、「学習モデル」を介してネットワークの再ルーティングパスを決定するために、クランクバックを使用して、利用可能なリンクバンド幅の洪水を使用する方法を示しています。この洪水を減らすと、オーバーヘッドが減少し、サイズとしてはるかに大きなサポートする能力につながる可能性があります。
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セットアップ（Ingress LSR）を開始するLSR、As As Border LSR、またはSomeを開始する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.
確立されたLSPの障害に起因するクランクバック情報を受け取る修理ポイント（たとえば、侵入LSR）は、LSPの修復を試みる方法を管理するためにローカルポリシーを適用する場合があります。たとえば、故障した複数のLSP間の修復試行に優先順位を付けることができ、局所的に修復されたLSP（[RFC4090]）がエンドツーエンド修復の緊急候補であると考える場合があります。さらに、他のLSRは、ネットワーク内でのリソース競合を引き起こす可能性のある同じ障害の影響を受けたLSPのLSP修復も試みている可能性があります。そのため、LSRはリソースの競合の可能性を減らすために修理の試みをずらします。
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 Fast Reoute」[RFC4090]のようなもので、MPLSドメインのノードは故障通知時に「ローカル修理」LSPを確立できます。
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.
代替経路を計算する修理点LSRは、LSPが下流LSRによって正常に確立されるか、修復ポイントLSRが再ルーティングの試みを放棄するまで、エラーメッセージに示されている閉塞の位置識別子を保存する必要があります。クランクバックシグナル伝達情報は特定のLSPを確立しながら同じ修理ポイントLSRに複数回返品される可能性があるため、修理点LSRはこのLSPのすべての経験豊富な閉塞の履歴テーブルを維持する必要があります（少なくともルーティングプロトコルがこの状態を更新するまで情報）結果のパス計算がすべての閉塞を迂回できるように。
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によって繰り返される再試行が行われたときに情報を相関させることであることに注意してください。たとえば、AからBからルーティングする試みが行われ、Bがクランクバック情報で障害を返し、AからCからルーティングする試みが行われる可能性があり、これはクランクバック情報の戻りでも失敗する可能性があるとします。次の試みは、AからBからBからルーティングすることではありません。これは、履歴テーブルを使用することで達成される可能性があります。
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.
履歴テーブルは、A AのLSPが正常に確立されている場合、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は、Ingress LSRで構成されたLSP Retryタイマーよりも大きいタイマーを使用して履歴テーブルを破棄することをお勧めします。イングレスと修復ポイント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セットアップのポイントを修復する可能性のある上流ノード（特にIngress 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.
3) RESVが処理されるため、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は傍受され、エリア/ボーダールーターとして作用する可能性があることに注意してください。
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) パスメッセージが処理されると、フォワードパスでリソース予約をすることもできます。この選択は、GMPLSネットワーク[RFC3471]、[RFC3473]のLSPセットアップと互換性があります。この場合、リソースが利用できない場合、「入場制御の失敗」を示すPatherrメッセージがIngressに返されます。
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では、失敗した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は、LSRSがエラーを報告するノードのIDに加えて誤っているインターフェイスを報告できるようにすることにより、上記のエラーレポートを拡張します。これにより、再計算ノードがエラーをルーティングする能力がさらに向上します。
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障害を報告するために使用できるターゲットを絞ったNotifyメッセージを導入します。このメッセージには、上記と同じエラー報告施設が含まれています。Notifyメッセージは、エラー通知の伝播を促進するために使用される場合がありますが、複数のノードでクランクバックルーティングを提供するネットワークでは、PatherrまたはNotifyがCrankback操作の刺激を提供するかどうかについて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) Notifyメッセージの宛先は、Ingress 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トンネルをセットアップするようにリクエストが行われた場合、Ingress 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.
境界再ルーティング中間ノードは、エリアボーダールーターまたは境界ルーター（ABRS/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.
「ルーティング問題」/「再ルーティング制限を超えた」のエラーコード/値（24/22）を使用して、ノードが再試行のしきい値に達したためにクランクバックの再ルーティングを放棄したことを識別します。
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で説明されている再ルーティングフラグを伝えるためにパスメッセージで使用されます。次のように、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に上流のメッセージを転送することを決定できます。または、別の出力境界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 Link Stateの広告にルーティングプロトコル（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エラー_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.
TLVS 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]で定義されている値フィールドはラベルです。ラベルのすべての使用と同様に、ラベル情報を処理できるノードは、コンテキストからラベルの構文とセマンティクスを知っていると想定されています。すべてのTLVは、4オクテットの倍数にゼロパッドされているため、ラベルがそれ自体が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）またはIGP内のノードを識別するために使用されるルーターID（TLVタイプ21）。
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-OCTETエリア識別子。これは、障害が発生した領域を識別します。
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.
オクテットの実際の（パドなし）IS-IS領域識別子の長さ。有効な値は2から11の包括的です。
IS-IS Area Identifier
IS-ISエリア識別子
The variable-length IS-IS area identifier. Padded with trailing zeroes to a four-octet boundary.
可変長IS-IS領域識別子。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.
関連する自律システムの数。数字として16ビットが使用されている場合、低次ビット（16〜31）を使用する必要があり、高次ビット（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）サブオブジェクトのシーケンス。[RFC3209]、[RFC3473]、またはその他のドキュメントで定義されている場合、EROサブオブジェクトは許可されます。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.
ここで定義されているTLVのシーケンスは、クランクバックの試みにすでに参加しており、現在のLSPセットアップの試みには使用できないと宣言されている下流ノードを示すタイプ1、2、または8のシーケンスです。インターフェイス識別子を使用してノードを識別できることに注意してください。
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.
ここで定義されているTLVのシーケンスは、クランクバックの試みに既に参加しており、現在のLSPセットアップの試みには使用できないと宣言されている下流ノードでの入力インターフェイスを示すタイプ1、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]で定義された処理ルールに従います。送信者には、情報/監視の目的でクランクバック情報を報告するために、タイプ6から27の追加の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.
Crankbackが使用されている場合、Patherr、Resverr、またはNotifyメッセージの送信者はIF_ID ERROR_SPECオブジェクトを使用する必要があり、[RFC3473]、[RFC4201]、および[RFC4201]、および、および3の範囲1〜3のTLVの少なくとも1つを含める必要があります。前の段落。追加の情報を報告するには、追加のTLVも含める必要があります。次のセクションでは、どのTLVをさまざまな状況で使用するか、どのTLVをLSRSでサポートする必要があるかについてのアドバイスを提供します。
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タイプ22および23の受領と処理をサポートする必要はありません。これらのTLVは、if_id error_specオブジェクトに挿入される場合がありますが、によって処理する必要はありません。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は、1〜3の範囲のTLVです（このカテゴリでは、廃止された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オブジェクトを使用する場合、範囲1〜3のTLVの少なくとも1つが存在する必要があります。使用するTLVの選択は、エラーとデバイスの機能の状況に依存します。たとえば、IPv6をサポートしないデバイスでは、タイプ2のTLVを作成する機能は必要ありません。ただし、そのようなデバイスは、すべてのエラーレポート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は1〜11ですが、TLV 4および5は、このカテゴリから除外されていると見なされる場合があります。
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.) The TLVs of type 8, 9, 10, and 11 MAY, however, be omitted according to local policy and relevance of the information.
これらのTLVは、ノードがクランクバック情報を使用して障害を検出および報告するときはいつでも、情報を提供する必要があります。（これらのTLVの一部は、前の2つのセクションで説明したように含める必要があることに注意してください。）しかし、タイプ8、9、10、および11のTLVは、現地のポリシーと情報の関連性に従って省略することができます。
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.
報告ノードは、エラーを報告するために適切な場合、範囲12から20からTLVを提供する必要があります。レポートノードは、範囲21〜27から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).
12〜20の範囲の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.
4つのTLV（21、22、23、および24）により、レポートノードの位置を拡張できます。これらのTLVは、情報がローカルシステム内で使用されない場合は含まれませんが、エラーを中継するABRSによって追加される可能性があります。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].
最後の3つの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.
Crankback 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 Interface障害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 prefore_hop_ipv4インデックス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 AS FALURES
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のPATH/RESVメッセージを区別するための新しいオブジェクトは使用されません。したがって、代替LSPは、同じセッションとsender_template/filter_specオブジェクトを使用して、再ルーティング中の最初のLSPに使用したものと使用します。
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メッセージを転送する必要があります。
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.
クランクバックの再ルーティングを実行するLSRは、LSPが正常に確立されるまで、またはノードがLSPを再ルーティングしようとする試みを放棄するまで、すべてのCrankback情報を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.
Crankback情報が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、および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 26および27を使用して利用可能です。これらのTLVは、クランクバックの障害が上流に伝播されるため、故障情報のより簡潔な蓄積を可能にします。
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を含めて、使用できないものとしてフラグを立てることが含まれます。の上。クランクバック情報の集約がどのように実行されるかの正確な詳細は、このドキュメントの範囲を超えています。
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).
上記のように、RSVメッセージが処理されているときにRSVP-TEのリソース割り当て障害が逆パスで発生する可能性があります。この場合、受信したクランクバック情報をIngress LSRに返品することは依然として有用です。ただし、出力LSRがRESVERRメッセージを受信すると、[RFC2205]ごとに、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メッセージを生成し、Ingress 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を運ぶため）について報告する場合、Resverrに1セットのクランクバック情報のみが存在する必要があり、すべてのfilter_specが携帯するすべてのfilter_specに適用する必要があります。この場合、[RFC2205]が複数のPatherrを生成する必要がある場合があります。
[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メッセージを置き換えることを意図したものではありません。Notifyメッセージは、パスおよび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.
リンクハードウェアの障害など、ネットワークエラーが発生すると、エラーを検出するLSRSは、要求されたアドレスに通知メッセージが送信される場合があります。通知メッセージを送信するエラーのタイプは、実装の詳細です。
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は、新しく定義されたif_id error_spec情報（TLV）を運ぶ場合でも、patherr、resverrの処理、または通知メッセージを引き続き処理し続けることが重要です。
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回復の場合、上記のCrankbackの再ルーティングの拡張は、パフォーマンスを改善するために適用できます。このセクションでは、上記の拡張機能をLSP Recoveryに適用する例を示します。この例の目標は、これがどのように機能するかの一般的な概要を示し、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 INDICATIONを運ぶ場合があります。メッセージを受信する各LSRは、対応するLSPをリリースします。（PatherRメッセージに状態除去の表示が存在しない場合、IngressノードはリソースをリリースするためにPATHTEARメッセージを発行する必要があります。）故障したLSPをアップストリームLSRで回復する必要がある場合、IF_IDエラー仕様これには、失敗したリンクまたはノードの位置情報がPATHERRメッセージに含まれています。侵入、中間エリアの境界LSR、または実際に再ルーティングフラグによって許可されている修理ポイントは、Patherrメッセージを受信することでメッセージを終了し、代替ルーティングを実行できます。
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.
フラットネットワークでは、Ingress LSRがIF_ID ERROR_SPEC TLVを使用してPatherRメッセージを受信すると、QOS保証を満たすブロックされたリンクまたはノードの周りの代替パスを計算します。代替パスが見つかった場合、このパスを介して出口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回復動作は、パスメッセージのLSP_ATTRIBUTESオブジェクトのフラグフィールドに示されています。フラグが「エンドツーエンドの再ルーティング」を示している場合、Patherrメッセージはイングレス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.
フラグフィールドが境界の再ルーティングを示した場合、イングレスエリアの境界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.
障害を検出し、障害の下流にあるノードは、障害リンクまたはノードの位置情報を含むif_idエラー仕様を含むpatherrを送信したり、通知メッセージを送信したり、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を送信しないことを選択する場合があります。資力。検出ノードがすぐに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タイプの値は、「interface_idタイプ」の「gmplsシグナル伝達パラメーター」レジストリの「interface_idタイプ」サブレジストリで維持されます。
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パラメーター」レジストリを維持しています。IANAは、セクション5.4にリストされているように、このレジストリから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_ATTRIBUTESのLSP属性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.
あるドメインによる別のドメインに対する直接的な攻撃の問題が可能であり、ドメイン管理者は、失敗したと報告する前に設定できるようにすることで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.
ドメイン間MPLと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で利用可能な既存のセキュリティ機能は、すべての展開者が慎重に検討する必要があり、CrankBackを提供するすべての実装によって利用可能にする必要があります。再ルーティングの試みのしきい値の実装は、このコンテキストでも特に役立つことに注意してください。
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.
Juha HeinanenとSrinivas Makamのレビューとコメントに感謝します。また、このドキュメントを復活させ、if_idエラースペックオブジェクトの使用を検討することを奨励してくれたJohn Drakeにも感謝します。Dimitri Papadimitriouによる歓迎で非常に徹底的なレビューをありがとう。
Stephen Shew made useful comments for clarification through the ITU-T liaison process.
Stephen Shewは、ITU-Tリエゾンプロセスを通じて明確にするために有用なコメントをしました。
Simon Marshall-Unitt made contributions to this document.
Simon Marshall-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によって提供されました。クランクバックの再ルーティングの試みの優先順位付けに関する有益な議論をしてくれたロス・カロンに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、12月2001年。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[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] Farrel、A.、ed。、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. ASH、ITU-Tの推奨事項E.360.1-> E.360.7、 "QoSルーティングおよび関連するトラフィックエンジニアリング方法のIP-、ATM、およびTDMベースのマルチサービスネットワークのメソッド"、2002年5月。
[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.、Malcolm、J.、Agogbua、J.、O'dell、M。、およびJ. McManus、「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] Sharma、V.、ed。、およびF. Hellstrand、ed。、「マルチプロトコルラベルスイッチング（MPLS）ベースの回復のフレームワーク」、RFC 3469、2003年2月。
[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] Pan、P.、Ed。、Ed。、Swallow、G.、Ed。、およびA. Atlas、ed。、「LSP TunnelsのRSVP-TEへの拡張速度」、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. Berger、「MPLS Traffic Engineering（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] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（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] Lee、Cy。、Farrel、A。、およびS. de Cnodder、「除外ルート - リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）への拡張」、2007年4月、RFC 4874。
[PNNI] ATM Forum, "Private Network-Network Interface Specification Version 1.0 (PNNI 1.0)", <af-pnni-0055.000>, May 1996.
[PNNI] ATMフォーラム、「プライベートネットワークネットワークインターフェイス仕様バージョン1.0（PNNI 1.0）」、<AF-PNNI-0055.000>、1996年5月。
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は1つの領域（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.
この例では、問題を明確に公開するために2つの異なる領域が使用されていることに注意してください。実際、問題はマルチエリアネットワークに限定されませんが、たとえば、ルート、またはパス計算ドメインなどのルーズルートなど、ネットワーク全体にパス計算が分散されるたびに発生します。
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. ノードN1からEO1への接続要求は、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.
一部のサービスプロバイダーは、Route Advance（RA）と呼ばれる手法を実装しています。RA能力のあるノードがCV34を使用してリリースメッセージを受信すると、これを暗黙的な再ルート表示として使用し、接続の代替ルートを見つけようとします。可能であればリクエスト。この例では、代替ルート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に到達しようとしている間に接続要求がN2からN3にATになり、Link AT-EO2でブロックされているとします。ノードはCV34を返し、RAを使用して、N2はN2-N1-N4-AT-EO2を再ルーティングしようとする可能性がありますが、もちろんこれは再び失敗します。問題は、N2がCV34に基づいてこのブロッキングが発生した場所を認識していないことであり、この場合、さらに代替ルーティングに意味がないことです。
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がブロックされていると仮定します。この場合、N3はクランクバック情報（CV34ではなく）を返し、N2がN1-N4-AT-EO2への交互のルートが成功する可能性があるようにする必要があります。
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.
4. 最後の例では、EO1からN2への接続要求の場合、EO1は最初に接続要求をN3に直接ルーティングしようとします。ただし、ノードN3は、リンクN3-EO1（おそらく優先ルーティングの考慮事項など、優先度の高い接続要求のために帯域幅を予約するため）で使用可能な帯域幅がある場合でも、接続要求を拒否する場合があります。ただし、N3がリリースメッセージでCV34を返す場合、EO1は、AT-N3-N2を通過するルートを交互にしようとするのではなく、接続要求（特にE01-N4がすでにブロックされていることがわかっている場合はCV34への通常の応答）をブロックします。成功。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つは、利用可能なリンク帯域幅の洪水のオーバーヘッドを回避し、ローカルな状態情報をより効率的に使用して、Ingress-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]は、イベント依存のルーティングが、「学習モデル」を介してネットワークの再ルーティングパスを決定するために、クランクバックを使用して、利用可能なリンクバンド幅の洪水を使用する方法を示しています。この洪水を減らすと、オーバーヘッドが減少し、サイズとしてはるかに大きなサポートする能力につながる可能性があります。
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
Adrian Farrel（編集者）オールドドッグコンサルティング電話：44（0）1978 860944メール：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
Arun Satyanarayana Cisco Systems、Inc。170 West Tasman Dr. San Jose、CA 95134電話：1 408 853-3206メール：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
アトシュシウワタNEC Corporation System Platforms Research Laboratories 1753 Nakahara-Ku、Kawasaki、Kanagawa、211-8666、日本電話：81-（44）-396-2744 FAX：81-（44）-431-7612電子メール@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 Nakahara-Ku、Kawasaki、Kanagawa、211-8666、日本電話：81-（44）-396-2091 FAX：81-（44）-431-7644電子メール：N-Fujita@bk.jp.nec.com
Gerald R. Ash AT&T EMail: gash5107@yahoo.com
Gerald R. Ash AT＆Tメール：gash5107@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。