RFC5152 日本語訳
5152 A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs).JP. Vasseur, Ed., A. Ayyangar, Ed., R. Zhang. February 2008. (Format: TXT=50563 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループJPをネットワークでつなぎます。 エドVasseur、コメントを求める要求: 5152年のシスコシステムズInc.カテゴリ: 規格はR.チャンBT2008年2月にエドA.Ayyangar、杜松ネットワークを追跡します。
A Per-Domain Path Computation Method for Establishing Inter-Domain
Traffic Engineering (TE) Label Switched Paths (LSPs)
相互ドメイン交通工学(Te)のラベルの切り換えられた経路を確立するための1ドメインあたり1つの経路計算方法(LSPs)
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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.
このドキュメントは相互ドメインTraffic Engineering(TE)Multiprotocol Label Switching(MPLS)とGeneralized MPLS(GMPLS)ラベルSwitched Paths(LSPs)を設立するための1ドメインあたり1つの経路計算のテクニックを指定します。 本書では、ドメインはInteriorゲートウェイプロトコル(IGP)の領域やAutonomous Systemsなどのアドレス管理か経路のコンピュータの責任の一般的な球の中でネットワーク要素の収集を参照します。
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.
1ドメインあたりの計算は、相互ドメインTE LSPのフルパスがあるはずがないところに適用するか、TE LSPのイングレスノードで決定しないで、またまたはドメイン境界の向こう側に合図されません。 これはTE目に見えること制限で最も起こりそうです。 シグナリングメッセージは目的地とノードを次のドメイン境界まで示します。 また、それはさらなるドメイン境界かドメイン識別子を示すかもしれません。 ことによるとドメインからのエキジットポイントの選択を含む各ドメインを通した経路はドメインの中で決定しているに違いありません。
Vasseur, et al. Standards Track [Page 1] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[1ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
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
1. 序論…2 2. 用語…3 2.1. 要件言語…4 3. 一般仮定…4 3.1. 一般的な仮定…4 3.2. 相互領域Teケースのためのトポロジーに関する例…6 3.3. トポロジーに関する例、相互、Teケース…7 4. 1ドメインあたりの経路計算手順…8 4.1. 相互領域Te LSPがある例…11 4.1.1. ケース1: T0は隣接のTe LSPです…11 4.1.2. ケース2: T0はステッチされたか入れ子にされたTe LSPです…12 4.2. 例、相互、Te LSP…13 4.2.1. ケース1: T1は隣接のTe LSPです…13 4.2.2. ケース2: T1はステッチされたか入れ子にされたTe LSPです…14 5. 経路の最適/多様性…14 6. 相互ドメインTe LSPのReoptimization…15 6.1. 隣接のTe LSPs…15 6.2. (非隣接)のTe LSPsをステッチするか、または入れ子にします…16 6.3. Reoptimizationの後の経路の特性…17 7. セキュリティ問題…17 8. 承認…18 9. 参照…18 9.1. 標準の参照…18 9.2. 有益な参照…18
1. Introduction
1. 序論
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].
相互ドメインTraffic Engineering(相互領域と相互AS TE)のための要件は、Traffic Engineering作業部会によって開発されて、[RFC4105]と[RFC4216]に述べられています。 相互ドメインMPLS Traffic Engineeringのための枠組みを[RFC4726]に提供しました。
Some of the mechanisms used to establish and maintain inter-domain TE LSPs are specified in [RFC5151] and [RFC5150].
相互ドメインTE LSPsを設立して、維持するのに使用されるメカニズムのいくつかが[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の経路に沿って相互ドメインTE LSP経路のセクションを計算することを担当した各ノードがある相互ドメインTE LSPsを設立するために経路計算局面に焦点を合わせて、方法を定義します。
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.
終わりから端への複数のドメインにかかる完全な経路の目に見えることがHead-終わりのLSR(TE LSPを開始したLSR)で利用可能でないときに、本書では説明された1つのアプローチが複数のドメインを横断するとき相互ドメインTE LSPを決定するのにLSPセットアップの間、1ドメインあたり1つの経路計算のテクニックを使用するのから成ります。
Vasseur, et al. Standards Track [Page 2] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[2ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
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であると指摘しなければなりません。 適切なテクニックの選択は、経路属性のための要件のセットでやる気満々であって展開シナリオに関する特定のテクニックへの適用性であるに違いありません。 例えば、要件が複数のドメインの向こう側に終わりから終わりへの規制ベースの最短パスを得ることであるなら、1分配されたPCEsを使用するメカニズムは、異なったドメインの向こう側に最短パスを計算するのに使用されるかもしれません([RFC4655]を見てください)。 経路計算のための他のオフラインメカニズムは排除されません。 また、Service Providerが、異なったTE LSPタイプに異なった相互ドメイン経路計算のテクニックを使用するのを選ぶかもしれないことに注意してください。
2. Terminology
2. 用語
Terminology used in this document:
このドキュメントで中古の用語:
AS: Autonomous System.
: 自律システム。
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: 領域Border Router、ルータが以前はよく2つのIGP領域をつなげていた、(OSPFの領域かIntermediate SystemへのIntermediate Systemのレベル、(-、)
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: 自治のSystem Border Router、ルータは1個以上の相互ASリンクを通して異なるか同じService Providerの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境界は、相互領域TEの文脈のABRか相互AS TEの文脈のASBRのどちらかです。
ERO: Explicit Route Object.
ERO: 明白なルート物。
IGP: Interior Gateway Protocol.
IGP: 内部のゲートウェイプロトコル。
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
相互、Te LSP: AS境界に交差するTE LSP。
Inter-area TE LSP: A TE LSP that crosses an IGP area.
相互領域Te LSP: IGP領域に交差するTE LSP。
Vasseur, et al. Standards Track [Page 3] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[3ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
LSR: Label Switching Router.
LSR: 切り換えルータをラベルしてください。
LSP: Label Switched Path.
LSP: ラベルは経路を切り換えました。
TE LSP: Traffic Engineering Label Switched Path.
Te LSP: 交通工学ラベルは経路を切り換えました。
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: 経路Computation Element、ネットワーク経路かルートを計算できる実体(コンポーネント、アプリケーション、またはネットワーク・ノード)はグラフと適用のコンピュータの規制をネットワークに基礎づけました。
TED: Traffic Engineering Database.
テッド: 交通工学データベース。
The notion of contiguous, stitched, and nested TE LSPs is defined in [RFC4726] and will not be repeated here.
隣接の、そして、ステッチされて、入れ子にされたTE LSPsの概念は、[RFC4726]で定義されて、ここで繰り返されないでしょう。
2.1. Requirements Language
2.1. 要件言語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. General Assumptions
3. 一般仮定
3.1. Common Assumptions
3.1. 一般的な想定
- 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.
- 以下のすべての例の各ドメインがTraffic Engineering(すなわち、OSPF-TEかイシス-TEとRSVP-TE(リソース予約プロトコルTraffic Engineering)を走らせる)ができると思われます。 ドメインがそうするかもしれない、それ自体、他の複数のドメインを包括してください、例えば、ASがそうしてもよい、それ自体、他の数個のサブASs(BGP同盟者)か領域/レベルで構成されてください。 この場合、相互領域と相互AS MPLS Traffic Engineeringのために説明された経路計算のテクニックは再帰的に適用されます。
- The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209] and
[RFC3473]).
- RSVP-TE([RFC3209]と[RFC3473])を使用することで相互ドメインTE LSPsは合図されます。
- 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 PathメッセージでERO(明白なRoute Object)によって指定される)は1セットの(ゆるい、そして/または、厳しい)のホップとして合図されるかもしれません。
- 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)
* 境界LSRsによって続かれたソースドメインの完全な厳しい経路(または、ドメイン識別子、例えば、AS番号)
Vasseur, et al. Standards Track [Page 4] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[4ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
* The complete list of boundary LSRs along the path
* 経路に沿った境界LSRsに関する全リスト
* 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.
(ゆるいか厳しい)のホップのセットをHead-終わりのLSRで静的に構成するか、またはダイナミックに計算できます。 TE LSPが合図されているとき本書では任意の自動発見メカニズム(例えば、IGP、BGPに基づいた方針ルーティング情報)が経路に沿って次のホップ境界ノード(Area Border Router(ABR)かAutonomous System Border Routerなどのドメインエキジットポイント(ASBR))をもたらしていて、1ドメインあたり1つの経路計算方法が定義されます、潜在的crankbackメカニズムと共に。あるいはまた、ドメインエキジットポイントはHead-終わりの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.
- 境界LSRsが経路がHead-終わりのLSRまでに1セットの厳しいホップとして合図されないか、厳しいホップが抽象的なノード(例えば、AS)であるなら合図されたEROの次のゆるいホップの拡大のための地方の経路計算を実行できると思われます。 情報がドメインの間に分配されるために必要としないどんなケース、トポロジーでないまたはどんなリソース([RFC4105]と[RFC4216]単位で強制されるように)でも全く。(それは、複数の経路ドメインにかかるTE LSPsの場合でIGP/BGPスケーラビリティと秘密性を保存するために重要です)。
- 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.
- イントラドメインのHierarchical LSP(H-LSP)かStitched LSP(S-LSP)か到着している相互ドメインLSPに基づいてダイナミックにあらかじめ設定されているかもしれないか、または計算されたドメインの中の隣接のTE 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].
- 横切って帯域幅のようなある規制を使用できる間、異なったドメイン(リソースの親近感のような他のあるTE規制)は着色します、メートル法であり、[RFC2702]に記載されているなどは、ドメイン境界で翻訳される必要があるかもしれません。 必要なら、ドメイン境界の向こう側にそのような規制を翻訳するために政策協定に基づくある種のローカルのマッピングがLSRsドメイン境界に存在すると思われます。 そのような仮定が特に相互AS TEに適用されると予想されます: 例えば、ローカルのマッピングは[RFC4216]に述べられていて、実施が取り締まる相互AS TE協定と同様でしょう。
Vasseur, et al. Standards Track [Page 5] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[5ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
- 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).
- 本書では定義された手順はゆるいホップを抑制するEROと共にPathメッセージを受け取るどんなノード(境界ノードであるだけではない)か簡単な抽象的なノード(すなわち、1LSRを特定する抽象的なノード)でない抽象的なノードにも適切です。
3.2. Example of Topology for the Inter-Area TE Case
3.2. 相互領域Teケースのためのトポロジーに関する例
The following example will be used for the inter-area TE case in this document.
以下の例は相互領域TEケースに本書では使用されるでしょう。
<-area 1-><-- area 0 --><--- area 2 --->
------ABR1------------ABR3-------
| / | | \ |
R0--X1 | | X2---X3--R1
| | | / |
------ABR2-----------ABR4--------
<=========== Inter-area TE LSP =======>
<-領域1>の<--領域0--><。--- 領域2--->。------ABR1------------ABR3------- | / | | \ | R0--X1| | X2---X3--R1| | | / | ------ABR2-----------ABR4-------- <====== 相互領域Te LSP=======>。
Figure 1 - Example of topology for the inter-area TE case
図1--相互領域TEケースのためのトポロジーに関する例
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のLSRsです。 - 相互領域TE LSP T0は領域2で領域1のR0で由来して、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に対応している、唯一の経路計算のテクニックがこのドキュメントが等しくケースに当てはまる提案されたコネである、-、マルチレベルネットワーク。
- 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ショーでHead-終わりとTail-端の領域が領域0によるつなげられるケースについて表現しました。 2つのIGP領域の間の領域0を通るどんなトランジットもしない相互領域TE LSPに関するケースは排除されません。
Vasseur, et al. Standards Track [Page 6] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[6ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
3.3. Example of Topology for the Inter-AS TE Case
3.3. トポロジーに関する例、相互、Teケース
We consider the following general case, built on a superset of the various scenarios defined in [RFC4216]:
私たちは[RFC4216]で定義された様々なシナリオのスーパーセットに造られた以下の一般的なケースを考えます:
<-- AS1 ----> <------- AS2 ------><--- AS3 ----->
<--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
<。---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
<==== 相互、Te LSP(LSRへのLSR)===========または>。
<======== Inter-AS TE LSP (CE to ASBR) =>
<==== 相互、Te LSP(ASBRへのCe)は>と等しいです。
or
または
<================= Inter-AS TE LSP (CE to CE)===============>
<========= 相互、Te LSP(CeへのCe)===============>。
Figure 2 - Example of topology for the inter-AS TE case
図2--相互AS TEケースのためのトポロジーに関する例
The diagram depicted in Figure 2 covers all the inter-AS TE deployment cases described in [RFC4216].
ダイヤグラムは図2カバーに[RFC4216]で説明されたすべての相互AS TE展開ケースについて表現しました。
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.
- 異なったASsのASBRsはBGP同輩です。 通常ASBRsとインタコネクトする単一のホップリンクで走らないどんなIGPと相互ASBRと呼ばれたリンクもあります。
- 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.
- または、各ASがIGPを走らせる、(-、OSPF) 必要なIGP TE拡張子([RFC3630]、[RFC3784]、[RFC4203]、および[RFC4205]を見る)で。 言い換えれば、ASsは有効にされたTEです。
- CE: Customer Edge router.
- Ce: 顧客Edgeルータ。
- 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
- いくつかのIGP領域で各ASを作ることができます。 本書では説明された経路計算のテクニックは複数のIGP領域でされた、独身のASの弁護、ただ一つのIGP領域で作られた、複数のASs、または上記のどんな組み合わせにも適用されます。 簡単にするために、各経路ドメインはただ一つの領域であるとみなされるでしょう。
Vasseur, et al. Standards Track [Page 7] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[7ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
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.
本書では。 例からそれらのいくつかのASsが複数のIGP領域で作られている複数のASsにかかる相互AS TE LSPに関するケースを以下の上に容易に得ることができます。 本書では説明された1ドメインあたりの経路計算のテクニックはこの場合再帰的に適用されます。
- An inter-AS TE LSP T1 originated at R0 in AS1 and terminated at R6
in AS3.
- 相互AS TE LSP T1はAS3でAS1のR0で由来して、R6で終わりました。
4. Per-Domain Path Computation Procedures
4. 1ドメインあたりの経路計算手順
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).
1セットのゆるくて厳しいホップとどんな経路も定義できることに注意してください。 言い換えれば、いくつかの場合、いくつかのドメインで動態的経路計算に依存して、他のドメインの経路に厳重な管理を出すのは望ましいかもしれません(厳しいホップを定義して)。
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と共にPathメッセージを受け取るとき、[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か簡単な抽象的なノードでない抽象的なノード(すなわち、1LSRを特定する抽象的なノード)でPathメッセージを受け取ると、それは[RFC5151]で説明されるように手順に従わなければなりません。
In addition, the following procedures describe the path computation procedures that SHOULD be carried out on the LSR:
さらに、以下の手順はLSRの外で運ばれた状態でSHOULDがある経路計算手順について説明します:
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 次のホップドメインがPSC(パケットSwitch Capable)であり、バンドの制御チャンネルを使用して
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
上記の2つの状態が満たされているなら、境界LSR SHOULDは、次のホップでIPの可到達性(IGPかBGPを通した)があるかどうかチェックします。 次のホップが届かないなら、シグナリング失敗は起こります、そして、LSR SHOULDは.4セクション4.3[RFC3209]で説明されるようにエラーコード=24(「ルート設定問題」)と誤り部分符号でRSVP PathErrメッセージ上流を返送します。 利用可能なルーティング情報は示します。
Vasseur, et al. Standards Track [Page 8] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[8ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
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.
そんなに次にホップが届いている、選択されたルートがLSRドメイン境界でドメイン境界を通り抜けると予想されるでしょう。 ルーティング情報に基づくドメイン境界ポイントの決断がそうである、何、私たち、このドキュメントの同じくらい「自動発見」の用語。 そのような自動発見メカニズムがないとき、a) 相互領域TEの場合におけるABRか次のホップASの相互AS TEの場合におけるASBRが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に存在しているなら:
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 SHOULDを処理する境界LSRがERO拡大(強制的な経路を次のゆるいホップまで計算して、EROの厳しいノードとしてホップのリストを加えるのから成る過程)を実行します。 セットを満たさないどんな経路であるならも、見つけることができて、次に、これが経路計算、シグナリング失敗、およびRSVP PathErrメッセージとして扱われたSHOULDであるという規制では、.4セクション4.3[RFC3209]に基づく相互ドメインTE LSPに送ってください。
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
* LSR境界がイントラ領域H-LSP/ S-LSPセットアップの候補LSR(境界には、巣ごもるか、またはステッチするためのローカルの方針がある)であり、階層構造/巣篭もり([RFC5151]で定義された「隣接のLSP」ビットは設定されない)、このLSRから規制を満たす次のホップLSR境界までH-LSP/S-LSPが全くなければ、TE LSPは候補であり、それはSHOULD信号です。次のホップLSR境界へのH-LSP/S-LSP。 あらかじめ設定されたH-LSP(s)かS-LSP(s)が既に存在しているなら、それがそれらのイントラドメインLSPsの中で選び抜こうとするその時です。 ローカルの方針によって、この選択が失敗するなら、それは新しいH-LSP/S-LSPに合図するかもしれません。 H-LSP/S-LSPが首尾よく合図されるか、または選択されるなら、それは手順に従うのが[RFC5151]で説明した次のホップに相互ドメインPathメッセージを伝播します。 ある理由でダイナミックなH-LSP/S-LSPが次のホップ境界にセットアップするなら、LSRは失敗して、次に、これはSHOULDです。
Vasseur, et al. Standards Track [Page 9] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[9ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
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.
経路計算として扱われて、失敗とRSVP PathErrメッセージに合図するのが、SHOULDであったなら、上流へ相互ドメインLSPに送ってください。 あらかじめ構成されたH-LSP/S-LSPの選択が失敗して、ローカルの方針が経路計算として扱われた状態で動力H-LSP/S、このSHOULDを防いで、失敗とRSVP PathErrメッセージSHOULDを示して、同様に、上流へ相互ドメインTE LSPに送ってください。 これらのケース、.4セクション4.3[RFC3209]SHOULDで説明された手順の両方では、続かれて、失敗を扱ってください。
* 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」ビットは設定される)でなく、次に、それはSHOULDです。隣接のケースのように同じ手順を適用してください。
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境界はあらかじめ交渉されたかもしれないじっと見る契約に基づくいくつかの方針を当てはまるかもしれません。 次のホップLSR境界がいったん決定するようになると、上で説明されたものとしての同様の手順は従われています。
Note the following related to the inter-AS TE case:
以下が相互AS TEケースに関連したことに注意してください:
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.
相互AS TE LSP経路の計算で、IGP TEが全くそれらのリンクの上に有効にされませんが(相互ASBRリンクの上にIGP隣接番組が全くないように)、ASBRsが相互ASBRリンクに関連するTE情報をあふれさせるのを許容するのからおもしろい最適化手法は成ります。 これは、どんなIGPもそれらのリンクで走っていませんが、相互ASBRリンクがTEによって可能にされるのをもちろん含意します。
<-- AS1 ----> <------- AS2 ------><--- AS3 ----->
<--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
<。---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関連の情報の氾濫
Vasseur, et al. Standards Track [Page 10] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[10ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
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 Link州Advertisement(LSA)/の広告を出すだろう、-、IS LSP、Traffic Engineering TLVsはリンクASBR1-ASBR4に関連しました。
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リンクに関連している規制を考慮に入れながらすぐに川下のASでエントリーまでの、より適切なルート選択をASBRにするように、前のASにLSR(エントリーASBRであるかもしれない)を許容します。 これは規制の相互AS TE LSPセットを満たさない相互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].
まとめられたTE情報が全くASsの間で漏らされないことに注意してください。要件が[RFC4105]と[RFC4216]にリストアップされている状態で、ASsは言いなりになっています。
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をあふれさせる、(TLV22、-、)、経路ドメインに、以下のリンクの予約州と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が属する同じドメインの他のLSRsのTEDでASBRによって溯源されたリンクに対応する相互ASBR TEリンク情報を利用可能にします。 その結果、また、相互AS TE LSP経路のための経路計算は相互ASBRリンクを考慮に入れることができます。 これはリソース不足か満たされていない規制の場合に相互ASBRリンクで次のASに沿ってうまくいっているシグナリングの機会を改良するでしょう、そして、それはcrankbackの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.
オペレータが、階層的なステッチされたセグメントか1ホップのLSPを相互ASBRリンクに操作すると決めるかもしれないことに注意してください。
4.1. Example with an Inter-Area TE LSP
4.1. 相互領域Te LSPがある例
The following example uses Figure 1 as a reference.
以下の例は参照として図1を使用します。
4.1.1. Case 1: T0 Is a Contiguous TE LSP
4.1.1. ケース1: T0は隣接のTe LSPです。
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
Head-終わりのLSR(R0)は最初に、次のホップABR(ユーザによって手動で構成されるか、または自動発見メカニズムを使用することによって、ダイナミックに決定できる)を決定します。 R0は次に、選択された次のホップABR(ABR1)に達するように経路を計算して、Pathメッセージに合図します。 いつ
Vasseur, et al. Standards Track [Page 11] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[11ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
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.
PathメッセージはABR1に達して、それは最初に、LSP経路(たとえば、ABR3)、直接ERO(例えば、次のホップABRがゆるいホップとしてEROで指定されるなら)または上で指定された自動発見メカニズムを使用するのによる領域0から次のホップABRを決定します。
- 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.
1セットの経路が優先的にHead-終わりのLSRで構成して、注文できることに注意してください。 それぞれの優先権経路を異なった規制に関連づけることができます。 少なくともTE経路が相互領域TE LSPソースと目的地の間に存在しているなら相互領域TE LSPがいつもセットアップされるかもしれないのを保証するという規制なしで切り札のオプションを系統的に持っているのは望ましいかもしれません。 セットアップの場合に失敗かそれともTE LSPが失敗、実現を受けたのを示すのにおいてRSVP PathErrがいつ受け取られているかが特定の経路オプションa構成可能な量の回を再試行する可能性を支持するかもしれない、(任意に、各トライアル) aを試みる前に、下側の優先度の経路オプションの間には、ダイナミックな間隔がある状態で。
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は計算された経路に沿ってPathメッセージを送ります。 そして、Pathメッセージを受け取ると、ABR3は同様の手順を繰り返します。 ABR3が、経路が相互領域TE LSPの規制のセットに従っているのを見つけることができないなら、シグナリングの過程は止まります、そして、ABR3はPathErrメッセージをABR1に送ります。 そして、ABR1は、crankbackがこの相互領域TE LSPのために許容されているなら([RFC4920]を見てください)別の出口LSR(上記の例のABR4)境界を選択することによって、順番に新しい経路計算の引き金となることができます。 crankbackがその相互領域TE LSPのために許容されていないか、またはABR1がcrankbackを実行しないように構成されたならABR1 MUSTが止まるなら、別のABRを選択しようとしないで、シグナリングは、処理して、PathErrをHead-終わりのLSR(R0)まで進めなければなりません。
4.1.2. Case 2: T0 Is a Stitched or Nested TE LSP
4.1.2. ケース2: T0はステッチされたか入れ子にされたTe LSPです。
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.
Head-終わりのLSR(R0)は最初に、次のホップABR(ユーザによって手動で構成されるか、または自動発見メカニズムを使用することによって、ダイナミックに決定できる)を決定します。 R0は次に、選択された次のホップABRに達するように経路を計算して、Pathメッセージに合図します。 PathメッセージがABR1に達すると、それは、最初に、LSP経路(ABR3を言う)、直接ERO(例えば、次のホップABRがゆるいホップとしてEROで指定されるなら)または自動発見メカニズムを使用するのによる領域0からの次のホップABRが上で指定したことを決定します。
Vasseur, et al. Standards Track [Page 12] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[12ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
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は、それが相互領域TE LSP Pathメッセージで運ばれた規制に合っているABR3にH-LSPかS-LSPを持っているかどうかチェックします。 そうでなければ、H-LSPかS-LSPのためにABR1から規制を満たすABR3まで経路を計算して、ABR1はそれに従って、それをセットアップします。 また、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.
[RFC5151]で説明されたシグナリング手順を用いて、ABR1がいったん相互領域LSPにH-LSP/S-LSPを選択すると、ABR1は相互領域TE LSPへのPathメッセージをABR3に送ります。 巣篭もりかABR1がステッチするかどうかの如何にかかわらず相互領域TE LSPへのPathメッセージがいつもABR3に転送されることに注意してください。 そして、ABR3は全く同じ手順を繰り返します。 ABR3が、経路が相互領域TE LSPの規制のセットに従っているのを見つけることができないなら、ABR3はPathErrメッセージをABR1に送ります。 そして、crankbackがこの相互領域TE LSPのために許容されているなら([RFC4920]を見てください)、ABR1はそのようなLSPが存在しているなら順番に別のH-LSP/S-LSPをABR3に選択するか、または別の出口LSR(上記の例のABR4)境界を選択できます。 crankbackがその相互領域TE LSPのために許容されていないか、またはABR1がcrankbackを実行しないように構成されたなら、別の出口LSRを選択しようとしないで、ABR1はPathErrを相互領域Head終わりのLSR(R0)まで進めます。
4.2. Example with an Inter-AS TE LSP
4.2. 例、相互、Te LSP
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).
相互AS TE LSPを設立するための経路計算手順は上で説明された相互領域TE LSPのものと非常に同様です。 主な違いは相互ASBRリンクの存在に関連します。
4.2.1. Case 1: T1 Is a Contiguous TE LSP
4.2.1. ケース1: T1は隣接のTe LSPです。
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経路は両方の厳しいホップ、ゆるいホップ、または組み合わせの1セットとしてHead-終わりの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
例1では、上では、1ASあたり1つの経路計算がそれぞれAS1のためのR0、AS2のためのASBR4、およびAS3のためのASBR9に実行されます。 LSRがERO拡大を実行しなければならないとき、次のホップが同じASに属さなければならないか、直接次のホップASに接続されたASBRであるに違いないことに注意してください。 この後者の場合では、ASBRの可到達性は隣接しているASBRによって溯源されたIGP TE LSA/LSPで発表されます。 例では、上の1、TE LSP経路は以下と定義されます。 ASBR4(ゆるい)--ASBR9の(ゆるい)の-R6(ゆるい)。 これは、R0が経路を計算しなければならないのを含意します。
Vasseur, et al. Standards Track [Page 13] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[13ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
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.
したがって、R0からASBR4まで、R0がTE予約状態を得る必要性はASBR1-ASBR4リンク(ASBR1でAS1で水につかっている)に関連しました。 また、さらに、ASBR1は、ASBR4のIPアドレスがT1の経路構成で指定したと発表しなければなりません。
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は相互領域TE LSPへのPathメッセージをASBR4に送ります(ASBR4が選択された次のホップASBRであると思って)。 そして、ASBR4は全く同じ手順を繰り返します。 ASBR4が、経路が相互AS TE LSPの規制のセットに従っているのを見つけることができないなら、ASBR4はPathErrメッセージをASBR1に送ります。 次に、crankbackがこの相互AS TE LSPのために許容されているなら([RFC4920]を見てください)ASBR1が順番に、別のASBR(上記の例のASBR5)を選択できるか、crankbackがその相互AS TE LSPのために許容されていないか、またはASBR1がcrankbackを実行しないように構成されたなら、別の出口LSRを選択しようとしないで、ABR1はHead-終わりのLSR(R0)までシグナリングの過程を止めて、PathErrを進めます。 この場合、構成されるなら、Head-終わりのLSRは順番にゆるいホップの別の系列を選択できます。 あるいはまた、Head-終わりのLSRは、同じ経路を再試行すると決めるかもしれません。 これはいくつかの川下のASの時代遅れのIGP TEデータベースによるセットアップ失敗の場合に役に立つ場合があります。 また、何らかの規制を弛緩した後にゆるいホップの同じ系列を再試行するために、代替手段はHead-終わりのLSRの間、あるかもしれません。
4.2.2. Case 2: T1 Is a Stitched or Nested TE LSP
4.2.2. ケース2: T1はステッチされたか入れ子にされたTe LSPです。
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-LSPsかS-LSPsがエントリーでASBRsによってASに溯源されます。
5. Path Optimality/Diversity
5. 経路の最適/多様性
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がドメイン(領域、AS)ベースで計算されるので、1つは、最適の相互ドメイン経路を見つけることができるのを保証できません。
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).
そのうえ、1ドメインあたり1つの経路計算アプローチを使用することで2つのさまざまの経路を計算するのはいくらかのtopologies(周知の「トラッピング」問題による)で可能でないかもしれません。
For example, consider the following simple topology:
例えば、↓これが簡単なトポロジーであると考えてください:
+-------+
/ \
A----B-----C------D
\ /
+---------+
+-------+/\A----B-----C------D\/+---------+
Figure 4 - Example of the "trapping" problem
図4--「トラッピング」問題に関する例
Vasseur, et al. Standards Track [Page 14] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[14ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
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.
連載されたアプローチが本書では指定された1ドメインあたりの経路計算のテクニックを使用している状態で図4に表現された簡単なトポロジーでは、経路A B C Dに続いて、最初のTE LSPを計算したかもしれません、その場合、2つのさまざまの経路が実際に存在していますが、どんなさまざまの経路も見つけることができませんでした: C Dと1B-Dです。 容易に相互ドメインケースに広げることができるその簡単な例の目的はさまざまの経路が存在していると1ドメインあたりの経路計算アプローチを使用することでさまざまの経路を見つけることができない潜在的問題を例証することです。
As already pointed out, the required path computation method can be selected by the Service Provider on a per-LSP basis.
既に指摘されるように、Service Providerは1LSPあたり1個のベースで必要な経路計算方法を選択できます。
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]).
1ドメインあたりの経路計算のテクニックが特定のTE LSP(例えば、経路の最適、さまざまに発送されたTE LSPsの1セットのための要件)のための要件のセットに会わないなら、PCEベースの経路計算のテクニックなどの他のテクニックは使用されるかもしれません([RFC4655]を見てください)。
6. Reoptimization of an Inter-Domain TE LSP
6. 相互ドメインTe LSPのReoptimization
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の自然に依存しています。
6.1. Contiguous TE LSPs
6.1. 隣接のTe LSPs
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がセットアップされた後に、より良いルートはどんな横断されたドメインの中にも現れるかもしれません。 この場合、次に、より良い経路に続くように非破壊的なファッション(いわゆる休みの前のMake手順を利用する)で相互ドメインがTE LSPであると別ルートで送る能力を得るのは望ましいです。 これはTE LSP reoptimization手順として知られているaです。
[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]はHead-終わりのLSRが川下のドメインの、より最適の経路の存在について通知されるのを許容するメカニズムを提案します。 そして、Head-終わりのLSRは、休みの前のMake手順を用いることで優雅にTE LSPを別ルートで送ると決めるかもしれません。 隣接のLSPの場合には、「再-最適化」の過程は[RFC3209]で定義されるように休みの前のMake手順の引き金となるHead-終わりのLSRまでに厳密に制御されます、より良い経路の位置にかかわらず。
Vasseur, et al. Standards Track [Page 15] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[15ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
6.2. Stitched or Nested (non-contiguous) TE LSPs
6.2. ステッチされたか入れ子にされた(非隣接の)Te LSPs
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がイントラドメインS-LSP、領域のH-LSPまたはASからの異なったLSP(そして、したがって、異なったRSVPセッション)であるということです。 したがって、局所的にイントラドメインのH-LSPかS-LSPを再最適化することによって、ドメインの「再-最適化」をします。 相互ドメインTE LSPsが各ドメインの向こう側にS-LSPかH-LSPを使用することで輸送されるので、ドメインの相互ドメインTE LSPの最適は対応するS-LSPかH-LSPの最適に依存しています。 相互ドメインLSPがセットアップされた後により最適の経路がドメインの中で利用可能であるなら、対応するS-LSPかH-LSPが、[RFC3209]で議論した休みの前のMakeのテクニックを使用することで再最適化されるでしょう。 H-LSPかS-LSPのReoptimizationは自動的に、H-LSPかS-LSPが輸送する相互ドメインTE LSPsを再最適化します。 「再-最適化」の頻度のようなReoptimizationパラメタ、メートル法か帯域幅有用性のような「再-最適化」の評価基準、などは1つのドメインから別のものに異なることができて、必要に応じてイントラドメインTE S-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.
したがって、休みの前のMakeは、各ドメインはそれ自身のS-LSPsを再最適化するか、H-LSPsの世話をして、したがって、対応する相互ドメインTE LSPsの世話をするので、この計画では、局所的に起こることができて、Head-終わりのLSRまでに相互ドメインLSPに引き起こされません。 それで、どんな追加RSVPシグナリングもLSP reoptimizationに必要ではありません、そして、「再-最適化」は相互ドメインTE LSPのHead-終わりの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へのHead-終わりのLSRのときに手動で「再-最適化」の引き金となることを望んでいるなら、この解決策はそれを防ぎません。 LSR SHOULDがその結果休みの前のMake手順を利用することで同じLSP(より最適の経路に沿った)のために「新しい」経路に合図する「再-最適化」を強制するHead-終わりの「再-最適化」のための手動の引き金。 この新しい構成要求に対応して、LSR境界は新しいS-LSPセットアップに着手するかもしれません、相互ドメインTE LSPがイントラドメインS-LSPにステッチされているか、または存在か新しいH-LSPを選択するといけないかもしれないので、巣篭もりの場合に。 現在の経路に沿ったLSPセットアップが完全であるときに、Head-終わりのLSRはその経路に交通を転換するはずです、そして、結局、古い経路を取りこわします。 Head-終わりのLSRが、より最適の経路が存在するかどうかを先験的に知らないことに注意してください。 しかしながら、相互ドメインTE LSPのHead-終わりのLSRからのそのような手動の引き金は多発であると考えられません。
Vasseur, et al. Standards Track [Page 16] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[16ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
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.
オペレータが、ある相互ドメインLSPsの地方の「再-最適化」を望んでいないなら、[RFC4736]で説明された手順を用いなければなりません。 この場合、ドメインの中のどんな「再-最適化」出来事もHead-エンドノードに報告しなければなりません。 このSHOULD、構成可能な方針になってください。
6.3. Path Characteristics after Reoptimization
6.3. Reoptimizationの後の経路特性
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).
TE LSPが隣接の相互ドメインTE LSPのゆるいホップ「再-最適化」か境界LSRsがゆるいホップとして指定されるステッチされたか入れ子にされたS-LSPの地方の「再-最適化」の場合では、1つ以上のドメインの中で望ましい経路に続くかもしれませんが、まだ境界LSRsの同じセットを横断していることに注意してください。 終わりから端への最適経路が計算されるので、対照的に、PCEベースの経路計算のテクニックの場合では、「再-最適化」の過程は、完全に異なった相互ドメイン経路に続くのに通じるかもしれません(境界LSRsの異なったセットを含んでいて)。
7. Security Considerations
7. セキュリティ問題
Signaling of inter-domain TE LSPs raises security issues (discussed in section 7 of [RFC5151]).
相互ドメインTE LSPsのシグナリングは安全保障問題([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]を見てください)注意が、キーが十分頻繁に変えられるのを保証するのに必要です。 管理か信用の異なったドメインを横断します、以下のメカニズムSHOULD。これが追加同期にかかわるかもしれないことに注意してください、ドメイン境界ノードがFast Reroute[RFC4090]と共に保護されるなら、また、Local Repair(PLR)のMerge Point(MP)とPointがキーを共有するはずであるので相互ドメインTE 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メッセージ処理を許容するメカニズム。
Vasseur, et al. Standards Track [Page 17] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[17ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
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.
このドキュメントは相互ドメイン経路計算に関連します。 本書では説明された経路を確立するための過程がASsの間で交換された情報を増加させないで、トポロジー秘密性を保存することに注意しなければなりません、[RFC4105]と[RFC4216]に従って。 それが言われていて、本書では定義された手順に従った相互ドメインTE LSPのシグナリングは様々な攻撃に露出されるかもしれない境界ノードの上で経路計算を必要とします。 したがって、許容されていないなら、それは相互ドメインTE LSPのERO拡大を拒絶するという政策決定を支持するRECOMMENDEDです。
8. Acknowledgements
8. 承認
We would like to acknowledge input and helpful comments from Adrian Farrel, Jean-Louis Le Roux, Dimitri Papadimitriou, and Faisal Aslam.
エードリアン・ファレル、ジャン・ルイル・ルー、ディミトリPapadimitriou、およびFaisal Aslamから入力と役に立つコメントを承諾したいと思います。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC3473] エドバーガー、L.、RFC3473、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)は資源予約プロトコル交通工学(RSVP-Te)拡大を示す」1月2003日
9.2. Informative References
9.2. 有益な参照
[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]ファレル、A.(エド)、Satyanarayana、A.、磐田、A.、フジタ、N.、およびG.灰、「MPLSのための拡大とGMPLS RSVP-Teに合図するCrankback」、RFC4920(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] ファレル、A.、エド、Ayyangar、A.、およびJP。 Vasseurに、「相互ドメインMPLSとGMPLSは工学を取引します--資源予約プロトコル交通工学(RSVP-Te)拡大」、RFC5151、2月2008日
[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.ファレル)は「一般化されたMultiprotocolラベル切り換え交通工学(GMPLS Te)でステッチされる切り換えられた経路をラベルします」、RFC5150、2008年2月。
Vasseur, et al. Standards Track [Page 18] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[18ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年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.とマルコムとJ.とAgogbuaとJ.とオデル、M.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(1999年9月)。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] ベイカーとF.とリンデル、B.とM.Talwar、「RSVPの暗号の認証」、RFC2747、2000年1月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097,
April 2001.
[RFC3097] ブレーデンとR.とL.チャン、「RSVPの暗号の認証--メッセージタイプ価値をアップデートする」RFC3097、2001年4月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC3630] キャッツ、D.、Kompella、K.、およびD.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計する交通、RFC3630、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] スミット、H.、およびT.李、「中間システムへの中間システム、(-、)、交通工学(Te)のための拡大、」、RFC3784(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]なべ、P.(エド)、ツバメ、G.(エド)、およびA.Atlas(エド)は「LSP Tunnelsのために速くRSVP-Teに拡大を別ルートで送ります」、RFC4090、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]ル・ルー、J.-L.(エド)、Vasseur、J.-P.、エドJ.ボイル(エド)、「相互領域MPLSのための要件は工学を取引します」、RFC4105、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.(エド)、およびY.Rekhter(エド)、「一般化されたマルチプロトコルを支持したOSPF拡張子は切り換え(GMPLS)をラベルします」、RFC4203、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.(エド)、およびY.Rekhter(エド)、「中間システムへの中間システム、(-、)、一般化されたマルチプロトコルを支持した拡大が切り換え(GMPLS)をラベルする、」、RFC4205(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] エドチャン、R.、J.-P。 Vasseur、エド「MPLS相互自律システム(AS)交通は(Te)要件を設計すること」でのRFC4216、2005年11月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC4655] ファレル、A.、Vasseur、J.-P.、およびJ.灰、「経路の計算の要素の(PCE)ベースの構造」、RFC4655、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] ファレル、A.、Vasseur、J.-P.、およびA.Ayyangar、「相互ドメインMultiprotocolラベル切り換え交通工学のための枠組み」、RFC4726(2006年11月)。
Vasseur, et al. Standards Track [Page 19] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[19ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
[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)、エド、Ikejiri、Y.、およびR.チャン、「Multiprotocolラベルの切り換え(MPLS)交通工学(Te)のReoptimizationは緩くラベルの切り換えられた経路(LSP)を発送しました」、RFC4736、11月2006
Authors' Addresses
作者のアドレス
JP Vasseur (editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA
Boxborough、JP Vasseur(エディタ)シスコシステムズInc.1414MA01719米国マサチューセッツ通り
EMail: jpv@cisco.com
メール: jpv@cisco.com
Arthi Ayyangar (editor) Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA
Arthi Ayyangar(エディタ)杜松は1194N.マチルダ・Aveカリフォルニア94089サニーベル(米国)をネットワークでつなぎます。
EMail: arthi@juniper.net
メール: arthi@juniper.net
Raymond Zhang BT 2160 E. Grand Ave. El Segundo, CA 90025 USA
レイモンドチャンBT2160のE.の壮大なAve。 エルセガンド、カリフォルニア90025米国
EMail: raymond.zhang@bt.com
メール: raymond.zhang@bt.com
Vasseur, et al. Standards Track [Page 20] RFC 5152 Path Comp. for Inter-Domain TE LSPs February 2008
Vasseur、他 標準化過程[20ページ]RFC5152経路コンピュータ相互ドメインTe LSPs2008年2月に
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Vasseur, et al. Standards Track [Page 21]
Vasseur、他 標準化過程[21ページ]
一覧
スポンサーリンク
