Network Working Group R. Zhang, Ed.
Request for Comments: 4216 Infonet Services Corporation
Category: Informational J.-P. Vasseur, Ed.
Cisco Systems, Inc.
November 2005
MPLS Inter-Autonomous System (AS)
Traffic Engineering (TE) Requirements
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document discusses requirements for the support of inter-AS MPLS Traffic Engineering (MPLS TE). Its main objective is to present a set of requirements and scenarios which would result in general guidelines for the definition, selection, and specification development for any technical solution(s) meeting these requirements and supporting the scenarios.
この文書では、相互AS MPLSトラフィックエンジニアリング（MPLS TE）をサポートするための要件について説明します。その主な目的は、技術的な解決策（複数可）、これらの要件を満たすとシナリオをサポートするための定義、選択、および仕様開発のための一般的なガイドラインにつながる要件とシナリオのセットを提示することです。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Contributing Authors ............................................4
3. Definitions and Requirements Statement ..........................5
3.1. Definitions ................................................5
3.2. Objectives and Requirements of Inter-AS Traffic
Engineering ................................................7
3.2.1. Inter-AS Bandwidth Guarantees .......................7
3.2.2. Inter-AS Resource Optimization ......................8
3.2.3. Fast Recovery across ASes ...........................8
3.3. Inter-AS Traffic Engineering Requirements Statement ........9
4. Application Scenarios ...........................................9
4.1. Application Scenarios Requiring Inter-AS Bandwidth
Guarantees .................................................9
4.1.1. Scenario I - Extended or Virtual PoP (VPoP) .........9
4.1.2. Scenario II - Extended or Virtual Trunk ............11
4.1.3. Scenario III - End-to-End Inter-AS MPLS TE
from CE to CE ......................................12
4.2. Application Scenarios Requiring Inter-AS Resource
Optimization ..............................................13
4.2.1. Scenario IV - TE across multi-AS within a
Single SP ..........................................13
4.2.2. Scenario V - Transit ASes as Primary and
Redundant Transport ................................14
5. Detailed Requirements for Inter-AS MPLS Traffic Engineering ....16
5.1. Requirements within One SP Administrative Domain ..........16
5.1.1. Inter-AS MPLS TE Operations and Interoperability ...16
5.1.2. Protocol Signaling and Path Computations ...........16
5.1.3. Optimality .........................................17
5.1.4. Support of Diversely Routed Inter-AS TE LSP ........17
5.1.5. Re-Optimization ....................................18
5.1.6. Fast Recovery Support Using MPLS TE Fast Reroute ...18
5.1.7. DS-TE Support ......................................18
5.1.8. Scalability and Hierarchical LSP Support ...........19
5.1.9. Mapping of Traffic onto Inter-AS MPLS TE Tunnels ...19
5.1.10. Inter-AS MPLS TE Management .......................19
5.1.10.1. Inter-AS MPLS TE MIB Requirements ........19
5.1.10.2. Inter-AS MPLS TE Fault Management
Requirements .............................20
5.1.11. Extensibility .....................................21
5.1.12. Complexity and Risks ..............................21
5.1.13. Backward Compatibility ............................21
5.1.14. Performance .......................................21
5.2. Requirements for Inter-AS MPLS TE across Multiple SP ......22
5.2.1. Confidentiality ....................................22
5.2.2. Policy Control .....................................23
5.2.2.1. Inter-AS TE Agreement Enforcement
Polices ...................................23
5.2.2.2. Inter-AS TE Rewrite Policies ..............24
5.2.2.3. Inter-AS Traffic Policing .................24
6. Security Considerations ........................................24
7. Acknowledgements ...............................................24
8. Normative References ...........................................25
9. Informative References .........................................25
Appendix A. Brief Description of BGP-based Inter-AS Traffic
Engineering ...........................................27
The MPLS Traffic Engineering (TE) mechanism documented in [TE-RSVP] may be deployed by Service Providers (SPs) to achieve some of the most important objectives of network traffic engineering as described in [TE-OVW]. These objectives are summarized as:
[TE-RSVP]で文書MPLSトラフィックエンジニアリング（TE）のメカニズムは、[TE-OVW]で説明したように、ネットワークのトラフィックエンジニアリングの最も重要な目標の一部を達成するためのサービスプロバイダ（SPの）によって展開されてもよいです。これらの目的は、以下のように要約されます。
- Supporting end-to-end services requiring Quality of Service (QoS) guarantees - Performing network resource optimization - Providing fast recovery
- 高速リカバリの提供 - ネットワークリソースの最適化を実行する - サービス品質（QoS）の保証を必要とするエンドツーエンドのサービスをサポート
However, this traffic engineering mechanism can only be used within an Autonomous System (AS).
しかし、このトラフィックエンジニアリングのメカニズムは、自律システム（AS）内にのみ使用することができます。
This document discusses requirements for an inter-AS MPLS Traffic Engineering mechanism that may be used to achieve the same set of objectives across AS boundaries within or beyond an SP's administrative domains.
この文書では、SPの管理ドメイン内または超えたASの境界を越えて目的の同じセットを達成するために使用することができる相互AS MPLSトラフィックエンジニアリングのメカニズムのための要件について説明します。
The document will also present a set of application scenarios where the inter-AS traffic engineering mechanism may be required. This mechanism could be implemented based upon the requirements presented in this document.
文書はまた、AS間トラフィックエンジニアリングのメカニズムが必要になることがありアプリケーションシナリオのセットを提示します。このメカニズムは、この文書の要件に基づいて実施することができます。
These application scenarios will also facilitate discussions for a detailed requirements list for this inter-AS Traffic Engineering mechanism.
これらのアプリケーションシナリオも、このAS間トラフィックエンジニアリングのメカニズムのための詳細な要件のリストについては、議論を促進します。
Please note that there are other means of traffic engineering including Interior Gateway Protocol (IGP); metrics-based (for use within an AS); and Border Gateway Protocol (BGP) attribute-based (for use across ASes, as described in Appendix A), which provide coarser control of traffic paths. However, this document addresses requirements for a MPLS-based, fine-grained approach for inter-AS TE.
インテリアゲートウェイプロトコル（IGP）を含むトラフィックエンジニアリングの他の手段があることに注意してください。メトリックベース（AS内で使用するため）。トラフィックパスの粗い制御を提供し、ボーダーゲートウェイプロトコル（BGP）属性ベース（のAS全体で使用するための、付録Aに記載されているように）。しかし、この文書は相互AS TEのためのMPLSベースの、きめの細かいアプローチに対する要件に対応します。
This document doesn't make any claims with respect to whether it is possible to have a practical solution that meets all the requirements listed in this document.
この文書は、この文書に記載されているすべての要件を満たしている実用的なソリューションを持つことが可能であるかどうかに関して、いかなる主張をしません。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC-2119]に記載されているように解釈されます。
The co-authors listed below contributed to the text and content of this document. (The contact information for the editors appears in section 9, and is not repeated below.)
下記に記載された共著者は、この文書のテキストやコンテンツに貢献しました。 （編集者の連絡先情報は、セクション9に表示され、以下省略する。）
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN EMail : ke-kumaki@kddi.com
けんじ くまき Ｋっぢ こｒぽらちおん がｒでん あいｒ とうぇｒ いいだばし、 ちよだーく、 ときょ １０２ー８４６０、 じゃぱん えまいｌ ： けーくまき＠ｋっぢ。こｍ
Paul Mabey Qwest Communications 950 17th Street, Denver, CO 80202, USA EMail: pmabey@qwest.com
ポールMabeyクエスト・コミュニケーションズ950 17thストリート、デンバー、CO 80202、USA Eメール：pmabey@qwest.com
Nadim Constantine Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025. USA EMail: nadim_constantine@infonet.com
ナディムコンスタンティンインフォネット・サービス株式会社2160 E.グランドアベニューエル・セグンド、CA 90025. USA電子メール：nadim_constantine@infonet.com
Pierre Merckx EQUANT 1041 route des Dolines - BP 347 06906 SOPHIA ANTIPOLIS Cedex, FRANCE EMail: pierre.merckx@equant.com
ピエール・メルクスイクアント1041ルートDolines - BP 347 06906ソフィアアンティポリスセデックス、FRANCE Eメール：pierre.merckx@equant.com
Ting Wo Chung Bell Canada 181 Bay Street, Suite 350 Toronto, Ontario, Canada, M5J 2T3 EMail: ting_wo.chung@bell.ca
ting_wo.chung@bell.ca：チョンベル・カナダ181ベイストリート、スイート350トロント、オンタリオ州、カナダ、M5J 2T3メール臥ティン
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex, France EMail: jeanlouis.leroux@francetelecom.com
ジャン=ルイ・ルーフランステレコム2、大通りピエールMarzin 22307ラニオンセデックス、フランスEメール：jeanlouis.leroux@francetelecom.com
Yonghwan Kim SBC Laboratories, Inc. 4698 Willow Road Pleasanton, CA 94588, USA EMail: Yonghwan_Kim@labs.sbc.com
YonghwanキムSBCラボラトリーズ社4698ウィロー・ロードプレザントン、CA 94588、USA Eメール：Yonghwan_Kim@labs.sbc.com
The following provides a list of abbreviations and acronyms specifically pertaining to this document:
以下、具体的に、このドキュメントに関連する略語のリストを提供します。
SP: Service Providers including regional or global providers.
SP：地域やグローバルプロバイダなどのサービスプロバイダ。
SP Administrative Domain: a single SP administration over a network or networks that may consist of one AS or multiple ASes.
SP管理ドメイン：一つとして、又は複数のASから成ることができるネットワークまたはネットワーク上の単一のSP投与。
IP-only networks: SP's network where IP routing protocols such as IGP/BGP are activated.
IPのみのネットワーク：SPのネットワークなどIGP / BGPなどのIPルーティングプロトコルが活性化されます。
IP/MPLS networks: SP's network where MPLS switching capabilities and signaling controls (e.g., ones described in [MPLS-ARCH]) are activated in addition to IP routing protocols.
IP / MPLSネットワーク：機能を切り替えて制御シグナリングMPLS SPのネットワーク（例えば、に記載されたもの[MPLS-ARCH]）IPルーティングプロトコルに加えて、活性化されます。
Intra-AS TE: A generic definition for traffic engineering mechanisms operating over IP-only and/or IP/MPLS network within an AS.
イントラAS TE：AS内IP-のみおよび/またはIP / MPLSネットワーク上で動作するトラフィックエンジニアリングのメカニズムのための一般的な定義。
Inter-AS TE: A generic definition for traffic engineering mechanisms operating over IP-only and/or IP/MPLS network across one or multiple ASes. Since this document only addresses IP/MPLS networks, any reference to Inter-AS TE in this document refers only to IP/MPLS networks and is not intended to address IP-only TE requirements.
インターAS TE：1または複数のAS間でIP-のみおよび/またはIP / MPLSネットワーク上で動作するトラフィックエンジニアリングのメカニズムのための一般的な定義。この文書は唯一のIP / MPLSネットワークを扱っているので、この文書に記載されている間AS TEへの参照は、IP / MPLSネットワークを参照し、IP-のみTE要件に対応するものではありません。
TE LSP: MPLS Traffic Engineering Label Switched Path.
TE LSP：MPLSトラフィックエンジニアリングラベルスイッチパス。
Intra-AS MPLS TE: An MPLS Traffic Engineering mechanism where its TE Label Switched Path (LSP), Head-end Label Switching Router (LSR), and Tail-end LSR reside in the same AS for traffic engineering purposes.
イントラAS MPLS TE：そのTEラベルスイッチパス（LSP）は、ルータ（LSR）を切り替えるヘッドエンドラベル、およびテールエンドLSRは、トラフィックエンジニアリングの目的で、ASと同じに常駐MPLSトラフィックエンジニアリングメカニズム。
Inter-AS MPLS TE: An MPLS Traffic Engineering mechanism where its TE LSPs, Head-end LSR, and Tail-end LSR do not reside within the same AS or both Head-end LSR and Tail-end LSR are in the same AS, but the TE LSP transiting path may be across different ASes.
インターAS MPLS TE：そのTEのLSP、ヘッドエンドLSR、およびテールエンドLSRは同じAS内に存在していないか、ヘッドエンドLSRとテールエンドLSRの両方が同じASにあるMPLSトラフィックエンジニアリングのメカニズム、しかし、TE LSP遷移パスが異なるのASを横断してもよいです。
ASBRs: Autonomous System Border Routers used to connect to another AS of a different or the same Service Provider via one or more links that interconnect ASes.
ASBRは：自律システム境界ルータは、のASを相互接続する1つまたは複数のリンクを経由して異なるまたは同じサービスプロバイダーのAS別に接続するために使用されます。
Inter-AS TE Path: A TE path traversing multiple ASes and ASBRs, e.g., AS1-ASBR1-inter-AS link(s)-ASBR2-AS2... ASBRn-ASn.
インターAS TEパス：複数のASとのASBR、例えば、AS1-ASBR1-AS間リンク（S）-ASBR2-AS2 ... ASBRn-ASNを横断TEパス。
Inter-AS TE Segment: A portion of the Inter-AS TE path.
インターAS TEセグメント：インターAS TEパスの一部。
Inter-AS DS-TE: Diffserv-aware Inter-AS TE.
インターAS DS-TE：Diffservの認識のInter-AS TE。
CE: Customer Edge Equipment
CE：カスタマーのエッジ機器
PE: Provider Edge Equipment that has direct connections to CEs.
PE：CEに直接接続しているプロバイダーエッジ機器。
P: Provider Equipment that has backbone trunk connections only.
P：唯一のバックボーントランク接続を持っているプロバイダ装置。
VRF: Virtual Private Network (VPN) Routing and Forwarding Instance.
VRF：仮想プライベートネットワーク（VPN）ルーティングおよび転送インスタンス。
PoP: Point of presence or a node in SP's network.
PoP：存在またはSPのネットワーク内のノードのポイント。
SRLG: A set of links may constitute a 'shared risk link group' (SRLG) if they share a resource whose failure may affect all links in the set as defined in [GMPLS-ROUT].
SRLG：彼らは、その故障[GMPLS-ROUT]で定義されるようにセット内のすべてのリンクに影響を与える可能性があるリソースを共有する場合、リンクの組が「共有リスク・リンク・グループ」（SRLG）を構成してもよいです。
PCC: Path Computation Client; any client application requesting a path computation to be performed by the Path Computation Element.
PCC：経路計算クライアント。経路計算要素によって実行される経路計算を要求するすべてのクライアントアプリケーション。
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：パス計算要素。ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用することが可能なエンティティ（コンポーネント、アプリケーション、またはネットワークノード）。
Please note that the terms of CE, PE, and P used throughout this document are generic in their definitions. In particular, whenever such acronyms are used, it does not necessarily mean that CE is connected to a PE in a VRF environment described in such IETF documents as [BGP-MPLSVPN].
この文書全体で使用されるCE、PE、およびPの用語は、それらの定義では一般的なものであることに注意してください。特に、このような頭字語が使用されるときはいつでも、それは必ずしもCEが[BGP-MPLSVPN]などのIETF文書に記載VRF環境でPEに接続されていることを意味するものではありません。
As mentioned in section 1 above, some SPs have requirements for achieving the same set of traffic engineering objectives as presented in [TE-OVW] across AS boundaries.
上記のセクション1で述べたように、いくつかのSPは、ASの境界を越えて[TE-OVW]で提示されたトラフィックエンジニアリングの目的の同じセットを達成するための要件があります。
This section examines these requirements in each of the key corresponding areas: 1) Inter-AS bandwidth guarantees; 2) Inter-AS Resource Optimization and 3) Fast Recovery across ASes, i.e., Recovery of Inter-AS Links/SRLG and ASBR Nodes.
このセクションでは、キー対応の各分野で、これらの要件を調べ：1）AS間の帯域保証を。 2）AS間のリソースの最適化とのAS間3）高速回復、すなわち、AS間リンク/ SRLGとASBRノードの回復。
The Diffserv IETF working group has defined a set of mechanisms described in [DIFF_ARCH], [DIFF_AF], and [DIFF_EF] or [MPLS-Diff]. These mechanisms can be activated at the edge of or over a Diffserv domain to contribute to the enforcement of a QoS policy (or a set of QoS policies), which can be expressed in terms of maximum one-way transit delay, inter-packet delay variation, loss rate, etc.
DiffservのIETFワーキンググループは、[DIFF_EF]または[MPLS-差分] [DIFF_AF]、[DIFF_ARCH]で説明されたメカニズムのセットを定義して、そしてました。これらのメカニズムは、最大片方向伝送遅延の観点で表現することができるQoSポリシー（またはQoSポリシーのセット）の施行に貢献するのDiffservドメイン、パケット間遅延の又は上縁に活性化することができます変動、損失率など
Many SPs have partial or full deployment of Diffserv implementations in their networks today, either across the entire network or minimally on the edge of the network across CE-PE links.
多くのSPは、ネットワーク全体または最小限CE-PEリンク間ネットワークのエッジ上のいずれか、今日そのネットワーク内のDiffservの実装の部分的または完全な展開を持っています。
In situations where strict QoS bounds are required, admission control inside the backbone of a network is in some cases required in addition to current Diffserv mechanisms.
厳密なQoS境界が必要とされる状況では、ネットワークのバックボーン内のアドミッション制御は、現在のDiffserv機構に加えて、必要ないくつかのケースです。
When the propagation delay can be bounded, the performance targets, such as maximum one-way transit delay, may be guaranteed by providing bandwidth guarantees along the Diffserv-enabled path.
伝播遅延が境界できる場合、そのような最大片道の伝送遅延などの性能目標は、Diffservの有効な経路に沿って帯域保証を提供することによって保証することができます。
One typical example of this requirement is to provide bandwidth guarantees over an end-to-end path for VoIP traffic classified as EF (Expedited Forwarding [DIFF_EF]) class in a Diffserv-enabled network. When the EF path is extended across multiple ASes, inter-AS bandwidth guarantee is then required.
この要件の一つの典型的な例は、Diffservの対応ネットワークにおけるEF（緊急転送[DIFF_EF]）クラスとして分類されたVoIPトラフィックのエンドツーエンドパス上の帯域幅保証を提供することです。 EFパスが複数のAS間で延長された場合、AS間の帯域幅保証は、その後必要になります。
Another case for inter-AS bandwidth guarantee is the requirement for guaranteeing a certain amount of transit bandwidth across one or multiple ASes.
AS間の帯域保証のためのもう一つのケースは、一つまたは複数のAS間でのトランジット一定量の帯域幅を保証するための必要条件です。
Several application scenarios are presented to further illustrate this requirement in section 4 below.
いくつかのアプリケーションシナリオは、さらに以下のセクション4で、この要件を例示するために提示されます。
In Service Provider (SP) networks, the BGP protocol [BGP] is deployed to exchange routing information between ASes. The inter-AS capabilities of BGP may also be employed for traffic engineering purposes across the AS boundaries. Appendix A provides a brief description of the current BGP-based inter-AS traffic engineering practices.
サービスプロバイダ（SP）ネットワークでは、BGPプロトコルは、[BGP]のAS間でルーティング情報を交換するために配備されます。 BGPのAS間の機能もASの境界を越えてトラフィックエンジニアリングの目的のために使用することができます。付録Aには、現在のBGPベースの相互ASトラフィックエンジニアリングの実践について簡単に説明します。
SPs have managed to survive with this coarse set of BGP-based traffic engineering facilities across inter-AS links in a largely best-effort environment. Certainly, in many cases, ample bandwidth within an SP's network and across inter-AS links reduces the need for more elaborate inter-AS TE policies.
SPは、主にベストエフォート環境でのAS間リンク間でBGPベースのトラフィックエンジニアリング施設のこの粗いセットで生き残るために管理しています。確かに、多くの場合、SPのネットワーク内およびAS間リンク間で十分な帯域幅がより複雑な相互AS TE政策の必要性を低減します。
However, in the case where a SP network is deployed over multiple ASes (for example, as the number of inter-AS links grows), the complexity of the inter-AS policies and the difficulty in inter-AS TE path optimization increase to a level such that it may soon become unmanageable.
しかし、（AS間リンクの数が増えると、例えば）SPネットワークが複数のAS上で展開されている場合、AS間のポリシーと相互AS TE経路最適化が増加することの困難の複雑にそれはすぐに管理不能になることができるようにレベル。
Another example is where inter-AS links are established between different SP administrative domains. Nondeterministic factors such as uncoordinated routing and network changes, as well as sub-optimum traffic conditions, would potentially lead to a complex set of inter-AS traffic engineering policies where current traffic engineering mechanisms would probably not scale well.
AS間リンクが異なるSP管理ドメイン間で確立されている場合別の例はあります。そのようなまとまりのないルーティングやネットワークの変更だけでなく、サブ最適な交通条件などの非決定的な要因は、潜在的に現在のトラフィックエンジニアリングのメカニズムはおそらくうまくスケールではないでしょうAS間トラフィックエンジニアリングポリシーの複雑なセットにつながります。
In these situations where resource optimization is required and/or specific routing requirements arise, the BGP-based inter-AS facilities will need to be complemented by a more granular inter-AS traffic engineering mechanism.
リソースの最適化が必要および/または特定のルーティング要件が発生しているこのような状況では、BGPベースの相互AS施設は、より詳細な相互ASトラフィックエンジニアリングメカニズムによって補完される必要があります。
When extending services such as VoIP across ASes, customers often require SPs to maintain the same level of performance targets, such as packet loss and service availability, as achieved within an AS. As a consequence, fast convergence in a stable fashion upon link/SRLG/node failures becomes a strong requirement. This is clearly difficult to achieve with current inter-domain techniques, especially in cases of link/SRLG failures between ASBRs or ASBR node failures.
このようのAS間のVoIPなどのサービスを拡張する場合、顧客は多くの場合、AS内で達成として、このようなパケットロスやサービスの可用性、パフォーマンス目標、同じレベルを維持するためのSPが必要です。その結果、リンク/ SRLG /ノード障害時に安定的で高速な収束が強く要件となります。これは特に、ASBRはやASBRノード障害との間のリンク/ SRLG障害の例には、明らかに現在のドメイン間の技術では達成することは困難です。
Just as in the applicable case of deploying MPLS TE in an SP's network, an inter-AS TE method in addition to BGP-based traffic engineering capabilities needs to be deployed across inter-AS links where resource optimization, bandwidth guarantees and fast recovery are required.
ただ、SPのネットワークでMPLS TEを展開該当する場合のように、BGPベースのトラフィックエンジニアリング機能に加えて、相互AS TEの方法は、リソースの最適化、帯域幅の保証と高速リカバリが必要とされているAS間リンク上に配備する必要があります。
This is especially critical in a Diffserv-enabled, multi-class environment described in [PSTE] where statistical performance targets must be maintained consistently over the entire path across different ASes.
これは、統計的な性能目標を別のASを横断経路全体にわたって一貫して維持されなければならない[PSTE]に記載のDiffserv対応、多クラス環境では特に重要です。
The approach of extending current intra-AS MPLS TE capabilities [TE-RSVP] across inter-AS links for IP/MPLS networks is considered here because of already available implementations and operational experiences.
IP / MPLSネットワークのためのAS間リンクを介して、現在のイントラAS MPLS TE機能[TE-RSVP]を拡張するアプローチがあるため、既に利用可能な実装と運用の経験をここでは考慮されています。
Please note that the inter-AS traffic engineering over an IP-only network is for future consideration since there is not sufficient interest for similar requirements to those of IP/MPLS networks at this time. More specifically, this document only covers the inter-AS TE requirements for packet-based IP/MPLS networks.
十分な関心が、この時点でのIP / MPLSネットワークのものと同様の要件のためにそこにいないので、AS間トラフィックエンジニアリングIPのみのネットワーク上では、今後の検討のためであることに注意してください。具体的には、このドキュメントでは、パケットベースのIP / MPLSネットワークのための相互AS TEの要件をカバーしています。
The following sections present a few application scenarios over IP/MPLS networks where requirements cannot be addressed with the current intra-AS MPLS TE mechanism and give rise to considerations for inter-AS MPLS traffic engineering requirements.
次のセクションでは、要件が現在のイントラAS MPLS TEメカニズムと対処し、相互AS MPLSトラフィックエンジニアリング要件について検討事項を生じさせることができないIP / MPLSネットワーク上で、いくつかのアプリケーションシナリオを提示します。
Although not explicitly noted in the following discussions, fast recovery of traffic path(s) crossing multiple ASes in a stable fashion is particularly important in the case of link/SRLG/node failures at AS boundaries for all application scenarios presented here.
明示的に以下の議論で指摘されていないが、安定した形で複数のASを通過するトラフィックパス（複数可）の高速リカバリは、ここに提示されたすべてのアプリケーションシナリオのための境界としてリンク/ SRLG /ノード障害の場合に特に重要です。
A global service provider (SP1) would like to expand its reach into a region where a regional service provider's (SP2) network has already established a denser network presence.
グローバルサービスプロバイダ（SP1）は、地域のサービスプロバイダの（SP2）ネットワークがすでに密度の高いネットワークのプレゼンスを確立している領域にその範囲を拡大したいと考えています。
In this scenario, the SP1 may establish interconnections with SP2 in one or multiple points in that region. In their customer-dense regions, SP1 may utilize SP2's network as an extended transport by co-locating aggregation routers in SP2's PoPs.
このシナリオでは、SP1は、その領域内の1つのまたは複数のポイントにSP2との相互接続を確立することができます。顧客密度の高い領域では、SP1はSP2ののPoPにおける共位置決めアグリゲーションルータによって拡張トランスポートとしてSP2のネットワークを利用してもよいです。
In order to ensure bandwidth capacity provided by SP2 and to achieve some degrees of transparency to SP2's network changes in terms of capacity and network conditions, one or more inter-AS MPLS TE LSPs can be built between SP1's ASBR or PE router inside AS1 and SP1's PE routers co-located in SP2's PoPs, as illustrated in the diagram below:
順SP2によって提供される帯域幅容量を確保し、容量及びネットワーク条件の面でSP2のネットワーク変更に透明のある程度を達成するために、一つ以上の相互AS MPLS TE LSPはAS1内部SP1のASBR又はPEルータ間で構築され、SP1のことができます以下の図に示すように、PEルータは、SP2ののPoPにある同一位置します：
<===========Inter-AS MPLS TE Tunnel===========>
----- -----
________|ASBR |___Inter-AS___|ASBR |________
| | RTR | Link | RTR | |
---- ----- ----- ----- -----
|SP1 |_Inter-AS_| SP2 | | SP1 |
|VPoP| Link |P/PE | |P/PE |
---- ----- ----- ----- -----
|________|ASBR |___Inter-AS___|ASBR |________|
| RTR | Link | RTR |
----- -----
<=================Inter-AS MPLS TE Tunnel======================>
+-SP1 AS1-+ +---SP2 AS2-----+ +------SP1 AS1------+
In situations where end-to-end Diffserv paths must be maintained, both SPs' networks may need to provision Diffserv PHB at each hop in order to support a set of traffic classes with compatible performance targets. The subsequent issues regarding Service Level Agreement (SLA) boundaries, reporting and measuring system interoperability and support demarcations are beyond the scope of this document and are not discussed further.
エンドツーエンドのDiffserv経路が維持されなければならない状況では、両方のSPネットワークは、互換性の性能目標を持つトラフィッククラスのセットをサポートするために、各ホップで提供たDiffserv PHBする必要があるかもしれません。システムの相互運用性とサポート境界設定を報告し、測定サービスレベル契約（SLA）の境界について、その後の問題は、このドキュメントの範囲を超えて、さらに議論されていません。
If either SP1's or SP2's network is not a Diffserv-aware network, the scenario would still apply to provide bandwidth guarantees.
いずれかのSP1のか、SP2のネットワークがDiffservの対応のネットワークではない場合、シナリオはまだ帯域幅保証を提供するために適用されます。
The SP2, on the other hand, can similarly choose to expand its reach beyond its servicing region over SP1's network via inter-AS MPLS TE tunnels.
SP2は、他の一方で、同様に相互AS MPLS TEトンネルを経由してSP1のネットワークを介してその整備領域を越えてその範囲を拡大することを選択できます。
It is worth mentioning that these remote aggregation routers co-located in another SP's network are unlikely to host SP1's IGP and BGP routing planes and will more likely maintain their own AS or be part of the SP1's AS. In this case, such TE tunnels may cross several ASes, but the Head-end and Tail-end LSRs of TE tunnel may have the same AS number, as shown in the diagram above.
別のSPのネットワーク内に同じ場所に配置これらのリモート集約ルータは、SP1のIGPとBGPルーティングプレーンをホストする可能性は低いと可能性が高く、自分のASを維持するか、SP1のASの一部になることを言及する価値があります。この場合、TEトンネルは、いくつかのASを横断してもよいが、TEトンネルのヘッドエンドとテールエンドのLSRは、上記の図に示すように、同じAS番号を有していてもよいです。
Instead of co-locating a PE router in SP2's PoP, SP1 may also choose to aggregate customer VPN sites onto a SP2's PE router where inter-AS TE tunnels can be built and signaled through SP2's MPLS network between the SP2 PoP (to which SP1 and customer CEs are directly connected) and SP1's ASBR or PE routers inside SP1's network. This allows SP1's customers connected to SP2 PE router to receive a guaranteed bandwidth service up to the TE LSP tail-end router located in SP1's network.
代わりに、SP2のPOPにおけるPEルータを共配置する、SP1はまた、インターAS TEトンネルが構築され、SP2ポップ間SP2のMPLSネットワークを通じてシグナリングすることができるSP2のPEルータに顧客VPNサイトを集約することを選択することができる（これはSP1および顧客のCEは、直接接続されている）とSP1のASBR又はPEルータSP1のネットワーク内にあります。これは、SP2 PEルータに接続されているSP1の顧客は、SP1のネットワーク内に位置するTE LSPテールエンドルータに帯域保証サービスを受けることができます。
In this scenario, there could be two applicable cases:
このシナリオでは、2つの適用例があるかもしれません。
Case 1 - the inter-AS MPLS TE tunnel functions as an extended or virtual trunk aggregating SP1's CE's local-loop access circuits on SP2's MPLS network over which the bandwidth can be guaranteed to the TE LSP tail-end router located in SP1's network, as shown in the diagram below:
ケース1 - インターAS MPLS TEトンネル機能帯域幅として、SP1のネットワークに位置TE LSPテールエンドルータに保証することができる上にSP2のMPLSネットワーク上SP1のCEのローカル・ループ・アクセス回線を集約拡張または仮想トランクとして以下の図に示されています。
<====Inter-AS MPLS TE Tunnel====>
or
< ===Inter-AS MPLS TE Tunnel===============>
---- ----- ----- ----- -----
| CE |_____Local___| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 |
| | Loop | PE | | RTR | Link | RTR | |PE |
---- ----- ----- ----- -----
+SP1 Customer ASx+ +-----SP2 AS2---+ +-SP1 AS1-------+
Case 2 - the inter-AS MPLS TE tunnel in this case functions as an extended or virtual local access link from SP1's CE on SP2's network to the SP1's ASBR or PE:
ケース2 - SP1のASBRまたはPEへSP2のネットワーク上のSP1のCEから拡張または仮想ローカル・アクセス・リンクこの場合関数で相互AS MPLS TEトンネル：
<==============Inter-AS MPLS TE Tunnel==============>
or
<==============Inter-AS MPLS TE Tunnel========================>
---- ----- ----- ----- -----
| CE |____Local_____| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 |
| | Loop | PE | | RTR | Link | RTR | |PE |
---- ----- ----- ----- -----
+SP1 Customer ASx+ +------SP2 AS2---+ +--SP1 AS1-----+
In Case 2 above, SP2 may elect to establish an aggregating or hierarchical intra-AS MPLS TE tunnel between the transiting P or PE router and SP2's ASBR router just to reduce the number of tunnel states signaled from the SP2 PE to where SP1's CEs are connected.
上記ケース2において、SP2は、単にトンネル状態の数を減らすために凝集又は遷移のP又はPEルータとSP2のASBRルータ間の階層のイントラAS MPLS TEトンネルを確立することを選択することができるSP1のCESが接続されている場所にSP2 PEからシグナリング。
In this scenario as illustrated below, customers require the establishment of MPLS TE tunnel from CE1 to CE2 end-to-end across several SPs' networks.
以下に示すように、このシナリオでは、顧客は、エンドツーエンドのいくつかのSPネットワーク全体CE1からCE2にMPLS TEトンネルの確立を必要とします。
<======================Inter-AS MPLS TE Tunnel==================>
--- ----- ----- ----- ----- ---
|CE1|_____| SP2 |___|ASBR |__Inter-AS__|ASBR |____| SP1 |_____|CE2|
| | | PE | | RTR | Link | RTR | | PE | | |
--- ----- ----- ----- ----- ---
+Cust ASx+ +---SP2 AS-----+ +-------SP1 AS-------+ +Cust ASy+
The diagram below illustrates another example where CE1 and CE2 are customers of SP1 with external BGP (eBGP) peering relationships established across the CE-PE links. An inter-AS MPLS TE tunnel may then be established from CE1 in ASx to CE2, which may belong to the same AS or a different AS than that of CE1 across SP1's network in AS2.
以下の図は、CE1とCE2は、CE-PEリンクを横切って確立された関係をピアリング外部BGP（のeBGP）とSP1の顧客である他の例を示します。インターAS MPLS TEトンネルは、同じASまたはAS2におけるSP1のネットワークを介してCE1よりもAS別に属し得る、CE2にASXにCE1から確立されてもよいです。
<===============Inter-AS MPLS TE Tunnel=====================>
--- ----- ---- ---- ----- ---
|CE1|______| SP1 |_____|SP1 |____|SP1 |____| SP1 |_________|CE2|
| | | PE1 | |P1 | |P2 | | PE2 | | |
--- ----- ---- ---- ----- ---
+-Cust ASx-+ +-------------SP1 AS2----------------+ +-Cust ASy-+
The above example shows that SP1's network has a single AS. Obviously, there may be multiple ASes between CE1 and CE2, as well as in the SP1's network.
上記の例では、SP1のネットワークは、単一のASを持っていることを示しています。明らかに、CE1とCE2の間だけでなく、SP1のネットワーク内に複数のASesがあるかもしれません。
In addition, where both CE1 and CE2 reside in the same AS, they will likely share the same private AS number.
また、CE1とCE2の両方が同じAS内に存在する場合、それらはおそらく数ASプライベート同じを共有します。
However, Scenario III will not scale well if there is a greater number of inter-AS TE MPLS tunnels in some degrees of partial mesh or full mesh. Therefore, it is expected that this scenario will have few deployments, unless some mechanisms such as hierarchical intra-AS TE-LSPs are used to reduce the number of signaling states.
部分メッシュまたはフルメッシュのある程度に相互AS TE MPLSトンネルのより多くが存在する場合は、シナリオIIIはうまくスケーリングしないであろう。したがって、このような階層内AS TE-LSPのようないくつかのメカニズムがシグナリング状態の数を減らすために使用されていない限り、このシナリオでは、いくつかの展開を有するであろうことが予想されます。
The scenarios presented in this section mainly deal with inter-AS resource optimization.
このセクションで提示シナリオは主にAS間のリソースの最適化に対処します。
4.2.1. Scenario IV - TE across multi-AS within a Single SP Administrative Domain
4.2.1. シナリオIV - シングルSP管理ドメイン内のマルチAS間でTE
As mentioned in [TE-APP], SPs have generally admitted that the current MPLS TE mechanism provides a great deal of tactical and strategic value in areas of traffic path optimization [TE-RSVP] and rapid local repair capabilities [TE-FRR] via a set of on-line or off-line constraint-based path computation algorithms.
[TE-APP]で述べたように、SPは、一般的に、現在のMPLS TEメカニズムを介して、トラフィックパスの最適化[TE-RSVP]と迅速なローカルリペア機能[TE-FRR]の分野で戦術的および戦略的価値の多くを提供することを認めていますオンラインまたはオフライン制約ベースの経路計算アルゴリズムのセット。
From a service provider's perspective, another way of stating the objectives of traffic engineering is to utilize available capacity in the network for delivering customer traffic without violating performance targets, and/or to provide better QoS services via an improved network utilization, more likely operating below congestion thresholds.
サービスプロバイダの観点からは、トラフィックエンジニアリングの目的を明記する別の方法は、パフォーマンス目標に違反することなく、顧客のトラフィックを配信するためのネットワークで利用可能な容量を利用するために、および/または、より多くの可能性が高い以下のオペレーティング改良されたネットワークの利用を通じて、より良いQoSサービスを提供することです輻輳しきい値。
It is worth noting that situations where resource provisioning is not an issue (e.g., low density in inter-AS connectivity or ample inter-AS capacity), it may not require more scalable and granular TE facilities beyond BGP routing policies. This is because such policies can be rather simple and because inter-AS resource optimization is not an absolute requirement.
リソースのプロビジョニングが問題（AS間接続や豊富なAS間の容量が、例えば、低密度）でない状況が、それはBGPのルーティングポリシーを超えて、よりスケーラブルかつ粒状TE施設を必要としなくてもよいことは注目に値します。そのような政策は、かなり単純なことができているためとAS間のリソースの最適化が絶対条件ではないためです。
However many SPs, especially those with networks across multiple continents, as well as those with sparsely connected networks, have designed their multi-AS routing policies along or within the continental or sub-continental boundaries where the number of ASes can range from a very few to dozens. Generally, inter-continent or sub-continent capacity is very expensive. Some Service Providers have multiple ASes in the same country and would like to optimize resources over their inter-region links. This would demand a more scalable degree of resource optimization, which warrants the consideration of extending current intra-AS MPLS TE capabilities across inter-AS links.
しかし、多くのSPS、複数大陸ネットワークと特に、ならびにまばらに接続されたネットワークを有するもの、のASの数が非常に少ないの範囲であり得る大陸またはサブ大陸の境界に沿って、または内でのマルチASルーティングポリシーを設計しました数十へ。一般的に、インター大陸または亜大陸の容量は非常に高価です。いくつかのサービスプロバイダは、同じ国で複数のASを持っており、その領域間のリンク上でリソースを最適化したいと思います。これは、AS間リンク間で現在のイントラAS MPLS TEの機能を拡張の検討を保証リソースの最適化、より多くのスケーラブルな程度を要求するだろう。
In addition, one may only realize higher efficiency in conducting traffic optimization and path protection/restoration planning when coordinating all network resources as a whole, rather than partially. For a network which may consist of many ASes, this could be realized via the establishment of inter-AS TE LSPs, as shown in the diagram below:
また、1だけではなく、部分的により、全体としてすべてのネットワークリソースを調整するとき、トラフィックの最適化とパス保護/復旧計画を行う上で高効率を実現することができます。以下の図に示すように、多くのASから構成することができるネットワークの場合、これは、インターAS TE LSPの確立を介して実現することができます。
<===================Inter-AS MPLS Tunnel=============>
-------- -------- --------
| |_______________| |____________| |
| SP1 |_______________| SP1 |____________| SP1 |
| AS1 |_______________| AS2 |____________| AS3 |
| | | | | |
-------- -------- --------
|| ||
|| --------- ||
||___________________| SP1 |________________||
|____________________| AS4 |_________________|
| |
---------
The motivation for inter-AS MPLS TE is even more prominent in a Diffserv-enabled network over which statistical performance targets are to be maintained from any point to any point of the network as illustrated in the diagram below with an inter-AS DS-TE LSP:
インターAS MPLS TEのための動機は、統計的性能目標は、インターAS DS-TEと下図に示すように、ネットワークの任意の点までの任意の点から維持されるべき上のDiffserv対応ネットワークにおいて一層顕著ですLSP：
<===================Inter-AS MPLS DS-TE Tunnel=============>
---- ----- ----- ----- ----- ----
| PE |__| P |___|ASBR |___Inter-AS___|ASBR |___|P |___|PE |
| RTR| | RTR | | RTR | Link | RTR | |RTR | |RTR |
---- ----- ----- ----- ----- ----
+------------SP1 AS1---------+ +------------SP1 AS2------+
For example, the inter-AS MPLS DS-TE LSP shown in the diagram above could be used to transport a set of L2 Pseudo Wires or VoIP traffic with corresponding bandwidth requirement.
例えば、上の図に示すインターAS MPLS DS-TE LSPは、対応する帯域幅要件とL2スードワイヤのセットまたはVoIPトラフィックを転送するために使用することができます。
Furthermore, fast recovery in case of ASBR-ASBR link failure or ASBR node failure is a strong requirement for such services.
さらに、ASBR-ASBRリンク障害やASBRノード障害が発生した場合に高速リカバリは、このようなサービスのための強力な要件です。
Scenario V presents another possible deployment case. SP1 with AS1 wants to link a regional network to its core backbone by building an inter-AS MPLS TE tunnel over one or multiple transit ASes belonging to SP2, SP3, etc., as shown in the following diagram:
シナリオVは、別の可能な展開のケースを提示します。 AS1とSP1は、以下の図に示すように、等SP2、SP3、に属する1つまたは複数のトランジットのAS上インターAS MPLS TEトンネルを構築することにより、そのコアバックボーンに地域ネットワークをリンクすることを望みます。
<===========Inter-AS MPLS TE Tunnel=======>
[ ] [ ] [ ]
[ ---- ---- ] [ ---- ---- ] [ ---- ---- ]
[ |P/PE|__|ASBR|]_Inter-AS_[|ASBR|.|ASBR|]_Inter-AS_[|ASBR| |P/PE|]
[ |RTR | |RTR |] Link [|RTR | |RTR |] Link [|RTR | |RTR |]
[ ---- ---- ] [ ---- ---- ] [ ---- ---- ]
[ ] [ ] [ ]
<================Inter-AS MPLS TE Tunnel=====================>
+SP1 Regional ASx+ +Transit SP2 AS2,etc...SPi ASi+ +------SP1 AS1-+
This scenario can be viewed as a broader case of Scenario I shown in section 4.1.1 where the "VPoP" could be expanded into a regional network of SP1. By the same token, the AS number for SP1's regional network ASx may be the same as or different from AS1.
このシナリオでは、私は「VPOP」はSP1の地域ネットワークに拡張することができるセクション4.1.1に示されているシナリオのより広い場合とみなすことができます。同様に、SP1の地域ネットワークASXのためのAS番号が同じかAS1と異なる場合があります。
The inter-AS MPLS TE LSP in this case may also be used to backup an internal path, as depicted in the diagram below, although this could introduce routing complexities:
以下の図に示されるように、これは、ルーティングの複雑さを導入する可能性があるが、この場合の相互AS MPLS TE LSPはまた、バックアップする内部パスを使用することができます。
<===========Inter-AS MPLS TE Tunnel=======>
+----------------------------SP1 AS1-----------------------------+
[ ]
[ ---- ---- ---- ---- ]
[ |P/PE|__|ASBR|__________Primary Intera-AS________|P | |PE |]
[ |RTR | |RTR | Link |RTR | |RTR |]
[ ---- ---- ---- ---- ]
[ | | ]
[ ---- ---- ]
[ |ASBR| |ASBR| ]
[ |RTR | |RTR | ]
[ ---- ---- ]
^ | | ^
| | | |
| | [ ] | |
| | [ ---- ---- ] | |
| |__ Inter-AS_[|ASBR|..|ASBR|]_Inter-AS_| |
| Link [|RTR | |RTR |] Link |
| [ ---- ---- ] |
| [ ] |
| |
+======Backup Inter-AS MPLS TE Tunnel======+
+Transit SP2 AS2,SP3 AS3,etc....SPi ASi+
This section discusses detailed requirements for inter-AS MPLS TE in two principal areas: 1) requirements for inter-AS MPLS TE in the same SP administrative domain and 2) requirements for inter-AS MPLS TE across different SP administrative domains.
同じSP管理ドメインにおける相互AS MPLS TEのための1）の要件と異なるSPの管理ドメイン間相互AS MPLS TE 2）の要件：このセクションでは、2つの主要分野で相互AS MPLS TEの詳細な要件について説明します。
This section presents detailed requirements for inter-AS MPLS TE within the same SP administrative domain.
このセクションでは、同じSP管理ドメイン内の相互AS MPLS TEのための詳細な要件を提示します。
The inter-AS MPLS TE solution SHOULD be consistent with requirements discussed in [TE-REQ] and the derived solution MUST be such that it will interoperate seamlessly with the current intra-AS MPLS TE mechanism and inherit its capability sets from [TE-RSVP].
インターAS MPLS TE溶液[TE-REQ]で説明した要件に合致すべきであり、誘導された解決策は、現在イントラAS MPLS TE機構とシームレスに相互運用し、[TE-RSVPから能力セットを継承するようなものでなければなりません]。
The proposed solution SHOULD allow the provisioning of a TE LSP at the Head/Tail-end with end-to-end Resource Reservation Protocol (RSVP) signaling (eventually with loose paths) traversing across the interconnected ASBRs, without further provisioning required along the transit path.
提案された解決策は、トランジットに沿って必要さらにプロビジョニングすることなく、エンドツーエンドのリソース予約プロトコル（RSVP）（ルーズパスで最終的に）シグナリング相互接続のASBRを横切って横断有するヘッド/テールエンドにおけるTE LSPのプロビジョニングを可能にするはずです道。
One can conceive that an inter-AS MPLS TE tunnel path signaled across inter-AS links consists of a sequence of ASes, ASBRs, and inter-AS links.
一つは、インターAS MPLS TEトンネルパスがAS間のリンクを介してシグナリングすることを考えることができるのAS、のASBR、及びインターASリンクの配列からなります。
The proposed solution SHOULD provide the ability either to select explicitly or to auto-discover the following elements when signaling the inter-AS TE LSP path:
提案された解決策は、どちらかの機能を提供すべきで明示的に選択するか、または相互AS TE LSPパスを知らせるときに次の要素を自動検出します：
- a set of AS numbers as loose hops and/or - a set of LSRs including ASBRs
- ルーズホップとしてAS番号のセットおよび/または - のASBRなどのLSRの組
It should also specify the above elements in the Explicit Route Object (ERO) and record them in the Record Route Object (RRO) of the Resv message just to keep track of the set of ASes or ASBRs traversed by the inter-AS TE LSP.
また、明示的なルートオブジェクト（ERO）で上記の要素を指定し、ちょうど間-AS TE LSPが通過するのASかのASBRのセットを追跡するためにResvメッセージの録音ルートオブジェクト（RRO）でそれらを記録する必要があります。
In the case of establishing inter-AS TE LSP traversing multiple ASes within the same SP networks, the solution SHOULD also allow the Head-end LSR to explicitly specify the hops across any one of the transiting ASes and the TE tunnel Head-end SHOULD also check the explicit segment to make sure that the constraints are met.
同じSPネットワーク内の複数のASを横断相互AS TE LSPを確立する場合には、溶液は、ヘッドエンドLSRは明示的遷移のASのいずれかを横切ってホップとTEトンネルヘッドエンドを指定することが可能にすべきであるSHOULDも制約が満たされていることを確認するために、明示的なセグメントを確認してください。
In addition, the proposed solution SHOULD provide the ability to specify and signal that certain loose or explicit nodes (e.g., AS numbers, etc.) and resources are to be explicitly excluded in the inter-AS TE LSP path establishment, such as one defined in [EXCLUDE-ROUTE].
加えて、提案された解決策を指定して（例えば、数字等）、そのようなものとして明示的に相互AS TE LSPパスの確立に除外されるとリソース、定義されたその特定の緩みまたは明示的なノードをシグナリングする能力を提供すべきです[EXCLUDE-ROUTE]をインチ
The solution SHOULD allow the set-up of an inter-AS TE LSP that complies with a set of TE constraints defined in [TE-REQ]) and follows an optimal path.
溶液は、で定義されたTE制約のセット[TE-REQ]）に準拠して、最適な経路をたどる間AS TE LSPのセットアップを可能にすべきです。
An optimal path is defined as a path whose end-to-end cost is minimal, based upon either an IGP or a TE metric. Note that in the case of an inter-AS path across several ASes having completely different IGP metric policies, the notion of minimal path might require IGP metric normalization.
最適経路は、そのエンド・ツー・エンドのコストIGPまたはTEメトリックのいずれかに基づいて、最小となる経路として定義されます。完全に異なるIGPメトリックポリシーを有するいくつかののAS間で相互ASパスの場合には、最小限のパスの概念はIGPメトリック正規化を必要とするかもしれないことに注意してください。
The solution SHOULD provide mechanism(s) to compute and establish an optimal end-to-end path for the inter-AS TE LSP and SHOULD also allow for reduced optimality (or sub-optimality) since the path may not remain optimal for the lifetime of the LSP.
パスは、寿命のために最適なままでなくてもよいので、溶液は、インターAS TE LSPのための最適なエンドツーエンドの経路を計算し、確立するための機構（単数または複数）を提供すべきであるとも低減最適（またはサブ最適）を可能にすべきですLSPの。
Setting up multiple inter-AS TE LSPs between a pair of LSRs might be desirable when:
ときのLSRのペアの間に複数の相互AS TE LSPを設定することが望ましいかもしれません。
(1) a single TE LSP satisfying the required set of constraints cannot be found, in which case it may require load sharing;
（1）制約の必要なセットを満たす単一のTE LSPは、ロードシェアリングを必要とする可能性がある場合には、見つけることができません。
(2) multiple TE paths may be required to limit the impact of a network element failure to a portion of the traffic (as an example, two VoIP gateways may load balance the traffic among a set of inter-AS TE LSPs);
（2）複数のTEパスは、（一例として、2つのVoIPゲートウェイは相互AS TE LSPのセットの中のトラフィックの負荷を分散することができる）のトラフィックの一部にネットワーク構成要素の故障の影響を制限するために必要とされ得ます。
(3) path protection (e.g., 1:1 or 1:N) as discussed in [MPLS-Recov].
（3）パスプロテクション（例えば、1：1または1：N）[MPLS-[復旧]で議論するように。
In the examples above, being able to set up diversely routed TE LSPs becomes a requirement for inter-AS TE.
上記の例では、多様にルーティングされたTE LSPを設定することができるということはインターAS TEの要件となります。
The solution SHOULD be able to set up a set of link/SRLG/Node diversely routed inter-AS TE LSPs.
ソリューションは、多様相互AS TE LSPのルーティングリンク/ SRLG /ノードのセットを設定することができるべきです。
Once an inter-AS TE LSP has been established, and should there be any resource or other changes inside anyone of the ASes, the solution MUST be able to re-optimize the LSP accordingly and non-disruptively, either upon expiration of a configurable timer or upon being triggered by a network event or a manual request at the TE tunnel Head-End.
インターAS TE LSPが確立されている、任意のリソースまたはのASのいずれか内の他の変更がなければならないならば、溶液はいずれかの設定タイマの満了時に、相応と無停止LSPを再最適化することができなければなりません又はネットワークイベントまたはTEトンネルヘッドエンドに手動要求によってトリガーされると。
The solution SHOULD provide an option for the Head-End LSRs to control if re-optimizing or not should there exist a more optimal path in one of the ASes.
溶液は、再最適化ならば制御するヘッドエンドのLSRのオプションを提供すべきかどうかのASのいずれかで、より最適な経路が存在しなければなりません。
In the case of an identical set of traversed paths, the solution SHOULD provide an option for the Head-End LSRs to control whether re-optimization will occur because there could exist a more optimal path in one of the transit ASes along the inter-AS TE LSP path.
トラバース経路の同一のセットの場合、溶液は、インターASに沿って通過のASのいずれかで、より最適な経路が存在する可能性があるため、再最適化が発生するかどうかを制御するためにヘッドエンドのLSRのオプションを提供すべきですTE LSPパス。
Furthermore, the solution MUST provide the ability to reject re-optimization at AS boundaries.
さらに、ソリューションは、AS境界で再最適化を拒絶する能力を提供しなければなりません。
There are, in general, two or more inter-AS links between multiple pairs of ASBRs for redundancy. The topological density between ASes in a SP network with multi-ASes is generally much higher. In the event of an inter-AS link failure, rapid local protection SHOULD also be made available and SHOULD interoperate with the current intra-AS MPLS TE fast re-route mechanism from [TE-FRR].
冗長性のためのASBRの複数のペアの間に2つ以上のAS間のリンクは、一般的には、があります。マルチのASとSPネットワーク内のAS間トポロジー密度は、一般的にはるかに高いです。 AS間のリンクに障害が発生した場合に、迅速なローカル保護も利用可能であるべきであり、[TE-FRR]から現在イントラAS MPLS TE高速再ルーティング機構と相互運用すべきです。
The traffic routed onto an inter-AS TE tunnel SHOULD also be fast protected against any node failure where the node could be internal to an AS or at the AS boundary.
インターAS TEトンネルにルーティングされるトラフィックも速いノードがASまたはAS境界の内部とすることができる任意のノード障害に対して保護されるべきです。
The proposed inter-AS MPLS TE solution SHOULD satisfy core requirements documented in [DS-TE].
提案された相互AS MPLS TE溶液[DS-TE]に記載のコア要件を満たさなければなりません。
It is worth pointing out that the compatibility clause in section 4.1 of [DS-TE] SHOULD also be faithfully applied to the solution development.
これは、[DS-TE]のセクション4.1で互換句も忠実にソリューション開発に適用されるべきであることを指摘する価値があります。
The proposed solution(s) MUST have a minimum impact on network scalability from both intra- and inter-AS perspectives.
提案された解決策（複数可）内およびAS間の視点の両方からネットワークスケーラビリティ上の最小の影響がなければなりません。
This requirement applies to all of the following:
この要件は、次のすべてに適用されます。
- IGP (impact in terms of IGP flooding, path computation, etc.) - BGP (impact in terms of additional information carried within BGP, number of routes, flaps, overload events, etc.) - RSVP TE (impact in terms of message rate, number of retained states, etc.)
- （BGP内で実施追加情報、等経路、フラップ、過負荷イベントの数の点で影響）BGP - - IGP（IGPフラッディング、経路計算、等の点で影響）メッセージの点でTE（影響をRSVP率、保持状態の数、など）
It is also conceivable that there would potentially be scalability issues as the number of required inter-AS MPLS TE tunnels increases. In order to reduce the number of tunnel states to be maintained by each transiting PoP, the proposed solution SHOULD allow TE LSP aggregation such that individual tunnels can be carried onto one or more aggregating LSP(s). One such mechanism, for example, is described in [MPLS-LSPHIE].
潜在的に必要な相互AS MPLS TEトンネルの数が増加するにつれてスケーラビリティの問題があるだろうということも考えられます。各遷移のPoPによって維持されるトンネル状態の数を減らすために、提案された解決策は、個々のトンネルがLSP（複数可）を集約一つ以上に実施することができるようにTE LSPの集約を可能にすべきです。そのような機構は、例えば、[MPLS-LSPHIE]に記載されています。
There SHOULD be several possibilities to map particular traffic to a particular destination onto a specific inter-AS TE LSP.
特定のAS間TE LSP上に特定の宛先への特定のトラフィックをマッピングするためのいくつかの可能性があるはずです。
For example, static routing could be used if IP destination addresses are known. Another example is to utilize static routing using recursive BGP route resolution.
IP宛先アドレスが既知である場合、例えば、スタティックルーティングを使用することができます。別の例では、再帰的なBGPルート解像度を使用して静的ルーティングを利用することです。
The proposed solution SHOULD also provide the ability to "announce" the inter-AS MPLS TE tunnels as a link into the IGPs (ISIS or OSPF) with the link's cost associated with it. By doing so, PE routers that do not participate in the inter-AS TE path computation can take into account such links in its IGP-based SPF computation.
提案された解決策はまた、それに関連したリンクのコストとのIGP（ISISまたはOSPF）へのリンクとして相互AS MPLS TEトンネル「を発表」する機能を提供すべきです。そうすることによって、相互AS TEの経路計算に参加しないPEルータはそのIGPベースSPF計算にアカウントようなリンクに取ることができます。
An inter-AS TE Management Information Base (MIB) is required for use with network management protocols by SPs to manage and configure inter-AS traffic engineering tunnels. This new MIB SHOULD extend (and not reinvent) the existing MIBs to accommodate this new functionality.
- 相互AS TE管理情報ベース（MIB）を管理および設定するには、SPのことで、ネットワーク管理プロトコルで使用するために必要とされるAS間トラフィックエンジニアリングトンネル。この新しいMIBは、この新しい機能に対応するために、（改革ではなく）既存のMIBを拡張する必要があります。
An inter-AS TE MIB should have features that include:
相互AS TE MIBには、機能を持っている必要があります。
- The setup of inter-AS TE tunnels with associated constraints (e.g., resources). - The collection of traffic and performance statistics not only at the tunnel head-end, but any other points of the TE tunnel. - The inclusion of both IPv4/v6 + AS# or AS# subobjects in the ERO in the path message, e.g.:
- 関連する制約（例えば、リソース）との相互AS TEトンネルのセットアップ。 - トラフィックの収集とパフォーマンス統計情報だけでなく、トンネルのヘッドエンドではなく、TEトンネルのいずれかの他のポイント。 - 含める両方のIPv4 / v6の+＃ASまたは＃AS例えばパスメッセージにEROでサブオブジェクト.:
EXPLICIT_ROUTE class object: address1 (loose IPv4 Prefix, /AS1) address2 (loose IPv4 Prefix, /AS1) AS2 (AS number) address3 (loose IPv4 prefix, /AS3) address4 (loose IPv4 prefix, /AS3) - destination
EXPLICIT_ROUTEクラスオブジェクト：アドレス1（ルーズIPv4のプレフィックス、/ AS1）アドレス2（ルーズIPv4のプレフィックス、/ AS1）AS2（数AS）アドレス3（ルーズIPv4プレフィクス/ AS3）address4（ルーズIPv4プレフィクス/ AS3） - 宛先
or
または
address1 (loose IPv4 Prefix, /AS1) address2 (loose IPv4 Prefix, /AS1) address3 (loose IPv4 Prefix, /AS2) address4 (loose IPv4 Prefix, /AS2) address5 (loose IPv4 prefix, /AS3) address6 (loose IPv4 prefix, /AS3) - destination
アドレス1（ルーズIPv4のプレフィックス、/ AS1）アドレス2（ルーズIPv4のプレフィックス、/ AS1）アドレス3（ルーズIPv4のプレフィックス/ AS2）address4（ルーズIPv4のプレフィックス/ AS2）address5（ルーズIPv4プレフィクス/ AS3）address6（ルーズIPv4のプレフィックス、/ AS3） - 宛先
- Similarly, the inclusion of the RRO object in the Resv message recording sub-objects such as interface IPv4/v6 address (if not hidden), AS number, a label, a node-id (when required), etc. - Inter-AS specific attributes as discussed in section 5 of this document including, for example, inter-AS MPLS TE tunnel accounting records across each AS segment.
- 同様に、そのようなインターフェイスのIPv4 / v6のアドレスとサブオブジェクトを記録するResvメッセージにRROオブジェクトの包含（隠されていない場合）、等番号、ラベル、ノードID（必要な場合）、AS - インターセグメントとしてそれぞれ横切って、例えば、インターAS MPLS TEトンネルアカウンティングレコードを含む本文書のセクション5で説明したと同様に、特定の属性。
In a MPLS network, an SP wants to detect both control plane and data plane failures. But tools for fault detection over LSPs haven't been widely developed so far. SPs today manually troubleshoot such failures in a hop-by-hop fashion across the data path. If they detect an error on the data plane, they have to check the control plane in order to determine where the faults come from.
MPLSネットワークでは、SPは、制御プレーンとデータプレーンの故障の両方を検出したいです。しかし、LSPを超える障害検出のためのツールが広く、これまでに開発されていません。 SPは今日手動でデータの経路を横切ってホップバイホップ方式でそのような障害のトラブルシューティングを行います。彼らは、データプレーン上でエラーを検出した場合、彼らは障害がどこから来たかを決定するために、制御プレーンを確認する必要があります。
The proposed solution SHOULD be able to interoperate with fault detection mechanisms of intra-AS TE and MAY or MAY NOT require the inter-AS TE tunnel ending addresses to be known or routable across IGP areas (OSPF) or levels (IS-IS) within the transiting ASes with working return paths.
提案された解決策は、イントラAS TEとMAYの故障検出機構と相互運用することができるべきであるか、IGP領域（OSPF）またはレベル（IS-IS）内を横切って既知のまたはルーティング可能する終了アドレス間AS TEトンネルを必要としないかもしれませんワーキングリターンパスで通過するのAS。
For example, [LSPPING] is being considered as a failure detection mechanism over the data plane against the control plane and could be used to troubleshoot intra-AS TE LSPs. Such facilities, if adopted, SHOULD then be extended to inter-AS TE paths.
例えば、[LSPPING]制御プレーンに対するデータプレーン上の障害検出メカニズムとして検討されているイントラAS TE LSPをトラブルシューティングするために使用することができます。そのような施設は、採用した場合、その後、インターAS TEパスに拡張されるべきです。
However, the above example depicts one such mechanism that does require a working return path such that diagnostic test packets can return via an alternate data plane, such as a global IPv4 path in the event that the LSP is broken.
しかしながら、上記の例では、診断テストパケットは、LSPが壊れている場合にグローバルIPv4経路として、代替データプレーンを介して返すことができるように、ワーキングリターンパスを必要とするそのような機構を示します。
[MPLS-TTL] presents how TTL may be processed across hierarchical MPLS networks, and such a facility as this SHOULD also be extended to inter-AS TE links.
[MPLS-TTL] TTL階層MPLSネットワークを介して処理することができる、このような機能はまた、インターAS TEリンクに拡張する方法を提示します。
The solution(s) MUST allow extensions as both inter-AS MPLS TE and current intra-AS MPLS TE specifications evolve.
相互AS MPLS TEと現在のイントラAS MPLS TEの両方の仕様は進化するように、溶液（複数可）の拡張を許容しなければなりません。
The proposed solution(s) SHOULD NOT introduce unnecessary complexity to the current operating network to such a degree that it would affect the stability and diminish the benefits of deploying such a solution over SP networks.
提案された解決策（複数可）は、安定性に影響を与えるし、SPネットワーク上でこのようなソリューションを展開する利点を減少させるだろう程度に、現在のオペレーティング・ネットワークへの不必要な複雑さを導入すべきではありません。
The deployment of inter-AS MPLS TE SHOULD NOT impact existing BGP-based traffic engineering or MPLS TE mechanisms, but allow for a smooth migration or co-existence.
相互AS MPLS TEの展開は、既存のBGPベースのトラフィックエンジニアリングやMPLS TEメカニズムに影響を与えますが、スムーズな移行や共存のために許してはなりません。
The solution SHOULD be evaluated taking into account various performance criteria:
溶液は、アカウントの様々な性能基準を考慮して評価されるべきです：
- Degree of path optimality of the inter-AS TE LSP path - TE LSP setup time - Failure and restoration time - Impact and scalability of the control plane due to added overheads, etc. - Impact and scalability of the data/forwarding plane due to added overheads, etc.
- インターAS TE LSPパスのパスの最適度 - TE LSPセットアップ時間 - 故障と復帰時間 - 衝撃起因追加オーバーヘッド、等への制御プレーンのスケーラビリティ - 衝撃およびデータ/転送プレーンのスケーラビリティによります追加オーバーヘッド、など
5.2. Requirements for Inter-AS MPLS TE across Multiple SP Administrative Domains
5.2. 複数のSP管理ドメイン間のInter-AS MPLS TEのための要件
The requirements for inter-AS MPLS TE across multiple SP admin domains SHOULD include all requirements discussed in section 5.1 above in addition to those that are presented in this section here.
複数のSP管理ドメイン間で相互AS MPLS TEのための要件は、ここでは、このセクションで説明されているものに加えて、上記のセクション5.1で説明したすべての要件を含むべきです。
Please note that the SP with multi-AS networks may choose not to turn on the features discussed in the following two sections when building TE tunnels across ASes in its own domain.
マルチASネットワークとSPは、独自ドメインでのAS間でTEトンネルを構築するときに、次の2つのセクションで説明した機能をオンにしないように選択する場合がありますのでご了承ください。
Since an inter-AS TE LSP may span multiple ASes belonging to different SPs, the solution MIGHT allow hiding the set of hops used by the TE LSP within an AS, as illustrated in the following example:
インターAS TE LSPは、異なるSPに属する複数のASにまたがることがあるため、溶液は、以下の例に示すように、AS内のTE LSPによって使用されるホップのセットを隠蔽できる場合があります。
[ ASBR1-----ASBR2 ]
[ ] [ ]
[ A ] [ B ]
[ AS1 ] [ AS2 ]
[ SP1 ]-----[ SP2 ]
[ ] [ ]
Suppose there is an inter-AS TE LSP from A (within AS1 of SP1) to B (within AS2 of SP2). When computing an inter-AS TE LSP path, the set of hops within AS2 might be hidden to AS1. In this case, the solution will allow A to learn that the more optimal TE LSP path to B (that complies with the set of constraints) traverses ASBR2, without a detailed knowledge of the lists of hops used within AS2.
A（SP1のAS1内）から相互AS TE LSPは（SP2のAS2内）Bに存在すると仮定する。インターAS TE LSPの経路を計算するとき、AS2内のホップのセットは、AS1に隠されるかもしれません。この場合、溶液は、AがBに対してより最適なTE LSPパス（つまり、制約の組に準拠）AS2内で使用されるホップのリストの詳細な知識がなくても、ASBR2を横断することを学ぶことを可能にします。
Optionally, the TE LSP path cost within AS2 could be provided to A via, for example, PCC-PCE communication, such that A (PCC) could use this information to compute an optimal path, even if the computed path is not provided by AS2. (See [PCE-COM] for PCC-PCE communication and [PCE] for a description of the PCE-based path computation architecture.)
必要に応じて、AS2内のTE LSPパスコストは、A（PCC）が計算された経路は、AS2によって提供されていない場合でも、最適な経路を計算するためにこの情報を使用することができるよう介して、例えば、PCC-PCE通信に提供することができます。 （PCEベースの経路計算アーキテクチャの説明については、PCC-PCE通信および[PCE]は[PCE-COM]を参照）。
In addition, the management requirements discussed in section 5.1.10 above, when used across different SP admin domains, SHOULD include similar confidentiality requirements discussed here in terms of "hiding" intermediate hops or interface address and/or labels in the transiting or peering SPs.
加えて、上記のセクション5.1.10で説明した管理要件は、異なるSPの管理ドメイン間で使用される場合、遷移中間ホップまたはインターフェイスアドレス及び/又はラベルを「隠蔽」またはピアリングのSPの点でここで議論同様の機密要件を含むべきです。
In some cases, policy control might be necessary at the AS boundaries, namely ingress policy controls enabling SPs to enforce the inter-AS policies per interconnect agreements or to modify some requested parameters conveyed by incoming inter-AS MPLS TE signaling requests.
いくつかのケースでは、ポリシー制御は、相互接続契約当りAS間のポリシーを適用するか、着信インターAS MPLS TEシグナリング要求によって搬送されるいくつかの要求されたパラメータを変更するためのSPを可能AS境界、すなわち入力ポリシー制御に必要かもしれません。
It is worth noting that such a policy control mechanism may also be used between ASes within a SP.
そのようなポリシー制御機構はまた、SP内のASとの間で使用されてもよいことは注目に値します。
This section discusses only the elements that may be used to form a set of ingress control policies, but exactly how SPs establish bilateral or multilateral agreements upon which the control policies can be built is beyond the scope of this document.
このセクションでは、入力制御ポリシーのセットを形成するために使用することができる唯一の要素を説明したが、SPは制御ポリシーを構築することができ、その上に二国間または多国間協定を確立し、正確にどのようにこの文書の範囲外です。
The following provides a set of TE-LSP parameters in the inter-AS TE Requests (RSVP Path Message) that could be enforced at the AS boundaries:
以下は、AS境界で実施することができインターAS TE要求（RSVP PATHメッセージ）でのTE-LSPパラメータのセットを提供します。
- RSVP-TE session attributes: affinities and preemption priorities - Per AS or SP bandwidth admission control to ensure that RSVP-TE messages do not request for bandwidth resources over their allocation - Request origins which can be represented by Head-End tunnel ending IP address, originating AS#, neighbor AS#, neighbor ASBR interface IP address, etc. - DS-TE TE-Class <Class-Type, Preemption> - FRR attribute: local protection desired bit, node protection desired bit, and bandwidth protection desired bit carried in the - SESSION ATTRIBUTE or the FAST-REROUTE objects in the RSVP Path message as defined in [TE-FRR] - Optimization allowed or not allowed
- RSVP-TEセッション属性：親和性およびプリエンプションの優先順位 - ASまたはSP帯域アドミッション制御PERが彼らの割り当てを介して帯域幅リソースを要求しないRSVP-TEメッセージを確実にするために - IPアドレスを終了するヘッドエンドトンネルで表すことができる起源をリクエストDS-TE TE-クラス<クラス型、プリエンプション> - - ＃、＃、隣接ASBRインターフェースIPアドレス等AS隣人AS、発信FRR属性：ローカル保護所望のビット、ノード保護の所望のビット、および帯域幅保護を所望のビット[TE-FRR]で定義されるようにセッション属性またはFAST-REROUTEは、RSVP Pathメッセージ内のオブジェクト - - 最適化の許可または許可しないで運ば
In some cases, a TE policy server could also be used for the enforcement of inter-AS TE policies. Implementations SHOULD allow the use of a policy enforcement server. This requirement could allow SPs to make the inter-AS TE policies scale better.
いくつかのケースでは、TEポリシーサーバは、相互AS TEポリシーの施行のために使用することができます。実装は、ポリシーの適用サーバーの使用を許可する必要があります。この要件は、SPは相互AS TE政策がより良いスケールにする可能性があります。
The signaling of a non-policy-compliant request SHOULD trigger the generation of a RSVP Path Error message by the policy enforcing node towards the Head-end LSR, indicating the cause. The Head-end LSR SHOULD take appropriate actions, such as re-route, upon receipt of such a message.
非ポリシー準拠要求のシグナリングは、原因を示す、ヘッドエンドLSRに向かってノードを強制ポリシーによってRSVPパスエラーメッセージの生成をトリガします。ヘッドエンドLSRは、そのようなメッセージを受信すると、このような再経路などの適切なアクションを取るべきです。
In some situations, SPs may need to rewrite some attributes of the incoming inter-AS TE signaling requests due to a lack of resources for a particular TE-Class, non-compliant preemption, or mutual agreements. The following provides a non-exhaustive list of the parameters that can potentially be rewritten at the AS boundaries:
いくつかの状況では、SPが原因特定のTE-クラス、非準拠プリエンプション、または相互の合意のための資源の不足に入ってくる間-AS TEのシグナリング要求のいくつかの属性を書き換える必要があるかもしれません。以下は、潜在的にAS境界で書き換え可能なパラメータの非網羅的なリストを提供します。
- RSVP-TE session attributes: affinities and preemption priorities - DS-TE TE-Class <Class-Type, Preemption> - ERO expansion requests
- RSVP-TEセッション属性：親和性およびプリエンプションの優先順位 - DS-TE TE-クラス<クラス型、プリエンプション> - ERO拡張要求
Similarly, the rewriting node SHOULD generate a RSVP Path Error Message towards the Head-end LSR indicating the cause in terms of types of changes made so as to maintain the end-to-end integrity of the inter-AS TE LSP.
同様に、書き換えノードは、インターAS TE LSPのエンドツーエンドの完全性を維持するように行われた変更の種類の点で原因を示すヘッドエンドLSRに向かってRSVPパスエラーメッセージを生成する必要があります。
The proposed solution SHOULD also provide a set of policing mechanisms which could be configured on the inter-AS links to ensure that traffic routed through the tunnel does not exceed the bandwidth negotiated during LSP signaling.
提案された解決策は、トンネルを介してルーティングされるトラフィックは、LSPシグナリング中にネゴシエート帯域幅を超えないことを保証するために、AS間のリンクで構成することができるポリシング機構のセットを提供しなければなりません。
For example, an ingress policer could be configured to enforce the traffic contract on the mutually agreed resource requirements of the established inter-AS TE LSP (i.e., RSVP bandwidth) on the interface to which the inter-AS link is connected.
例えば、入力ポリサーは、AS間のリンクが接続されたインターフェイス上で確立された相互AS TE LSP（すなわち、RSVP帯域幅）の相互に合意したリソース要件にトラフィック契約を強制するように構成することができます。
The proposed solution(s) MUST address security issues across multiple SP administrative domains. Although inter-AS MPLS TE is not expected to add specific security extensions beyond those of current intra-AS TE, greater considerations MUST be given in terms of how to establish a trusted model across AS boundaries. SPs SHOULD have a means to authenticate (such as using RSVP INTEGRITY Object), to allow, and to possibly deny inter-AS signaling requests. Also, SPs SHOULD be protected from DoS attacks.
提案された解決策（複数可）は、複数のSP管理ドメイン間でのセキュリティ問題に対処しなければなりません。相互AS MPLS TEは、現在のイントラAS TEのそれを超えて、特定のセキュリティ拡張機能を追加することが予想されていないが、より大きな配慮を境界として全体で信頼されたモデルを確立する方法の観点から与えられなければなりません。 SPは、（例えばRSVPのINTEGRITYオブジェクトを使用するなど）を認証するための手段を有するべきで可能にするために、そして恐らくはインターASシグナリング要求を拒否します。また、SPはDoS攻撃から保護されなければなりません。
We would like to thank Yuichi Ikejiri, David Allan, Kurt Erik Lindqvist, Dave McDysan, Christian Jacquenet, Kireeti Kompella, Ed Kern, Jim Boyle, Thomas Nadeau, Yakov Rekhter, and Bert Wijnen for their suggestions and helpful comments during the discussions of this document.
私たちは、この議論の中に彼らの提案や有益なコメントのため雄一池尻、デビッド・アラン、クルト・エリックLindqvist、デイブMcDysan、クリスチャンJacquenet、Kireeti Kompella、エド・カーン、ジム・ボイル、トーマスナドー、ヤコフ・レックター、およびバートWijnenに感謝したいと思います資料。
[TE-REQ] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[TE-REQ] Awduche、D.、マルコム、J.、Agogbua、J.、オデル、M.、およびJ.マクマナス、 "トラフィックエンジニアリングオーバーMPLSのための要件"、RFC 2702、1999年9月。
[TE-RSVP] 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.
[TE-RSVP] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：ExtensionsがLSPトンネルのためのRSVPする"、RFC 3209 、2001年12月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS-ARCH]ローゼン、E.、Viswanathanの、A.、およびR. Callon、RFC 3031、2001年1月 "マルチプロトコルラベルスイッチングアーキテクチャ"。
[BGP-MPLSVPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP VPNs", Work in Progress, October 2004.
[BGP-MPLSVPN]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP VPN" を、進歩、2004年10月に作業。
[DIFF_ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[DIFF_ARCH]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[DIFF_AF] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
【DIFF_AF] Heinanen、J.、ベーカー、F.、ワイス、W.、及びJ. Wroclawski、 "保証転送PHBグループ"、RFC 2597、1999年6月。
[DIFF_EF] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
【DIFF_EF】デイビー、B.、Charny、A.、ベネット、JC、ベンソン、K.、ルBoudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、およびD. Stiliadis、「アン緊急転送PHB（ホップ単位動作）」、RFC 3246、2002年3月。
[MPLS-Diff] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[MPLS-差分]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング差別化サービスの（MPLS）サポート」、RFC 3270、2002年5月。
[TE-OVW] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.
[TE-OVW] Awduche、D.、チウ、A.、Elwalid、A.、Widjaja、I.、およびX.シャオ、 "インターネットトラフィックエンジニアリングの概要と原則"、RFC 3272は、2002年5月。
[PSTE] Li, T. and Y. Rekhter, "A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC 2430, October 1998.
[PSTE]李、T.とY. Rekhter、 "差別化サービスおよびトラフィックエンジニアリングのためのプロバイダのアーキテクチャ（ペースト）"、RFC 2430、1998年10月。
[TE-APP] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., Christian, B., and W. Lai, "Applicability Statement for Traffic Engineering with MPLS", RFC 3346, August 2002.
[TE-APP]ボイル、J.、ギル、V.、阪南、A.、クーパー、D.、Awduche、D.、クリスチャン、B.、およびW.ライ、 "MPLSとトラフィックエンジニアリングのための適用性に関する声明"、 RFC 3346、2002年8月。
[GMPLS-ROUT] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[GMPLS-ROUT]バーガー、L.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）拡張機能"、RFC 3473、2003年1月。
[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[BGP] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[LSPPING] Kompella, K. and G. Swallow, "Detecting MPLS Data Plane Failures", Work in Progress, May 2005.
[LSPPING] Kompella、K.とG.ツバメ、 "検出MPLSデータプレーン障害"、進歩、2005年5月での作業。
[MPLS-TTL] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[MPLS-TTL] Agarwalさん、P.とB. Akyol、 "（TTL）の生存時間（MPLS）ネットワークのマルチプロトコルラベルスイッチングの処理"、RFC 3443、2003年1月。
[DS-TE] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[DS-TE]ルFaucheur、F.およびW.ライ、 "差別化サービスを意識したMPLSトラフィックエンジニアリングのサポートのための要件"、RFC 3564、2003年7月。
[TE-FRR] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[TE-FRR]パン、P.、ツバメ、G.とA.アトラス、RFC 4090、2005年5月 "高速リルート機能拡張LSPトンネルの-TEをRSVPに"。
[MPLS-LSPHIE] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, September 2005.
[MPLS-LSPHIE] Kompella、K.とY. Rekhterは、RFC 4206、2005年9月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[MPLS-Recov] Sharma, V. and F. Hellstrand, "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.
[MPLS-[復旧]シャルマ、V.とF. Hellstrand、RFC 3469、2003年2月の "回復をベースマルチプロトコルラベルスイッチング（MPLS）のためのフレームワーク"。
[EXCLUDE-ROUTE] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to RSVP-TE", Work in Progress, August 2005.
。[EXCLUDE-ROUTE]リー、CY、ファレル、A.、およびS.デCnodderは、 "ルートの除外 - 拡張を-TE RSVPに"、進歩、2005年8月の作業を。
[PCE] Farrel, A., Vasseur, J.-P., and J. Ash, "Path Computation Element (PCE) Architecture", Work in Progress, September 2005.
[PCE]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（PCE）アーキテクチャ"、進歩、2005年9月での作業。
[PCE-COM] Vasseur, J.-P., et al., "Path Computation Element (PCE) communication Protocol (PCEP) - Version 1", Work in Progress, September 2005.
[PCE-COM] Vasseur、J.-P.ら、 "パス計算要素（PCE）通信プロトコル（PCEP） - バージョン1"、進歩、2005年9月ワーク。
Appendix A. Brief Description of BGP-based Inter-AS Traffic Engineering
BGPベースのInter-ASトラフィックエンジニアリングの付録A.簡単な説明
In today's Service Provider (SP) network, BGP is deployed to meet two different sets of requirements:
今日のサービスプロバイダ（SP）ネットワークでは、BGPは、要件の異なる2組を満たすように展開されています。
- Establishing a scalable exterior routing plane separate from the data forwarding plane within SP's administrative domain - Exchanging network reachability information with different BGP autonomous systems (ASes) that could belong to a different SP or simply, a different AS within a SP network
- スケーラブルな外部ルーティング・プレーンを確立するSPの管理ドメイン内のデータ転送プレーンから分離 - 単に異なるSPに属するか、可能性が異なるBGP自律システム（のAS）とのネットワーク到達可能性情報を交換し、別のSPネットワーク内のAS
Over connections across the AS boundaries, traffic engineering may also be accomplished via a set of BGP capabilities by appropriately enforcing BGP-based inter-AS routing policies. The current BGP-based inter-AS traffic engineering practices may be summarized as follows:
ASの境界を越えて接続を介して、トラフィックエンジニアリングはまた、適切にBGPベースのAS間ルーティングポリシーを適用することにより、BGP機能のセットを介して達成することができます。次のように現在のBGPベースの相互ASトラフィックエンジニアリングの実践を要約することができます。
- "Closest exit" routing where egress traffic from one SP to another follows the path defined by the lowest IGP or intra-AS MPLS TE tunnel metrics of the BGP next-HOP of exterior routes learned from other ASes over the inter-AS links - "BGP path attribute"-based routing selection mechanism where the egress traffic path is determined by interconnect (peering or transit) policies based upon one or a combination of BGP path attributes, like AS_PATH, MULTI_EXIT_DISC (MED), and Local_Pref.
- - 1つのSPから別の出力トラフィックは、経路が最も低いIGPによって定義された又は外部経路のBGPネクストホップのイントラAS MPLS TEトンネルメトリックはAS間リンクを介して他のASから学習以下「最も近い出口」ルーティング「BGPパス属性は、」（ピアリングまたはトランジット）出力トラフィック経路は、相互接続することによって決定された経路選択メカニズムをベース1つに基づいてポリシーまたはBGPパスの組み合わせはAS_PATH、MULTI_EXIT_DISC（MED）、およびLocal_Prefのように、属性。
SPs have often faced a number of nondeterministic factors in the practices of inter-AS traffic engineering employing the methods mentioned above:
SPは、多くの場合、相互AS上記の方法を採用したトラフィックエンジニアリングの実践に非決定的な要因の数に直面しています：
- Sub-optimum traffic distribution across inter-AS links - Nondeterministic traffic condition changes due to uncoordinated IGP routing policies or topology changes within other AS and uncoordinated BGP routing policy changes (MED or as-prepend, etc.)
非協調IGPルーティングポリシーまたは他のASとまとまりのないBGPルーティングポリシーの変更（MEDまたはAS-プリペンドなど）内のトポロジ変化に非決定的な交通状況の変化 - - AS間リンク間準最適トラフィック分布
In addition, to achieve some degrees of granularity, SPs may choose to enforce BGP inter-AS policies. These policies are specific to one inter-AS link or to a set of inter-AS links for ingress traffic. By tagging certain sets of routes with a specific attribute when announcing to another AS, the ingress traffic is destined to certain PoPs or to regions within SP's network from another AS. Of course, this operates on the assumption that the other AS permits automated egress policy by matching the predefined attribute from incoming routes.
また、粒度のいくつかの程度を達成するために、SPはBGP AS間のポリシーを適用することもできます。これらのポリシーは、1 AS間リンクまたは入力トラフィックのためのAS間リンクのセットに固有のものです。別のASに発表し、特定の属性を持つルートの特定のセットをタグ付けすることによって、入力トラフィックは、他のASからSPのネットワーク内の特定のPoPや地域に運命づけられています。もちろん、これは許す限り他の受信ルートから事前に定義された属性を照合することによって出力ポリシーを自動化することを前提に動作します。
Editors' Addresses
エディタのアドレス
Raymond Zhang Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025 USA
レイモンド・チャンインフォネット・サービス株式会社2160 E.グランドアベニューエル・セグンド、CA 90025 USA
EMail: raymond_zhang@infonet.com
メールアドレス：raymond_zhang@infonet.com
J.-P. Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
J.-P. Vasseurシスコシステムズ社300ビーバーブルック・ロードボックスボロー、MA 01719 USA
EMail: jpv@cisco.com
メールアドレス：jpv@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。