[要約] RFC 5152は、異なるドメイン間のトラフィックエンジニアリング（TE）ラベルスイッチパス（LSP）を確立するためのドメインごとのパス計算方法についての要約です。目的は、異なるドメイン間のLSPの確立を容易にし、ネットワークの効率性と信頼性を向上させることです。
Networking Working Group JP. Vasseur, Ed.
Request for Comments: 5152 Cisco Systems, Inc.
Category: Standards Track A. Ayyangar, Ed.
Juniper Networks
R. Zhang
BT
February 2008
A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)
ドメイン間トラフィックエンジニアリング（TE）ラベルスイッチ付きパス（LSP）を確立するためのドメインごとのパス計算方法
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document, a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems.
このドキュメントは、ドメイン間トラフィックエンジニアリング（TE）マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPLS（GMPLS）ラベルスイッチドパス（LSP）を確立するためのドメインごとのパス計算手法を指定します。このドキュメントでは、ドメインは、インテリアゲートウェイプロトコル（IGP）領域や自律システムなど、アドレス管理の共通の領域内のネットワーク要素のコレクションを指します。
Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain.
ドメインごとの計算は、ドメイン間TE LSPのフルパスがTE LSPのイングレスノードで決定できない、または決定されない場合に適用され、ドメインの境界を越えてシグナルがありません。これは、可視性の制限により発生する可能性が最も高くなります。信号メッセージは、宛先と次のドメイン境界までのノードを示します。また、さらにドメインの境界またはドメイン識別子を示している場合があります。おそらくドメインからの出口ポイントの選択を含む各ドメインを通るパスは、ドメイン内で決定する必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
2.1. Requirements Language ......................................4
3. General Assumptions .............................................4
3.1. Common Assumptions .........................................4
3.2. Example of Topology for the Inter-Area TE Case .............6
3.3. Example of Topology for the Inter-AS TE Case ...............7
4. Per-Domain Path Computation Procedures ..........................8
4.1. Example with an Inter-Area TE LSP .........................11
4.1.1. Case 1: T0 Is a Contiguous TE LSP ..................11
4.1.2. Case 2: T0 Is a Stitched or Nested TE LSP ..........12
4.2. Example with an Inter-AS TE LSP ...........................13
4.2.1. Case 1: T1 Is a Contiguous TE LSP ..................13
4.2.2. Case 2: T1 Is a Stitched or Nested TE LSP ..........14
5. Path Optimality/Diversity ......................................14
6. Reoptimization of an Inter-Domain TE LSP .......................15
6.1. Contiguous TE LSPs ........................................15
6.2. Stitched or Nested (non-contiguous) TE LSPs ...............16
6.3. Path Characteristics after Reoptimization .................17
7. Security Considerations ........................................17
8. Acknowledgements ...............................................18
9. References .....................................................18
9.1. Normative References ......................................18
9.2. Informative References ....................................18
The requirements for inter-domain Traffic Engineering (inter-area and inter-AS TE) have been developed by the Traffic Engineering Working Group and have been stated in [RFC4105] and [RFC4216]. The framework for inter-domain MPLS Traffic Engineering has been provided in [RFC4726].
ドメイン間トラフィックエンジニアリングの要件（エリア間およびAS TE）は、トラフィックエンジニアリングワーキンググループによって開発されており、[RFC4105]および[RFC4216]に記載されています。ドメイン間MPLSトラフィックエンジニアリングのフレームワークは[RFC4726]で提供されています。
Some of the mechanisms used to establish and maintain inter-domain TE LSPs are specified in [RFC5151] and [RFC5150].
ドメイン間TE LSPを確立および維持するために使用されるメカニズムのいくつかは、[RFC5151]および[RFC5150]で指定されています。
This document exclusively focuses on the path computation aspects and defines a method for establishing inter-domain TE LSPs where each node in charge of computing a section of an inter-domain TE LSP path is always along the path of such a TE LSP.
このドキュメントは、パス計算の側面にのみ焦点を当て、ドメイン間の各ノードを計算する各ノードが常にそのようなte lspのパスに沿っている場合、領域間テープを確立する方法を定義します。
When the visibility of an end-to-end complete path spanning multiple domains is not available at the Head-end LSR (the LSR that initiated the TE LSP), one approach described in this document consists of using a per-domain path computation technique during LSP setup to determine the inter-domain TE LSP as it traverses multiple domains.
複数のドメインにまたがるエンドツーエンドの完全なパスの可視性がヘッドエンドLSR（TE LSPを開始したLSR）で使用できない場合、このドキュメントで説明する1つのアプローチは、ドメインごとのパス計算手法を使用することで構成されています。LSPセットアップ中に、複数のドメインを通過する際にドメイン間TE LSPを決定します。
The mechanisms proposed in this document are also applicable to MPLS TE domains other than IGP areas and ASs.
このドキュメントで提案されているメカニズムは、IGP領域とASS以外のMPLS TEドメインにも適用できます。
The solution described in this document does not attempt to address all the requirements specified in [RFC4105] and [RFC4216]. This is acceptable according to [RFC4216], which indicates that a solution may be developed to address a particular deployment scenario and might, therefore, not meet all requirements for other deployment scenarios.
このドキュメントで説明されているソリューションは、[RFC4105]および[RFC4216]で指定されたすべての要件に対処しようとはしません。これは[RFC4216]に従って許容されます。これは、特定の展開シナリオに対処するためのソリューションが開発されている可能性があるため、他の展開シナリオのすべての要件を満たしていない可能性があることを示しています。
It must be pointed out that the inter-domain path computation technique proposed in this document is one among many others. The choice of the appropriate technique must be driven by the set of requirements for the path attributes and the applicability to a particular technique with respect to the deployment scenario. For example, if the requirement is to get an end-to-end constraint-based shortest path across multiple domains, then a mechanism using one or more distributed PCEs could be used to compute the shortest path across different domains (see [RFC4655]). Other off-line mechanisms for path computation are not precluded either. Note also that a Service Provider may elect to use different inter-domain path computation techniques for different TE LSP types.
このドキュメントで提案されているドメイン間パス計算手法は、他の多くの人の中であることを指摘する必要があります。適切な手法の選択は、パス属性の一連の要件と、展開シナリオに関する特定の手法への適用可能性によって駆動されなければなりません。たとえば、要件が複数のドメインにわたってエンドツーエンドの制約ベースの最短パスを取得することである場合、1つ以上の分散PCEを使用したメカニズムを使用して、異なるドメイン間の最短パスを計算することができます（[RFC4655を参照]）。パス計算のための他のオフラインメカニズムも排除されていません。また、サービスプロバイダーは、さまざまなTE LSPタイプに異なるドメイン間パス計算手法を使用することを選択できることに注意してください。
Terminology used in this document:
このドキュメントで使用される用語：
AS: Autonomous System.
AS：自律システム。
ABR: Area Border Router, a router used to connect two IGP areas (areas in OSPF or levels in Intermediate System to Intermediate System (IS-IS)).
ABR：エリアボーダールーター、2つのIGPエリア（OSPFのエリアまたは中間システムのレベルのレベル（IS-IS）に接続するために使用されるルーター）。
ASBR: Autonomous System Border Router, a router used to connect together ASs of a different or the same Service Provider via one or more inter-AS links.
ASBR：Autonomous System Border Routerは、1つ以上のリンクを介して異なるまたは同じサービスプロバイダーのASSを接続するために使用されるルーターです。
Boundary LSR: A boundary LSR is either an ABR in the context of inter-area TE or an ASBR in the context of inter-AS TE.
境界LSR：境界LSRは、インターエアリーのコンテキストではABRであるか、Inter-as AsのコンテキストではASBRです。
ERO: Explicit Route Object.
IGP: Interior Gateway Protocol.
IGP：インテリアゲートウェイプロトコル。
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
Inter-as te lsp：境界を横切るte lsp。
Inter-area TE LSP: A TE LSP that crosses an IGP area.
LSR: Label Switching Router.
LSR：ラベルスイッチングルーター。
LSP: Label Switched Path.
LSP：ラベルスイッチ付きパス。
TE LSP: Traffic Engineering Label Switched Path.
PCE: Path Computation Element, an entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
PCE：パス計算要素、ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用できるエンティティ（コンポーネント、アプリケーション、またはネットワークノード）。
TED: Traffic Engineering Database.
TED：トラフィックエンジニアリングデータベース。
The notion of contiguous, stitched, and nested TE LSPs is defined in [RFC4726] and will not be repeated here.
連続し、縫い付けられ、ネストされたte LSPの概念は[RFC4726]で定義されており、ここでは繰り返されません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
- Each domain in all the examples below is assumed to be capable of doing Traffic Engineering (i.e., running OSPF-TE or ISIS-TE and RSVP-TE (Resource Reservation Protocol Traffic Engineering)). A domain may itself comprise multiple other domains, e.g., an AS may itself be composed of several other sub-ASs (BGP confederations) or areas/levels. In this case, the path computation technique described for inter-area and inter-AS MPLS Traffic Engineering applies recursively.
- 以下のすべての例の各ドメインは、トラフィックエンジニアリングを実行できると想定されています（つまり、OSPF-TEまたはISIS-TEおよびRSVP-TE（リソース予約プロトコルトラフィックエンジニアリング））。ドメイン自体が他の複数のドメインで構成される場合があります。たとえば、AS自体は、他のいくつかのサブアス（BGPコンフェデレーション）または領域/レベルで構成されている場合があります。この場合、エリア間およびAS間のMPLSトラフィックエンジニアリングについて説明されているパス計算手法は、再帰的に適用されます。
- The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209] and [RFC3473]).
- ドメイン間TE LSPは、RSVP-TE（[RFC3209]および[RFC3473]）を使用してシグナル伝達されます。
- The path (specified by an ERO (Explicit Route Object) in an RSVP-TE Path message) for an inter-domain TE LSP may be signaled as a set of (loose and/or strict) hops.
- ドメイン間TE LSPのパス（RSVP-TEパスメッセージのERO（明示的なルートオブジェクト）で指定）は、（緩んだ）ホップのセットとして信号を送信できます。
- The hops may identify:
- ホップは識別される場合があります：
* The complete strict path end-to-end across different domains
*
* The complete strict path in the source domain followed by boundary LSRs (or domain identifiers, e.g., AS numbers)
* ソースドメインの完全な厳格なパスとその後の境界LSR（またはドメイン識別子、例えば、数字など）
* The complete list of boundary LSRs along the path
* パスに沿った境界LSRの完全なリスト
* The current boundary LSR and the LSP destination
* 現在の境界LSRとLSP宛先
The set of (loose or strict) hops can be either statically configured on the Head-end LSR or dynamically computed. A per-domain path computation method is defined in this document with an optional auto-discovery mechanism (e.g., based on IGP, BGP, policy routing information) yielding the next-hop boundary node (domain exit point, such as an Area Border Router (ABR) or an Autonomous System Border Router (ASBR)) along the path as the TE LSP is being signaled, along with potential crankback mechanisms. Alternatively, the domain exit points may be statically configured on the Head-end LSR, in which case next-hop boundary node auto-discovery would not be required.
（ルーズまたは厳密な）ホップのセットは、ヘッドエンドLSRで静的に構成するか、動的に計算されます。次のホップ境界ノード（エリアボーダールーターなどのドメイン出口ポイントなど、オプションの自動発見メカニズム（例えば、IGP、BGP、ポリシールーティング情報に基づく）を使用して、このドキュメントでドメインごとのパス計算方法が定義されています。（abr）またはTE LSPが潜在的なクランクバックメカニズムとともに、パスに沿った自律システムの境界ルーター（ASBR））。あるいは、ドメインの出口ポイントは、ヘッドエンドLSRで静的に構成されている場合があります。
- Boundary LSRs are assumed to be capable of performing local path computation for expansion of a loose next hop in the signaled ERO if the path is not signaled by the Head-end LSR as a set of strict hops or if the strict hop is an abstract node (e.g., an AS). In any case, no topology or resource information needs to be distributed between domains (as mandated per [RFC4105] and [RFC4216]), which is critical to preserve IGP/BGP scalability and confidentiality in the case of TE LSPs spanning multiple routing domains.
- 境界LSRは、パスが厳格ホップのセットとしてヘッドエンドLSRによって信号がない場合、または厳密なホップが抽象ノードである場合、信号型EROでのゆるい次のホップの拡張のためにローカルパス計算を実行できると想定されています（例えば、as）。いずれにせよ、複数のルーティングドメインにまたがるTE LSPの場合にはIGP/BGPのスケーラビリティと機密性を維持するために重要なドメイン間にトポロジまたはリソース情報を分配する必要はありません（[RFC4105]および[RFC4216]）。
- The paths for the intra-domain Hierarchical LSP (H-LSP) or Stitched LSP (S-LSP) or for a contiguous TE LSP within the domain may be pre-configured or computed dynamically based on the arriving inter-domain LSP setup request (depending on the requirements of the transit domain). Note that this capability is explicitly specified as a requirement in [RFC4216]. When the paths for the H-LSP/S-LSP are pre-configured, the constraints as well as other parameters like a local protection scheme for the intra-domain H-LSP/S-LSP are also pre-configured.
- ドメイン内階層LSP（H-LSP）またはステッチされたLSP（S-LSP）またはドメイン内の連続したTE LSPのパスは、到着するドメイン間LSPセットアップリクエストに基づいて、事前に構成または動的に計算される場合があります（トランジットドメインの要件に応じて）。この機能は、[RFC4216]の要件として明示的に指定されていることに注意してください。H-LSP/S-LSPのパスが事前に構成されている場合、制約やドメイン内H-LSP/S-LSPのローカル保護スキームのような他のパラメーターも事前に構成されています。
- While certain constraints like bandwidth can be used across different domains, certain other TE constraints like resource affinity, color, metric, etc. as listed in [RFC2702] may need to be translated at domain boundaries. If required, it is assumed that, at the domain boundary LSRs, there will exist some sort of local mapping based on policy agreement in order to translate such constraints across domain boundaries. It is expected that such an assumption particularly applies to inter-AS TE: for example, the local mapping would be similar to the inter-AS TE agreement enforcement polices stated in [RFC4216].
-
- The procedures defined in this document are applicable to any node (not just a boundary node) that receives a Path message with an ERO that constrains a loose hop or an abstract node that is not a simple abstract node (that is, an abstract node that identifies more than one LSR).
-
The following example will be used for the inter-area TE case in this document.
次の例は、このドキュメントの地域間ケースに使用されます。
<-area 1-><-- area 0 --><--- area 2 --->
------ABR1------------ABR3-------
| / | | \ |
R0--X1 | | X2---X3--R1
| | | / |
------ABR2-----------ABR4--------
<=========== Inter-area TE LSP =======>
Figure 1 - Example of topology for the inter-area TE case
図1-エリア間ケースのトポロジの例
Description of Figure 1:
図1の説明：
- ABR1, ABR2, ABR3, and ABR4 are ABRs. - X1 is an LSR in area 1. - X2 and X3 are LSRs in area 2. - An inter-area TE LSP T0 originated at R0 in area 1 and terminated at R1 in area 2.
- ABR1、ABR2、ABR3、およびABR4はABRSです。-X1はエリア1のLSRです。 -X2およびX3はエリア2のLSRです。-エリア1のR0で発信され、エリア2のR1で終了しました。
Notes:
ノート：
- The terminology used in the example above corresponds to OSPF, but the path computation technique proposed in this document equally applies to the case of an IS-IS multi-level network.
- 上記の例で使用されている用語はOSPFに対応していますが、このドキュメントで提案されているパス計算手法は、IS-ISマルチレベルネットワークの場合に等しく適用されます。
- Just a few routers in each area are depicted in the diagram above for the sake of simplicity.
- 単純さのために、上の図に各領域のほんの数ルーターが描かれています。
- The example depicted in Figure 1 shows the case where the Head-end and Tail-end areas are connected by means of area 0. The case of an inter-area TE LSP between two IGP areas that does not transit through area 0 is not precluded.
- 図1に示す例は、ヘッドエンドとテールエンドの領域がエリア0によって接続されている場合を示しています。エリア0を通過しない2つのIGPエリア間のインターエアリーLSPの場合は、排除されていません。。
We consider the following general case, built on a superset of the various scenarios defined in [RFC4216]:
[RFC4216]で定義されているさまざまなシナリオのスーパーセットの上に構築された次の一般的なケースを検討します。
<-- AS1 ----> <------- AS2 ------><--- AS3 ----->
<---BGP---> <---BGP-->
CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6
|\ \ | / | / | / | | |
| \ ASBR2---/ ASBR5 | -- | | |
| \ | | |/ | | |
R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2
<======= Inter-AS TE LSP (LSR to LSR)===========>
or
<======== Inter-AS TE LSP (CE to ASBR) =>
or
また
<================= Inter-AS TE LSP (CE to CE)===============>
Figure 2 - Example of topology for the inter-AS TE case
図2-テースとの間のトポロジの例
The diagram depicted in Figure 2 covers all the inter-AS TE deployment cases described in [RFC4216].
図2に示されている図は、[RFC4216]で説明されているすべての展開間ケースをすべてカバーしています。
Description of Figure 2:
図2の説明：
- Three interconnected ASs, respectively AS1, AS2, and AS3. Note that in some scenarios described in [RFC4216] AS1=AS3.
- 3つの相互接続されたASS、それぞれAS1、AS2、およびAS3。[rfc4216] as1 = as3で説明されているいくつかのシナリオで。
- The ASBRs in different ASs are BGP peers. There is usually no IGP running on the single hop links interconnecting the ASBRs and also referred to as inter-ASBR links.
-
- Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE extensions (see [RFC3630], [RFC3784], [RFC4203] and [RFC4205]). In other words, the ASs are TE enabled.
- それぞれは、必要なIGP TE拡張機能を使用してIGP（IS-ISまたはOSPF）を実行します（[RFC3630]、[RFC3784]、[RFC4203]、[RFC4205]）。言い換えれば、お尻は有効です。
- CE: Customer Edge router.
- CE：カスタマーエッジルーター。
- Each AS can be made of several IGP areas. The path computation technique described in this document applies to the case of a single AS made of multiple IGP areas, multiple ASs made of a single IGP area, or any combination of the above. For the sake of simplicity, each routing domain will be considered as a single area in this document. The case of an inter-AS TE LSP spanning multiple ASs where some of those ASs are themselves made of multiple IGP areas can be easily derived from the examples above: the per-domain path computation technique described in this document is applied recursively in this case.
- それぞれがいくつかのIGP領域で構成されています。このドキュメントで説明されているパス計算手法は、複数のIGP領域、単一のIGP領域で作られた複数のASS、または上記の任意の組み合わせで構成された単一の場合に適用されます。簡単にするために、各ルーティングドメインは、このドキュメントの単一の領域と見なされます。これらのASSの一部が複数のIGP領域で作られている複数のASSにまたがるTELSPの場合の場合は、上記の例から簡単に導出できます。このドキュメントで説明されているドメインごとのパス計算手法は、この場合に再帰的に適用されます。。
- An inter-AS TE LSP T1 originated at R0 in AS1 and terminated at R6 in AS3.
- AS LSP T1とAS Inter-ASは、AS1でR0で発生し、AS3でR6で終了しました。
The mechanisms for inter-domain TE LSP computation as described in this document can be used regardless of the nature of the inter-domain TE LSP (contiguous, stitched, or nested).
このドキュメントで説明されているドメイン間TE LSP計算のメカニズムは、ドメイン間TE LSP（連続、ステッチ、またはネスト）の性質に関係なく使用できます。
Note that any path can be defined as a set of loose and strict hops. In other words, in some cases, it might be desirable to rely on the dynamic path computation in some domains, and exert a strict control on the path in other domains (defining strict hops).
任意のパスは、ゆるくて厳格なホップのセットとして定義できることに注意してください。言い換えれば、場合によっては、一部のドメインの動的なパス計算に依存し、他のドメインのパスに厳密な制御を行うことが望ましい場合があります（厳密なホップを定義します）。
When an LSR that is a boundary node such as an ABR/ASBR receives a Path message with an ERO that contains a strict node, the procedures specified in [RFC3209] apply and no further action is needed.
ABR/ASBRなどの境界ノードであるLSRが、厳密なノードを含むEROを使用してパスメッセージを受信する場合、[RFC3209]で指定された手順が適用され、それ以上のアクションは必要ありません。
When an LSR that is a boundary node such as an ABR/ASBR receives a Path message with an ERO that contains a loose hop or an abstract node that is not a simple abstract node (that is, an abstract node that identifies more than one LSR), then it MUST follow the procedures as described in [RFC5151].
ABR/ASBRなどの境界ノードであるLSRが、ルーズホップまたは単純な抽象ノードではない抽象ノードを含むEROを含むパスメッセージを受信する場合（つまり、複数のLSRを識別する抽象ノードです。）、[RFC5151]に記載されている手順に従う必要があります。
In addition, the following procedures describe the path computation procedures that SHOULD be carried out on the LSR:
さらに、次の手順では、LSRで実行する必要があるパス計算手順について説明します。
1) If the next hop is not present in the TED, the two following conditions MUST be checked:
1) 次のホップがTEDに存在しない場合、次の2つの条件を確認する必要があります。
o Whether the IP address of the next-hop boundary LSR is outside of the current domain
o 次のホップ境界LSRのIPアドレスが現在のドメインの外側にあるかどうか
o Whether the next-hop domain is PSC (Packet Switch Capable) and uses in-band control channel
o Next-HopドメインがPSC（パケットスイッチ対応）であり、バンド制御チャネルを使用しているかどうか
If the two conditions above are satisfied, then the boundary LSR SHOULD check if the next hop has IP reachability (via IGP or BGP). If the next hop is not reachable, then a signaling failure occurs and the LSR SHOULD send back an RSVP PathErr message upstream with error code=24 ("Routing Problem") and error subcode as described in section 4.3.4 of [RFC3209]. If the available routing information indicates that next hop is reachable, the selected route will be expected to pass through a domain boundary via a domain boundary LSR. The determination of domain boundary point based on routing information is what we term as "auto-discovery" in this document. In the absence of such an auto-discovery mechanism, a) the ABR in the case of inter-area TE or the ASBR in the next-hop AS in the case of inter-AS TE should be the signaled loose next hop in the ERO and hence should be accessible via the TED, or b) there needs to be an alternate scheme that provides the domain exit points. Otherwise, the path computation for the inter-domain TE LSP will fail.
上記の2つの条件が満たされている場合、境界LSRは、次のホップにIPリーチ可能性があるかどうかを確認する必要があります（IGPまたはBGPを介して）。次のホップが到達できない場合、シグナリングの障害が発生し、LSRはエラーコード= 24（ "ルーティング問題"）と[RFC3209]のセクション4.3.4で説明されているエラーサブコードを使用して上流のRSVP PATHERRメッセージを送信する必要があります。利用可能なルーティング情報が次のホップに到達可能であることを示している場合、選択したルートはドメイン境界LSRを介してドメイン境界を通過することが期待されます。ルーティング情報に基づくドメイン境界点の決定は、このドキュメントでは「自動発見」と呼ばれるものです。このような自動配置メカニズムがない場合、a）インターエリアまたは次のホップのASBRの場合のABRは、インタータイの場合のように、EROの次のホップに合図された次のホップである必要がありますしたがって、TEDを介してアクセスできるはずです。またはb）ドメインの出口ポイントを提供する代替スキームが必要です。それ以外の場合、ドメイン間TE LSPのパス計算は失敗します。
An implementation MAY support the ability to disable such an IP reachability fall-back option should the next-hop boundary LSR not be present in the TED. In other words, an implementation MAY support the possibility to trigger a signaling failure whenever the next hop is not present in the TED.
次のホップ境界LSRがTEDに存在しない場合、実装は、このようなIPリーチ可能性の転倒オプションを無効にする機能をサポートする場合があります。言い換えれば、実装は、次のホップがTEDに存在しないときはいつでも、信号障害をトリガーする可能性をサポートする場合があります。
2) Once the next-hop boundary LSR has been determined (according to the procedure described in 1)) or if the next-hop boundary is present in the TED:
2) 次のホップ境界LSRが決定されたら（1で説明されている手順に従って）、またはTEDにnext-Hopの境界が存在する場合：
o Case of a contiguous TE LSP. Unless not allowed by policy, the boundary LSR that processes the ERO SHOULD perform an ERO expansion (a process consisting of computing the constrained path up to the next loose hop and adding the list of hops as strict nodes in the ERO). If no path satisfying the set of constraints can be found, then this is treated as a path computation and signaling failure and an RSVP PathErr message SHOULD be sent for the inter-domain TE LSP based on section 4.3.4 of [RFC3209].
o 隣接するte lspの場合。ポリシーで許可されていない限り、EROを処理する境界LSRはERO拡張を実行する必要があります（制約付きパスを次のルーズホップまで計算し、EROの厳格なノードとしてホップのリストを追加するプロセス）。一連の制約を満たすパスが見つからない場合、これはパス計算とシグナル伝達の故障として扱われ、[RFC3209]のセクション4.3.4に基づいてドメイン間TE LSPに対してRSVP PATHERRメッセージを送信する必要があります。
o Case of a stitched or nested TE LSP
o ステッチまたはネストされたte lspの場合
* If the boundary LSR is a candidate LSR for intra-area H-LSP/ S-LSP setup (the boundary has local policy for nesting or stitching), the TE LSP is a candidate for hierarchy/nesting (the "Contiguous LSP" bit defined in [RFC5151] is not set), and if there is no H-LSP/S-LSP from this LSR to the next-hop boundary LSR that satisfies the constraints, it SHOULD signal an H-LSP/S-LSP to the next-hop boundary LSR. If a pre-configured H-LSP(s) or S-LSP(s) already exists, then it will try to select from among those intra-domain LSPs. Depending on local policy, it MAY signal a new H-LSP/S-LSP if this selection fails. If the H-LSP/S-LSP is successfully signaled or selected, it propagates the inter-domain Path message to the next hop following the procedures described in [RFC5151]. If for some reason the dynamic H-LSP/S-LSP setup to the next-hop boundary LSR fails, then this SHOULD be treated as a path computation and signaling failure and an RSVP PathErr message SHOULD be sent upstream for the inter-domain LSP. Similarly, if selection of a pre-configured H-LSP/S-LSP fails and local policy prevents dynamic H-LSP/S, this SHOULD be treated as a path computation and signaling failure and an RSVP PathErr message SHOULD be sent upstream for the inter-domain TE LSP. In both of these cases, procedures described in section 4.3.4 of [RFC3209] SHOULD be followed to handle the failure.
* 境界LSRがエリア内H-LSP/ S-LSPセットアップの候補LSRである場合（境界にはネスティングまたはステッチのためのローカルポリシーがあります）、TE LSPは階層/ネストの候補です（「連続LSP」ビットビットが定義されています[rfc5151]では設定されていません）、そしてこのLSRから制約を満たす次のホップ境界LSRにh-lsp/s-lspがない場合、h-lsp/s-lspを次のh-lsp/s-lspを信号する必要があります-hop境界LSR。事前に構成されたH-LSPまたはS-LSP（S）がすでに存在する場合、それらの領域内LSPの中から選択しようとします。ローカルポリシーに応じて、この選択が失敗した場合、新しいH-LSP/S-LSPを示す場合があります。H-LSP/S-LSPが正常にシグナルまたは選択されている場合、[RFC5151]で説明されている手順に従って、次のホップへのドメイン間パスメッセージを伝播します。何らかの理由で、次のホップ境界LSRへの動的H-LSP/S-LSPセットアップが失敗した場合、これはパス計算とシグナル伝達の障害として扱われ、domain間LSPのRSVP PATHERRメッセージを上流に送信する必要があります。。同様に、事前に構成されたH-LSP/S-LSPの選択が失敗し、ローカルポリシーが動的なH-LSP/sを防ぐ場合、これはパス計算およびシグナル伝達の障害として扱われ、RSVP PatherRメッセージを上流に送信する必要があります。ドメイン間Te lsp。これらの両方のケースでは、[RFC3209]のセクション4.3.4で説明されている手順に従って、障害を処理する必要があります。
* If, however, the boundary LSR is not a candidate for intra-domain H-LSP/S-LSP (the boundary LSR does not have local policy for nesting or stitching) or the TE LSP is not a candidate for hierarchy/nesting (the "Contiguous LSP" bit defined in [RFC5151] is set), then it SHOULD apply the same procedure as for the contiguous case.
* ただし、境界LSRがドメイン内H-LSP/S-LSPの候補ではない場合（境界LSRにはネストまたはステッチのためのローカルポリシーがありません）、またはTE LSPが階層/ネストの候補ではない場合（[RFC5151]で定義されている「連続LSP」ビットが設定されています）、隣接する場合と同じ手順を適用する必要があります。
The ERO of an inter-domain TE LSP may comprise abstract nodes such as ASs. In such a case, upon receiving the ERO whose next hop is an AS, the boundary LSR has to determine the next-hop boundary LSR, which may be determined based on the auto-discovery process mentioned above. If multiple ASBR candidates exist, the boundary LSR may apply some policies based on peering contracts that may have been pre-negotiated. Once the next-hop boundary LSR has been determined, a similar procedure as the one described above is followed.
ドメイン間TE LSPのEROは、ASSなどの抽象的なノードで構成される場合があります。そのような場合、次のホップがASであるEROを受信すると、境界LSRは次のホップ境界LSRを決定する必要があります。これは、上記の自動発見プロセスに基づいて決定される場合があります。複数のASBR候補が存在する場合、境界LSRは、事前に交換された可能性のあるピアリング契約に基づいていくつかのポリシーを適用する場合があります。next-Hopの境界LSRが決定されると、上記のように同様の手順が順守されます。
Note the following related to the inter-AS TE case:
テースとの間に関連する以下に注意してください。
In terms of computation of an inter-AS TE LSP path, an interesting optimization technique consists of allowing the ASBRs to flood the TE information related to the inter-ASBR link(s) although no IGP TE is enabled over those links (and so there is no IGP adjacency over the inter-ASBR links). This of course implies that the inter-ASBR links be TE-enabled although no IGP is running on those links.
TE LSPパスの間での計算に関しては、興味深い最適化手法は、ASBRがASBR間リンクに関連するTE情報に浸水できるようにすることで構成されていますが、IGP TEはそれらのリンクで有効になりません（ASBR間リンクを介したIGP隣接はありません）。もちろん、これは、ASBR間リンクがTE対応であることを意味しますが、これらのリンクではIGPが実行されていません。
<-- AS1 ----> <------- AS2 ------><--- AS3 ----->
<---BGP---> <---BGP-->
CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6
|\ \ | / | / | / | | |
| \ ASBR2---/ ASBR5 | -- | | |
| \ | | |/ | | |
R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2
Figure 3 - Flooding of the TE-related information for the inter-ASBR links
図3- ASBR間リンクのTE関連情報の洪水
Referring to Figure 3, ASBR1 for example would advertise in its OSPF Link State Advertisement (LSA)/IS-IS LSP the Traffic Engineering TLVs related to the link ASBR1-ASBR4.
図3を参照すると、たとえばASBR1は、OSPFリンク状態広告（LSA）/IS-IS LSPで、リンクASBR1-ASBR4に関連するトラフィックエンジニアリングTLVを宣伝します。
This allows an LSR (could be the entry ASBR) in the previous AS to make a more appropriate route selection up to the entry ASBR in the immediately downstream AS taking into account the constraints associated with the inter-ASBR links. This reduces the risk of call setup failure due to inter-ASBR links not satisfying the inter-AS TE LSP set of constraints. Note that the TE information is only related to the inter-ASBR links: the TE LSA/LSP flooded by the ASBR includes not only the TE-enabled links contained in the AS but also the inter-ASBR links.
これにより、ASBR間リンクに関連する制約を考慮して、すぐに下流のエントリASBRまでより適切なルート選択を行うために、以前のLSR（エントリASBR）が可能になります。これにより、ASBR間のリンクが一連の制約を満たしていないため、ASBR間リンクによるコールセットアップ障害のリスクが軽減されます。TE情報はASBR間リンクのみに関連していることに注意してください。ASBRによって浸水したTE LSA/LSPには、ASに含まれるTE対応リンクだけでなく、ASBR間リンクも含まれます。
Note that no summarized TE information is leaked between ASs, which is compliant with the requirements listed in [RFC4105] and [RFC4216].
[RFC4105]および[RFC4216]にリストされている要件に準拠しているASS間に要約されたTE情報が漏れていないことに注意してください。
For example, consider the diagram depicted in Figure 2: when ASBR1 floods its IGP TE LSA ((opaque LSA for OSPF)/LSP (TLV 22 for IS-IS)) in its routing domain, it reflects the reservation states and TE properties of the following links: X1-ASBR1, ASBR1-ASBR2, and ASBR1-ASBR4.
たとえば、図2に描かれている図を考えてみましょう。ASBR1がIGP Te LSA（（OSPFの不透明LSA）/LSP（IS-ISのTLV 22））にfloodしている場合、それはルーティングドメインで、予約状態とTE特性を反映しています。次のリンク：X1-ASBR1、ASBR1-ASBR2、およびASBR1-ASBR4。
Thanks to such an optimization, the inter-ASBR TE link information corresponding to the links originated by the ASBR is made available in the TED of other LSRs in the same domain to which the ASBR belongs. Consequently, the path computation for an inter-AS TE LSP path can also take into account the inter-ASBR link(s). This will improve the chance of successful signaling along the next AS in case of resource shortage or unsatisfied constraints on inter-ASBR links, and it potentially reduces one level of crankback. Note that no topology information is flooded, and these links are not used in IGP SPF computations. Only the TE information for the outgoing links directly connected to the ASBR is advertised.
このような最適化のおかげで、ASBRが発信するリンクに対応するASBR間のリンク情報は、ASBRが属する同じドメインの他のLSRのTEDで利用可能になります。したがって、TE LSPパスとしてのパス計算では、ASBR間リンクを考慮に入れることもできます。これにより、ASBR間リンクに対するリソース不足や不満の制約の場合のように、次のシグナリングに沿って成功する可能性が向上し、1つのレベルのクランクバックが潜在的に減少する可能性があります。トポロジー情報は浸水しておらず、これらのリンクはIGP SPF計算では使用されていないことに注意してください。ASBRに直接接続されている発信リンクのTE情報のみが宣伝されています。
Note that an operator may decide to operate a stitched segment or 1-hop hierarchical LSP for the inter-ASBR link.
オペレーターは、ASBR間リンクのためにステッチされたセグメントまたは1ホップ階層LSPを操作することを決定することに注意してください。
The following example uses Figure 1 as a reference.
次の例では、図1を参照として使用しています。
The Head-end LSR (R0) first determines the next-hop ABR (which could be manually configured by the user or dynamically determined by using the auto-discovery mechanism). R0 then computes the path to reach the selected next-hop ABR (ABR1) and signals the Path message. When the Path message reaches ABR1, it first determines the next-hop ABR from its area 0 along the LSP path (say, ABR3), either directly from the ERO (if for example the next-hop ABR is specified as a loose hop in the ERO) or by using the auto-discovery mechanism specified above.
ヘッドエンドLSR（R0）は、最初にネクストホップABR（ユーザーが手動で構成するか、自動ディスコービリメカニズムを使用して動的に決定することができます）を決定します。R0は、選択されたネクストホップABR（ABR1）に到達するパスを計算し、パスメッセージを信号します。パスメッセージがABR1に到達すると、最初にLSPパスに沿ったエリア0から次のホップABRを決定します（たとえば、ABR3）。ERO）または上記で指定された自動発見メカニズムを使用して。
- Example 1 (set of loose hops): R0-ABR1(loose)-ABR3(loose)-R1(loose)
- 例1（ルーズホップのセット）：R0-ABR1（ルーズ）-ABR3（ルーズ）-R1（ルーズ）
- Example 2 (mix of strict and loose hops): R0-X1-ABR1-ABR3(loose)-X2-X3-R1
- 例2（厳密なホップとルーズホップの組み合わせ）：R0-X1-ABR1-ABR3（ルーズ）-X2-X3-R1
Note that a set of paths can be configured on the Head-end LSR, ordered by priority. Each priority path can be associated with a different set of constraints. It may be desirable to systematically have a last-resort option with no constraint to ensure that the inter-area TE LSP could always be set up if at least a TE path exists between the inter-area TE LSP source and destination. In case of setup failure or when an RSVP PathErr is received indicating that the TE LSP has suffered a failure, an implementation might support the possibility of retrying a particular path option a configurable amount of times (optionally with dynamic intervals between each trial) before trying a lower-priority path option.
一連のパスは、優先順位で順序付けられたヘッドエンドLSRで構成できることに注意してください。各優先パスは、さまざまな制約セットに関連付けられます。少なくともエアリーのLSPソースと宛先の間に少なくともTEパスが存在する場合、インターアレアLSPを常にセットアップできるように制約のない最後のリゾートオプションを体系的に持つことが望ましい場合があります。セットアップの障害の場合、またはRSVP PatherrがTE LSPが障害に陥ったことを示す場合、実装は特定のパスオプションを構成可能な回数（オプションで各試行間で動的間隔で）を再試行する可能性をサポートする可能性がありますより低いパスオプション。
Once it has computed the path up to the next-hop ABR (ABR3), ABR1 sends the Path message along the computed path. Upon receiving the Path message, ABR3 then repeats a similar procedure. If ABR3 cannot find a path obeying the set of constraints for the inter-area TE LSP, the signaling process stops and ABR3 sends a PathErr message to ABR1. Then ABR1 can in turn trigger a new path computation by selecting another egress boundary LSR (ABR4 in the example above) if crankback is allowed for this inter-area TE LSP (see [RFC4920]). If crankback is not allowed for that inter-area TE LSP or if ABR1 has been configured not to perform crankback, then ABR1 MUST stop the signaling process and MUST forward a PathErr up to the Head-end LSR (R0) without trying to select another ABR.
次のホップABR（ABR3）までのパスを計算すると、ABR1は計算されたパスに沿ってパスメッセージを送信します。パスメッセージを受信すると、ABR3は同様の手順を繰り返します。ABR3がインターエリアテアLSPの制約セットに従うパスを見つけることができない場合、シグナル伝達プロセスは停止し、ABR3はPatherrメッセージをABR1に送信します。次に、ABR1は、このインターアレアLSPに対してクランクバックが許可されている場合、別の出力境界LSR（上記の例のABR4）を選択することにより、新しいパス計算をトリガーできます（[RFC4920]を参照）。クランクバックがその界面のLSPに許可されていない場合、またはABR1がクランクバックを実行しないように構成されている場合、ABR1はシグナリングプロセスを停止する必要があり、別の選択を試みることなくヘッドエンドLSR（R0）にPatherrを転送する必要がありますabr。
The Head-end LSR (R0) first determines the next-hop ABR (which could be manually configured by the user or dynamically determined by using the auto-discovery mechanism). R0 then computes the path to reach the selected next-hop ABR and signals the Path message. When the Path message reaches ABR1, it first determines the next-hop ABR from its area 0 along the LSP path (say ABR3), either directly from the ERO (if for example the next-hop ABR is specified as a loose hop in the ERO) or by using an auto-discovery mechanism, specified above.
ヘッドエンドLSR（R0）は、最初にネクストホップABR（ユーザーが手動で構成するか、自動ディスコービリメカニズムを使用して動的に決定することができます）を決定します。R0は、選択したNext-Hop ABRに到達するパスを計算し、パスメッセージを信号します。パスメッセージがABR1に到達すると、最初にEROから直接LSPパス（ABR3など）に沿ったエリア0から次のホップABRを決定します（たとえば、次のホップABRが緩いホップとして指定されている場合ERO）または上記で指定された自動発見メカニズムを使用して。
ABR1 then checks whether it has an H-LSP or S-LSP to ABR3 matching the constraints carried in the inter-area TE LSP Path message. If not, ABR1 computes the path for an H-LSP or S-LSP from ABR1 to ABR3 satisfying the constraint and sets it up accordingly. Note that the H-LSP or S-LSP could have also been pre-configured.
ABR1は、H-LSPまたはS-LSPがABR3に存在するかどうかをチェックします。そうでない場合、ABR1は、ABR1からABR3へのH-LSPまたはS-LSPのパスを計算し、制約を満たし、それに応じて設定します。H-LSPまたはS-LSPも事前に構成されている可能性があることに注意してください。
Once ABR1 has selected the H-LSP/S-LSP for the inter-area LSP, using the signaling procedures described in [RFC5151], ABR1 sends the Path message for the inter-area TE LSP to ABR3. Note that irrespective of whether ABR1 does nesting or stitching, the Path message for the inter-area TE LSP is always forwarded to ABR3. ABR3 then repeats the exact same procedures. If ABR3 cannot find a path obeying the set of constraints for the inter-area TE LSP, ABR3 sends a PathErr message to ABR1. Then ABR1 can in turn either select another H-LSP/S-LSP to ABR3 if such an LSP exists or select another egress boundary LSR (ABR4 in the example above) if crankback is allowed for this inter-area TE LSP (see [RFC4920]). If crankback is not allowed for that inter-area TE LSP or if ABR1 has been configured not to perform crankback, then ABR1 forwards the PathErr up to the inter-area Head-end LSR (R0) without trying to select another egress LSR.
ABR1が[RFC5151]に記載されているシグナル伝達手順を使用して、APR1がエリア間LSPのH-LSP/S-LSPを選択したら、ABR1はInter-Area re LSPのパスメッセージをABR3に送信します。ABR1がネストまたはステッチを行うかどうかに関係なく、インターエリアLSPのパスメッセージは常にABR3に転送されることに注意してください。ABR3は、まったく同じ手順を繰り返します。ABR3がインターエリアLSPの制約セットに従うパスを見つけることができない場合、ABR3はPatherRメッセージをABR1に送信します。次に、ABR1は、このようなLSPが存在する場合、別のH-LSP/S-LSPからABR3に別のH-LSP/S-LSPを選択するか、この界面間LSP（[RFC4920を参照）にクランクバックが許可されている場合、別の出力境界LSR（上記の例のABR4）を選択できます。]）。クランクバックがその界面間LSPに許可されていない場合、またはabr1がクランクバックを実行しないように構成されている場合、ABR1は別の出力LSRを選択しようとせずに、エリア間ヘッドエンドLSR（R0）にPatherrを転送します。
The following example uses Figure 2 as a reference.
次の例では、図2を参照として使用しています。
The path computation procedures for establishing an inter-AS TE LSP are very similar to those of an inter-area TE LSP described above. The main difference is related to the presence of inter-ASBR link(s).
TELSPとしての間隔を確立するためのパス計算手順は、上記のインターエリアLSPのパスと非常に似ています。主な違いは、ASBR間リンクの存在に関連しています。
The inter-AS TE path may be configured on the Head-end LSR as a set of strict hops, loose hops, or a combination of both.
AS TE TEパスは、ヘッドエンドLSRで厳格なホップ、ルーズホップ、または両方の組み合わせとして構成できます。
- Example 1 (set of loose hops): ASBR4(loose)-ASBR9(loose)-R6(loose)
- 例1（ルーズホップのセット）：ASBR4（ルーズ）-ASBR9（ルーズ）-R6（ルーズ）
- Example 2 (mix of strict and loose hops): R2-ASBR3-ASBR2-ASBR1-ASBR4-ASBR10(loose)-ASBR9-R6
- 例2（厳密なホップとルーズホップの組み合わせ）：R2-ASBR3-ASBR2-ASBR1-ASBR4-ASBR10（ルーズ）-ASBR9-R6
In example 1 above, a per-AS path computation is performed, respectively on R0 for AS1, ASBR4 for AS2, and ASBR9 for AS3. Note that when an LSR has to perform an ERO expansion, the next hop either must belong to the same AS or must be the ASBR directly connected to the next hop AS. In this latter case, the ASBR reachability is announced in the IGP TE LSA/LSP originated by its neighboring ASBR. In example 1 above, the TE LSP path is defined as: ASBR4(loose)- ASBR9(loose)-R6(loose). This implies that R0 must compute the path from R0 to ASBR4, hence the need for R0 to get the TE reservation state related to the ASBR1-ASBR4 link (flooded in AS1 by ASBR1). In addition, ASBR1 must also announce the IP address of ASBR4 specified in T1's path configuration.
上記の例1では、AS1のR0、AS2のASBR4、AS3ではASBR9でそれぞれPATH PATH計算がそれぞれ実行されます。LSRがERO拡張を実行する必要がある場合、次のホップは次のホップASに直接接続されているASBRに属している必要があるかどうか。この後者の場合、ASBRの到達可能性は、隣接するASBRによって発信されたIGP TE LSA/LSPで発表されます。上記の例1では、TE LSPパスは次のように定義されています：ASBR4（ルーズ） - ASBR9（ルーズ）-R6（ルーズ）。これは、R0がR0からASBR4へのパスを計算する必要があることを意味するため、R0がASBR1-ASBR4リンクに関連するTE予約状態を取得する必要性（ASBR1によってAS1でAS1に浸水）。さらに、ASBR1は、T1のパス構成で指定されたASBR4のIPアドレスも発表する必要があります。
Once it has computed the path up to the next-hop ASBR, ASBR1 sends the Path message for the inter-area TE LSP to ASBR4 (supposing that ASBR4 is the selected next-hop ASBR). ASBR4 then repeats the exact same procedures. If ASBR4 cannot find a path obeying the set of constraints for the inter-AS TE LSP, then ASBR4 sends a PathErr message to ASBR1. Then ASBR1 can in turn either select another ASBR (ASBR5 in the example above) if crankback is allowed for this inter-AS TE LSP (see [RFC4920]), or if crankback is not allowed for that inter-AS TE LSP or if ASBR1 has been configured not to perform crankback, ABR1 stops the signaling process and forwards a PathErr up to the Head-end LSR (R0) without trying to select another egress LSR. In this case, the Head-end LSR can in turn select another sequence of loose hops, if configured. Alternatively, the Head-end LSR may decide to retry the same path; this can be useful in case of setup failure due to an outdated IGP TE database in some downstream AS. An alternative could also be for the Head-end LSR to retry the same sequence of loose hops after having relaxed some constraint(s).
次のホップASBRまでのパスを計算すると、ASBR1は、ASBR4がASBR4が選択されたNext-Hop ASBRであると仮定すると、ASBR4にパスメッセージを送信します。ASBR4は、まったく同じ手順を繰り返します。ASBR4がTE LSPであるための一連の制約に従うパスを見つけることができない場合、ASBR4はPatherRメッセージをASBR1に送信します。次に、ASBR1は、このLSPとしてのクランクバックが許可されている場合（上記の例のASBR5）別のASBR（ASBR5）を選択できます（[RFC4920]を参照）、またはそのLSPとしてのクランクバックが許可されていない場合、またはASBR1の場合Crankbackを実行しないように構成されており、ABR1はシグナル伝達プロセスを停止し、別の出力LSRを選択しようとせずにPatherrをヘッドエンドLSR（R0）に転送します。この場合、ヘッドエンドLSRは、構成されている場合、ルーズホップの別のシーケンスを順番に選択できます。あるいは、ヘッドエンドLSRは同じパスを再試行することを決定する場合があります。これは、下流のASの古いIGP TEデータベースのためにセットアップ障害の場合に役立ちます。別の方法は、ヘッドエンドLSRが、いくつかの制約をリラックスした後、同じルーズホップのシーケンスを再試行することもできます。
The path computation procedures are very similar to the inter-area LSP setup case described earlier. In this case, the H-LSPs or S-LSPs are originated by the ASBRs at the entry to the AS.
パス計算手順は、前述のエリア間LSPセットアップケースと非常に似ています。この場合、H-LSPまたはS-LSPは、ASへのエントリ時にASBRによって発信されます。
Since the inter-domain TE LSP is computed on a per-domain (area, AS) basis, one cannot guarantee that the optimal inter-domain path can be found.
ドメイン間TE LSPはドメインごと（面積）ベースで計算されるため、最適なドメイン間パスが見つかることを保証することはできません。
Moreover, computing two diverse paths using a per-domain path computation approach may not be possible in some topologies (due to the well-known "trapping" problem).
さらに、一部のトポロジーでは、ドメインごとのパス計算アプローチを使用して2つの多様なパスを計算することはできない場合があります（よく知られている「トラップ」問題のため）。
For example, consider the following simple topology:
たとえば、次の単純なトポロジを考えてみましょう。
+-------+
/ \
A----B-----C------D
\ /
+---------+
Figure 4 - Example of the "trapping" problem
図4-「トラップ」の問題の例
In the simple topology depicted in Figure 4, with a serialized approach using the per-domain path computation technique specified in this document, a first TE LSP may be computed following the path A-B-C-D, in which case no diverse path could be found although two diverse paths actually exist: A-C-D and A-B-D. The aim of that simple example that can easily be extended to the inter-domain case is to illustrate the potential issue of not being able to find diverse paths using the per-domain path computation approach when diverse paths exist.
As already pointed out, the required path computation method can be selected by the Service Provider on a per-LSP basis.
すでに指摘したように、必要なパス計算方法は、サービスプロバイダーがLSPごとに選択できます。
If the per-domain path computation technique does not meet the set of requirements for a particular TE LSP (e.g., path optimality, requirements for a set of diversely routed TE LSPs), other techniques such as PCE-based path computation techniques may be used (see [RFC4655]).
ドメインごとのパス計算手法が特定のTE LSPの一連の要件を満たしていない場合（たとえば、パスの最適性、一連の多様にルーティングされたTE LSPの要件）、PCEベースのパス計算技術などの他の手法を使用できます。（[RFC4655]を参照）。
As stated in [RFC4216] and [RFC4105], the ability to reoptimize an already established inter-domain TE LSP constitutes a requirement. The reoptimization process significantly differs based upon the nature of the TE LSP and the mechanism in use for the TE LSP computation.
[RFC4216]および[RFC4105]に記載されているように、すでに確立されているドメイン間TE LSPを再現する能力は要件を構成します。再発現プロセスは、TE LSPの性質とTE LSP計算に使用されているメカニズムに基づいて大きく異なります。
The following mechanisms can be used for reoptimization and are dependent on the nature of the inter-domain TE LSP.
以下のメカニズムは、再最適化に使用でき、ドメイン間TE LSPの性質に依存します。
After an inter-domain TE LSP has been set up, a better route might appear within any traversed domain. Then in this case, it is desirable to get the ability to reroute an inter-domain TE LSP in a non-disruptive fashion (making use of the so-called Make-Before-Break procedure) to follow a better path. This is a known as a TE LSP reoptimization procedure.
ドメイン間のTE LSPがセットアップされた後、トラバースドメイン内により良いルートが表示される可能性があります。この場合、ドメイン間のTE LSPを非破壊的な方法で再ルーティングする能力（いわゆるメイク前の手順を使用する）を取得して、より良いパスに従うことが望ましいです。これは、TE LSPの再最適化手順として知られています。
[RFC4736] proposes a mechanism that allows the Head-end LSR to be notified of the existence of a more optimal path in a downstream domain. The Head-end LSR may then decide to gracefully reroute the TE LSP using the Make-Before-Break procedure. In case of a contiguous LSP, the reoptimization process is strictly controlled by the Head-end LSR that triggers the Make-Before-Break procedure as defined in [RFC3209], regardless of the location of the better path.
[RFC4736]は、下流のドメインでより最適なパスの存在をヘッドエンドLSRに通知できるメカニズムを提案しています。ヘッドエンドLSRは、ブレイク前の手順を使用してTE LSPを優雅に再ルーティングすることを決定する場合があります。連続したLSPの場合、より良い経路の位置に関係なく、[RFC3209]で定義されているように、ブレイク前の手順をトリガーするヘッドエンドLSRによって再オプチミー化プロセスが厳密に制御されます。
In the case of a stitched or nested inter-domain TE LSP, the reoptimization process is treated as a local matter to any domain. The main reason is that the inter-domain TE LSP is a different LSP (and therefore different RSVP session) from the intra-domain S-LSP or H-LSP in an area or an AS. Therefore, reoptimization in a domain is done by locally reoptimizing the intra-domain H-LSP or S-LSP. Since the inter-domain TE LSPs are transported using S-LSP or H-LSP across each domain, optimality of the inter-domain TE LSP in a domain is dependent on the optimality of the corresponding S-LSP or H-LSP. If after an inter-domain LSP is set up a more optimal path is available within a domain, the corresponding S-LSP or H-LSP will be reoptimized using Make-Before-Break techniques discussed in [RFC3209]. Reoptimization of the H-LSP or S-LSP automatically reoptimizes the inter-domain TE LSPs that the H-LSP or S-LSP transports. Reoptimization parameters like frequency of reoptimization, criteria for reoptimization like metric or bandwidth availability, etc. can vary from one domain to another and can be configured as required, per intra-domain TE S-LSP or H-LSP if it is pre-configured or based on some global policy within the domain.
ステッチまたはネストされたドメイン間TE LSPの場合、再最適化プロセスは、あらゆるドメインの局所的な問題として扱われます。主な理由は、ドメイン間のTE LSPが、地域またはASのドメイン内S-LSPまたはH-LSPとは異なるLSP（したがって異なるRSVPセッション）であることです。したがって、ドメインでの再最適化は、領域内H-LSPまたはS-LSPを局所的に再現することによって行われます。ドメイン間TE LSPは各ドメイン全体でS-LSPまたはH-LSPを使用して輸送されるため、ドメイン内のドメイン間TE LSPの最適性は、対応するS-LSPまたはH-LSPの最適性に依存します。ドメイン間LSPが設定された後、ドメイン内でより最適なパスが利用可能である場合、対応するS-LSPまたはH-LSPは[RFC3209]で説明されているメイクブレイク前の手法を使用して再最適化されます。H-LSPまたはS-LSPの再オプチミー化は、H-LSPまたはS-LSPが輸送するドメイン間のte LSPを自動的に再現します。再オプチミー化の頻度、メトリックや帯域幅の可用性などの再発現の基準などの再オプチミー化パラメータは、ドメインごとに異なる場合があり、領域内TE-LSPまたはH-LSPごとに必要に応じて構成することができます。または、ドメイン内のいくつかのグローバルポリシーに基づいています。
Hence, in this scheme, since each domain takes care of reoptimizing its own S-LSPs or H-LSPs, and therefore the corresponding inter-domain TE LSPs, the Make-Before-Break can happen locally and is not triggered by the Head-end LSR for the inter-domain LSP. So, no additional RSVP signaling is required for LSP reoptimization, and reoptimization is transparent to the Head-end LSR of the inter-domain TE LSP.
したがって、このスキームでは、各ドメインが独自のS-LSPまたはH-LSPを再最適化するため、したがって対応するドメイン間テップを処理するため、ブレイク前に発生する可能性があり、ヘッドによってトリガーされない可能性があります。ドメイン間LSPのLSRを終了します。したがって、LSPの再最適化には追加のRSVPシグナル伝達は必要ありません。また、再最適化は、ドメイン間TE LSPのヘッドエンドLSRに対して透明です。
If, however, an operator desires to manually trigger reoptimization at the Head-end LSR for the inter-domain TE LSP, then this solution does not prevent that. A manual trigger for reoptimization at the Head-end LSR SHOULD force a reoptimization thereby signaling a "new" path for the same LSP (along the more optimal path) making use of the Make-Before-Break procedure. In response to this new setup request, the boundary LSR either may initiate new S-LSP setup, in case the inter-domain TE LSP is being stitched to the intra-domain S-LSP, or it may select an existing or new H-LSP, in case of nesting. When the LSP setup along the current path is complete, the Head-end LSR should switch over the traffic onto that path, and the old path is eventually torn down. Note that the Head-end LSR does not know a priori whether a more optimal path exists. Such a manual trigger from the Head-end LSR of the inter-domain TE LSP is, however, not considered to be a frequent occurrence.
ただし、オペレーターがドメイン間TE LSPのヘッドエンドLSRで手動で再最適化をトリガーすることを望んでいる場合、このソリューションはそれを妨げません。ヘッドエンドLSRでの再最適化のための手動トリガーは、再最適化を強制し、同じLSP（より最適なパスに沿った）の「新しい」パスを、ブレイク前の手順を使用して、この新しいセットアップリクエストに応じて、境界LSRは、ドメイン間TE LSPがドメイン内S-LSPに縫い付けられている場合、または既存または新しいH-を選択する場合がある場合、新しいS-LSPセットアップを開始する場合があります。ネスティングの場合のLSP。現在のパスに沿ったLSPのセットアップが完了すると、ヘッドエンドLSRはトラフィックをそのパスに切り替え、古いパスは最終的に取り壊されます。ヘッドエンドLSRは、より最適なパスが存在するかどうかのアプリオリを知らないことに注意してください。ただし、ドメイン間TE LSPのヘッドエンドLSRからのこのようなマニュアルトリガーは、頻繁に発生するとは見なされません。
Procedures described in [RFC4736] MUST be used if the operator does not desire local reoptimization of certain inter-domain LSPs. In this case, any reoptimization event within the domain MUST be reported to the Head-end node. This SHOULD be a configurable policy.
[RFC4736]に記載されている手順は、オペレーターが特定のドメイン間LSPの局所的な再最適化を希望しない場合は、使用する必要があります。この場合、ドメイン内の再オプチミー化イベントは、ヘッドエンドノードに報告する必要があります。これは構成可能なポリシーである必要があります。
Note that in the case of loose hop reoptimization of contiguous inter-domain TE LSP or local reoptimization of stitched/nested S-LSP where boundary LSRs are specified as loose hops, the TE LSP may follow a preferable path within one or more domain(s) but would still traverse the same set of boundary LSRs. In contrast, in the case of PCE-based path computation techniques, because the end-to-end optimal path is computed, the reoptimization process may lead to following a completely different inter-domain path (including a different set of boundary LSRs).
境界LSRがルーズホップとして指定されているステッチ/ネストされたS-LSPの連続的なドメイン間TE LSPの緩い再最適化の場合、TE LSPは1つ以上のドメイン内の好ましいパスに従うことができることに注意してください（s）しかし、それでも同じ境界LSRのセットを横断します。対照的に、PCEベースのパス計算手法の場合、エンドツーエンドの最適パスが計算されるため、再最適化プロセスは、まったく異なるドメイン間パス（異なる境界LSRのセットを含む）に従うことにつながる可能性があります。
Signaling of inter-domain TE LSPs raises security issues (discussed in section 7 of [RFC5151]).
ドメイン間TE LSPのシグナル伝達は、セキュリティの問題を引き起こします（[RFC5151]のセクション7で説明）。
[RFC4726] provides an overview of the requirements for security in an MPLS-TE or GMPLS multi-domain environment. In particular, when signaling an inter-domain RSVP-TE LSP, an operator may make use of the security features already defined for RSVP-TE ([RFC3209]). This may require some coordination between the domains to share the keys (see [RFC2747] and [RFC3097]), and care is required to ensure that the keys are changed sufficiently frequently. Note that this may involve additional synchronization, should the domain border nodes be protected with Fast Reroute ([RFC4090], since the Merge Point (MP) and Point of Local Repair (PLR) should also share the key. For an inter-domain TE LSP, especially when it traverses different administrative or trust domains, the following mechanisms SHOULD be provided to an operator (also see [RFC4216]):
[RFC4726]は、MPLS-TEまたはGMPLSマルチドメイン環境のセキュリティ要件の概要を提供します。特に、ドメイン間のRSVP-TE LSPをシグナルにする場合、オペレーターはRSVP-TE（[RFC3209]）で既に定義されているセキュリティ機能を利用できます。これには、キーを共有するためにドメイン間の調整が必要になる場合があり（[RFC2747]および[RFC3097]を参照）、キーが十分に頻繁に変更されるように注意する必要があります。マージポイント（MP）とローカル修復ポイント（PLR）もキーを共有する必要があるため、ドメインの境界ノードを高速ルート（[RFC4090]で保護する場合、これには追加の同期が含まれる場合があります。LSPは、特にさまざまな管理ドメインまたは信頼ドメインを横断する場合、以下のメカニズムをオペレーターに提供する必要があります（[RFC4216]も参照）：
1) A way to enforce policies and filters at the domain borders to process the incoming inter-domain TE LSP setup requests (Path messages) based on certain agreed trust and service levels/contracts between domains. Various LSP attributes such as bandwidth, priority, etc. could be part of such a contract.
1) ドメインの境界でポリシーとフィルターを実施して、特定の合意された信頼とドメイン間のサービスレベル/契約に基づいて、着信中のドメイン間TE LSPセットアップ要求（パスメッセージ）を処理する方法。帯域幅、優先度などのさまざまなLSP属性は、そのような契約の一部である可能性があります。
2) A way for the operator to rate-limit LSP setup requests or error notifications from a particular domain.
2) オペレーターが特定のドメインからのLSPセットアップリクエストまたはエラー通知を評価する方法。
3) A mechanism to allow policy-based outbound RSVP message processing at the domain border node, which may involve filtering or modification of certain addresses in RSVP objects and messages.
3) ドメイン境界ノードでのポリシーベースのアウトバウンドRSVPメッセージ処理を許可するメカニズム。これには、RSVPオブジェクトとメッセージの特定のアドレスのフィルタリングまたは変更が含まれる場合があります。
This document relates to inter-domain path computation. It must be noted that the process for establishing paths described in this document does not increase the information exchanged between ASs and preserves topology confidentiality, in compliance with [RFC4105] and [RFC4216]. That being said, the signaling of inter-domain TE LSP according to the procedure defined in this document requires path computation on boundary nodes that may be exposed to various attacks. Thus, it is RECOMMENDED to support policy decisions to reject the ERO expansion of an inter-domain TE LSP if not allowed.
このドキュメントは、ドメイン間パス計算に関連しています。このドキュメントで説明されているパスを確立するプロセスは、[RFC4105]および[RFC4216]に準拠して、ASSと保存の間で交換される情報を増加させないことに注意する必要があります。そうは言っても、このドキュメントで定義されている手順に従って、ドメイン間TE LSPのシグナル伝達には、さまざまな攻撃にさらされる可能性のある境界ノードでのパス計算が必要です。したがって、許可されていない場合、ドメイン間TE LSPのERO拡張を拒否するための政策決定をサポートすることをお勧めします。
We would like to acknowledge input and helpful comments from Adrian Farrel, Jean-Louis Le Roux, Dimitri Papadimitriou, and Faisal Aslam.
Adrian Farrel、Jean-Louis Le Roux、Dimitri Papadimitriou、およびFaisal Aslamからの入力と有益なコメントを認めたいと思います。
[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月。
[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年。
[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月。
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC4920] Farrel、A.、ed。、Satyanarayana、A.、Iwata、A.、Fujita、N.、およびG. Ash、「MPLSおよびGMPLS RSVP-TEのクランクバックシグナリング拡張」、2007年7月。
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008.
[RFC5151] Farrel、A.、ed。、Ayyangar、A。、およびJp。Vasseur、「ドメイン間MPLSおよびGMPLSトラフィックエンジニアリング - リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 5151、2008年2月。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC5150] Ayyangar、A.、Kompella、K.、Vasseur、Jp。、およびA. Farrel、「一般化されたマルチプロトコルラベルスイッチングトラフィックエンジニアリング（GMPLS TE）を使用したラベルスイッチングパスステッチ」、RFC 5150、2008年2月。
[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月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] Baker、F.、Lindell、B。、およびM. Talwar、「RSVP暗号認証」、RFC 2747、2000年1月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097] Braden、R。およびL. Zhang、「RSVP暗号化認証 - 更新されたメッセージタイプ値」、RFC 3097、2001年4月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPFバージョン2」、RFC 3630、2003年9月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784] Smit、H。およびT. Li、「トラフィックエンジニアリングの中間システム（IS-IS）拡張（TE）」、RFC 3784、2004年6月。
[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月。
[RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle, Ed., "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105] Le Roux、J.-L.、ed。、vasseur、J.-P.、ed。、およびJ. Boyle、ed。、「A-A-Area MPLS Traffic Engineeringの要件」、RFC 4105、2005年6月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、RFC 4203、2005年10月。
[RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
[RFC4205] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートする中間システム（IS-IS）拡張」、RFC 4205、2005年10月。
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216] Zhang、R.、ed。、およびJ.-P。Vasseur、ed。、「MPLS Inter-autonomous System（AS）Traffic Engineering（TE）要件」、RFC 4216、2005年11月。
[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月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726] Farrel、A.、Vasseur、J.-P。、およびA. Ayyangar、「ドメイン間マルチプロトコルラベルスイッチングトラフィックエンジニアリングのフレームワーク」、RFC 4726、2006年11月。
[RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, November 2006.
[RFC4736] Vasseur、Jp。、ed。、ekejiri、Y。、およびR. Zhang、「マルチプロトコルラベルスイッチング（MPLS）交通工学（TE）の再オプチミー化（TE）ゆるいルーティングラベルスイッチドパス（LSP）」、RFC 4736、2006年11月。
Authors' Addresses
著者のアドレス
JP Vasseur (editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP Vasseur（編集者）Cisco Systems、Inc。1414 Massachusetts Avenue Boxborough、MA 01719 USA
EMail: jpv@cisco.com
Arthi Ayyangar (editor) Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA
Arthi Ayyangar（編集者）ジュニパーネットワーク1194 N. Mathilda Ave Sunnyvale、CA 94089 USA
EMail: arthi@juniper.net
Raymond Zhang BT 2160 E. Grand Ave. El Segundo, CA 90025 USA
Raymond Zhang BT 2160 E. Grand Ave. El Segundo、CA 90025 USA
EMail: raymond.zhang@bt.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
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への情報をお問い合わせください。