[要約] RFC 4216は、異なる自治システム間でのトラフィックエンジニアリングの要件を定義しています。その目的は、MPLSネットワークにおける効率的なトラフィック制御と最適な経路選択を実現することです。
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
MPLS自動間システム（AS）トラフィックエンジニアリング（TE）要件
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).
Copyright（c）The Internet Society（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.
このドキュメントでは、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]に記載されているように、ネットワークトラフィックエンジニアリングの最も重要な目的のいくつかを達成するために、サービスプロバイダー（SPS）によって展開される場合があります。これらの目的は次のように要約されています。
- 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の管理ドメイン内またはそれ以外の境界として同じ目的セットを達成するために使用される可能性のある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.
ドキュメントには、トラフィック間機関間メカニズムが必要になる可能性のあるアプリケーションシナリオのセットも表示されます。このメカニズムは、このドキュメントに示されている要件に基づいて実装できます。
These application scenarios will also facilitate discussions for a detailed requirements list for this inter-AS Traffic Engineering mechanism.
これらのアプリケーションシナリオは、このトラフィック間エンジニアリングメカニズムの詳細な要件リストの議論も促進します。
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内で使用するため）;およびBorder Gateway Protocol（BGP）属性ベース（付録Aで説明されているように、ASES全体で使用）。ただし、このドキュメントでは、MPLSベースの細かいアプローチの要件について、Inter-As As TEに対処しています。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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
Kenji Kumaki Kddi Corporation Garden Air Tower Iidabashi、Chiyoda-Ku、Tokyo 102-8460、日本メール：ke-kumaki@kddi.com
Paul Mabey Qwest Communications 950 17th Street, Denver, CO 80202, USA EMail: pmabey@qwest.com
Paul Mabey Qwest Communications 950 17th Street、Denver、Co 80202、USAメール：pmabey@qwest.com
Nadim Constantine Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025. USA EMail: nadim_constantine@infonet.com
Nadim Constantine Infonet Services Corporation 2160 E. Grand Ave. El Segundo、CA90025。米国メール：nadim_constantine@infonet.com
Pierre Merckx EQUANT 1041 route des Dolines - BP 347 06906 SOPHIA ANTIPOLIS Cedex, FRANCE EMail: pierre.merckx@equant.com
Pierre Merckx Equant 1041 Route Des Dolines -BP 347 06906 Sophia Antipolis Cedex、フランスメール：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 Canada 181 Bay Street、Suite 350 Toronto、Ontario、Canada、M5J 2T3メール：ting_wo.chung@bell.ca
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex, France EMail: jeanlouis.leroux@francetelecom.com
Jean-Louis Le Roux France Telecom 2、Avenue Pierre-Marzin 22307 Lannion Cedex、France Email：jeanlouis.leroux@francetelecom.com
Yonghwan Kim SBC Laboratories, Inc. 4698 Willow Road Pleasanton, CA 94588, USA EMail: Yonghwan_Kim@labs.sbc.com
Yonghwan Kim SBC Laboratories、Inc。4698 Willow Road Pleasanton、CA 94588、USAメール：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管理ドメイン：1つまたは複数のASEで構成されるネットワークまたはネットワークを介した単一のSP管理。
IP-only networks: SP's network where IP routing protocols such as IGP/BGP are activated.
IPのみのネットワーク：IGP/BGPなどのIPルーティングプロトコルがアクティブになっているSPのネットワーク。
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スイッチング機能とシグナリングコントロール（[MPLS-ARCH]で説明されているものなど）がIPルーティングプロトコルに加えてアクティブ化されるSPのネットワーク。
Intra-AS TE: A generic definition for traffic engineering mechanisms operating over IP-only and/or IP/MPLS network within an AS.
Intra-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.
Inter-as te：1つまたは複数のASEでIPのみおよび/またはIP/MPLSネットワークを介して動作するトラフィックエンジニアリングメカニズムの一般的な定義。このドキュメントはIP/MPLSネットワークのみに対応しているため、このドキュメントのAS Inter-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.
Intra-AS MPLS TE：TEラベルがスイッチされたパス（LSP）、ヘッドエンドラベルスイッチングルーター（LSR）、およびテールエンドLSRがトラフィックエンジニアリングの目的と同じで存在する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.
MPLS Inter-AS MPLS：TE LSP、ヘッドエンドLSR、およびテールエンドLSRがヘッドエンドLSRおよびテールエンドLSRの両方と同じまたは両方と同じまたは両方の範囲内に存在しないMPLSトラフィックエンジニアリングメカニズムしかし、TE LSPの通過経路は、異なるASEを越えている場合があります。
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.
ASBRS：ASESを相互接続する1つ以上のリンクを介して、別のまたは同じサービスプロバイダーのように別のものに接続するために使用される自律システムの境界ルーター。
Inter-AS TE Path: A TE path traversing multiple ASes and ASBRs, e.g., AS1-ASBR1-inter-AS link(s)-ASBR2-AS2... ASBRn-ASn.
パス間：複数のASESとASBRを通過するTEパス、たとえば、AS1-ASBR1-inter-as link（s）-Asbr2-as2 ... asbrn-asn。
Inter-AS TE Segment: A portion of the Inter-AS TE path.
セグメント間：TE間のパスの一部。
Inter-AS DS-TE: Diffserv-aware Inter-AS TE.
ds-teである：diffserv-aware inter-as te。
CE: Customer Edge Equipment
CE：顧客エッジ機器
PE: Provider Edge Equipment that has direct connections to CEs.
PE：CESに直接接続するプロバイダーエッジ機器。
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の用語は、その定義において一般的なものであることに注意してください。特に、そのような頭字語が使用される場合はいつでも、[BGP-Mplsvpn]などのIETFドキュメントに記載されているVRF環境でCEが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で述べたように、一部のSPSには、境界として[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）帯域幅間保証。2）リソースの最適化と3）ASES間の高速回復、つまり、AS Inter-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_arch]、[diff_af]、および[diff_ef]または[mpls-diff]で説明されている一連のメカニズムを定義しています。これらのメカニズムは、diffservドメインの端で有効にして、QoSポリシー（またはQoSポリシーのセット）の施行に貢献できます。変動、損失率など
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.
多くのSPSは、ネットワーク全体にわたって、または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.
この要件の典型的な例の1つは、diffserv対応ネットワークでEF（迅速な転送[diff_ef]）クラスに分類されたVoIPトラフィックのエンドツーエンドパスで帯域幅保証を提供することです。EFパスが複数のASEで拡張されると、帯域幅間保証が必要です。
Another case for inter-AS bandwidth guarantee is the requirement for guaranteeing a certain amount of transit bandwidth across one or multiple ASes.
帯域幅間保証のもう1つのケースは、1つまたは複数のASEにわたって一定量の輸送帯域幅を保証するための要件です。
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]がASE間のルーティング情報を交換するために展開されます。BGPのAS Inter-AS機能は、AS境界全体のトラフィックエンジニアリングの目的で採用される場合があります。付録Aでは、現在のBGPベースのトラフィックエンジニアリングプラクティスの簡単な説明を提供します。
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.
SPSは、主にベストエフォートの環境でリンク間としてのこのBGPベースのトラフィックエンジニアリング施設の粗いセットで生き残ることができました。確かに、多くの場合、SPのネットワーク内およびASリンク間での十分な帯域幅が、より精巧なインタータイポリシーの必要性を減らします。
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.
ただし、SPネットワークが複数のASESに展開される場合（たとえば、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.
別の例は、異なるSP管理ドメイン間でリンクを確立する場合です。協調していないルーティングやネットワークの変更、および最適下の交通条件などの非決定論的要因は、現在のトラフィックエンジニアリングメカニズムがおそらく十分に縮小しない複雑な交通工学ポリシーにつながる可能性があります。
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間の施設は、より詳細なトラフィックエンジニアリングメカニズムによって補完する必要があります。
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内で達成されたように、パケットの損失やサービスの可用性など、同じレベルのパフォーマンス目標を維持するためにSPSを必要とすることがよくあります。結果として、Link/SRLG/ノードの障害に対する安定した方法での高速収束が強力な要件になります。これは、特にASBRSまたは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ベースのトラフィックエンジニアリング機能に加えて、リソースの最適化、帯域幅保証、高速回復が必要なリンク間でBGPベースのトラフィックエンジニアリング機能を展開する必要があります。。
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.
これは、[PSTE]で説明されているDiffserv対応のマルチクラス環境で特に重要です。ここでは、統計的なパフォーマンスターゲットを、異なるASEを横切るパス全体で一貫して維持する必要があります。
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 Inter-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ネットワークの要件と同様の要件に十分な関心がないため、IPのみのネットワーク上のトラフィック間エンジニアリングは将来の検討のためのものです。より具体的には、このドキュメントは、パケットベースのIP/MPLSネットワークの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.
次のセクションでは、現在のMPLS TEメカニズムで要件に対処できないIP/MPLSネットワークに関するいくつかのアプリケーションシナリオを示し、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.
次の議論では明示的には明示的ではありませんが、安定した方法で複数のASEを横断するトラフィックパスの迅速な回復は、ここに示されているすべてのアプリケーションシナリオの境界としてのリンク/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のPOPSの共同配置集約ルーターにより、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のネットワークの変化に対する透明度をある程度達成するために、AS1とSP1のSP1またはPEルーターの間にMPLS間の1つ以上のAS間のTE LSPを構築できます。以下の図に示されているように、SP2のPOPSで共同開催されたPEルーター：
<===========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パスを維持する必要がある状況では、両方のSPSのネットワークが、互換性のあるパフォーマンス目標を持つトラフィッククラスのセットをサポートするために、各ホップで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-Awareネットワークではない場合、シナリオは帯域幅の保証を提供するために適用されます。
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は同様に、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ルーティングプレーンをホストする可能性が低く、SP1のASのASまたは一部を維持する可能性が高いことに言及する価値があります。この場合、そのようなトンネルはいくつかのASEを越える可能性がありますが、上記の図に示すように、TEトンネルのヘッドエンドおよびテールエンドのLSRは数と同じである可能性があります。
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は、顧客VPNサイトをSP2のPEルーターに集約することも選択できます。これにより、SP2のMPLSネットワークを介してSP2 POP（SP1とWhich）の間のSP2のMPLSネットワークを介して構築および信号を送信できます。顧客CESが直接接続されます）とSP1のネットワーク内のSP1のASBRまたはPEルーター。これにより、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 Inter-AS MPLS TEトンネルは、SP1の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-この場合のMPLS TEトンネルは、SP2のネットワーク上のSP1のCEからSP1のASBRまたはPEへの拡張または仮想ローカルアクセスリンクとして機能します。
<==============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.
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.
以下に示すように、このシナリオでは、顧客は、いくつかのSPSネットワークにわたって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の顧客である別の例を示しています。ASXのCE1からASXのCE1からCE2に確立される場合があります。CE2は、AS2のSP1ネットワーク全体の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のネットワークには複数のASEがある場合があります。
In addition, where both CE1 and CE2 reside in the same AS, they will likely share the same private AS number.
さらに、CE1とCE2の両方が同じである場合、それらはおそらく数字と同じプライベートを共有します。
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.
ただし、シナリオIIIは、部分的なメッシュまたはフルメッシュのある程度でTEMPLSトンネル間でより多くの数のTEMPLSトンネルがある場合、十分にスケーリングしません。したがって、TE-LSPのように階層的なメカニズムを使用してシグナル伝達状態の数を減らすために使用されない限り、このシナリオには展開がほとんどないことが予想されます。
The scenarios presented in this section mainly deal with inter-AS resource optimization.
このセクションで提示されているシナリオは、主にリソース間最適化を扱っています。
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]で述べたように、SPSは一般に、現在の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.
リソースのプロビジョニングが問題ではない状況（たとえば、接続性または豊富な容量としての十分な密度）が、BGPルーティングポリシーを超えてよりスケーラブルで粒状のTE施設を必要としない場合があることに注意してください。これは、そのようなポリシーがかなり単純であり、リソース間最適化が絶対的な要件ではないためです。
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、特に複数の大陸にあるネットワークを持つSPS、およびまばらに接続されたネットワークを持つ人は、ASの数が非常に少ない大陸または大陸境界に沿って、または大陸亜大陸境界内に沿って、または大陸亜大陸境界内で多数のルーティングポリシーを設計しています。何十も。一般的に、大陸間または大陸亜大陸能力は非常に高価です。一部のサービスプロバイダーは、同じ国に複数のASEを持っているため、地域間リンクでリソースを最適化したいと考えています。これにより、よりスケーラブルな程度のリソース最適化が必要になります。これにより、リンク間での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:
さらに、すべてのネットワークリソースを部分的にではなく調整する場合、トラフィックの最適化とパス保護/修復計画の実施における効率が高いことを認識することができます。多くのASESで構成される可能性のあるネットワークの場合、これは、以下の図に示すように、inter-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:
MPLS Inter-ASの動機は、以下の図に示すように、統計パフォーマンスターゲットをネットワークの任意のポイントに維持する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つまたは複数のトランジットASESの上にMPLS間トンネル間トンネルを構築することにより、地域ネットワークをコアバックボーンにリンクしたいと考えています。
<===========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:
この場合、MPLS間の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.
このセクションでは、2つの主要な領域におけるMPLS間の詳細な要件について説明します。1）同じSP管理ドメインでのMPLS間のMPLSの要件、2）異なるSP管理ドメインにわたるMPLS Inter-AS MPLS TEの要件について説明します。
This section presents detailed requirements for inter-AS MPLS TE within the same SP administrative domain.
このセクションでは、同じSP管理ドメイン内のMPLS間の詳細な要件を示します。
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-REQ]で説明されている要件と一致する必要があり、導出されたソリューションは、現在の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 Inter-ASリンクを越えてシグナル伝達されたMPLS TE TEトンネルパスは、ASE、ASBRS、および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:
提案されたソリューションは、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）の上記の要素を指定し、resvメッセージのレコードルートオブジェクト（rro）に記録して、asesまたはasbrsのセットをte lspとして追跡するだけです。
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ネットワーク内で複数のASEを横断するためのLSPを確立する場合、ソリューションにより、ヘッドエンドLSRが通過ASESのいずれかにわたってホップを明示的に指定できるようにする必要があります。明示的なセグメントをチェックして、制約が満たされていることを確認してください。
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].
さらに、提案されたソリューションは、特定のゆるいノードまたは明示的なノード（数字など）およびリソースが、定義されたものなど、TELSPパス確立として明示的に除外されることを指定および信号する機能を提供する必要があります。[除外]で。
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-req]で定義された一連のTE制約に準拠し、最適なパスに従う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メトリックポリシーを持ついくつかのASEを横切る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.
ソリューションは、TELSPとしての間隔として最適なエンドツーエンドパスを計算して確立するメカニズムを提供する必要があります。また、パスが寿命に合わせて最適ではない可能性があるため、最適性（またはサブ最適性）を減らすこともできます。LSPの。
Setting up multiple inter-AS TE LSPs between a pair of LSRs might be desirable when:
LSRのペア間で複数の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ゲートウェイは、TELSPのセット間のトラフィックのバランスを負担する場合があります）。
(3) path protection (e.g., 1:1 or 1:N) as discussed in [MPLS-Recov].
(3) [MPLS-Recov]で説明されているように、パス保護（例：1：1または1：n）。
In the examples above, being able to set up diversely routed TE LSPs becomes a requirement for inter-AS TE.
上記の例では、多様にルーティングされたTELSPをセットアップできることは、TEとの間の要件になります。
The solution SHOULD be able to set up a set of link/SRLG/Node diversely routed inter-AS TE LSPs.
このソリューションは、lspsとspideで多様にルーティングされたリンク/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.
TE LSPとしての間に確立された後、ASESの誰かにリソースやその他の変更がある場合は、構成可能なタイマーの有効期限のいずれかで、それに応じて不正に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.
ソリューションは、ASEの1つにより最適なパスが存在するかどうかを再最適化するかどうかを制御するためのヘッドエンドLSRSが制御するオプションを提供する必要があります。
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.
同一のトラバースパスのセットの場合、ソリューションは、ヘッドエンドLSRSが、Inter-ASに沿ったトランジットASESの1つにより最適なパスが存在する可能性があるため、再最適化が発生するかどうかを制御するオプションを提供する必要があります。TE LSPパス。
Furthermore, the solution MUST provide the ability to reject re-optimization at AS boundaries.
さらに、ソリューションは、境界で再最適化を拒否する能力を提供する必要があります。
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つ以上のリンクがあります。マルチエースを備えたSPネットワークのASE間のトポロジー密度は、一般にはるかに高くなっています。リンク間障害が発生した場合、迅速な局所保護も利用可能になり、[TE-FRR]からの現在のMPLSの高速再ルートメカニズムと相互操作する必要があります。
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.
TET TETトンネル間にルーティングされるトラフィックは、ノードがASまたはAS境界の内部にある可能性のあるノード障害に対して高速で保護される必要があります。
The proposed inter-AS MPLS TE solution SHOULD satisfy core requirements documented in [DS-TE].
提案された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.
提案されたソリューションは、視点内および界面の両方の視点からネットワークスケーラビリティに最小限の影響を与える必要があります。
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.)
- IGP（IGP洪水、パス計算などの観点からの影響） - BGP（BGP内での追加情報、ルート数、フラップ、過負荷イベントなどの影響）-RSVP TE（メッセージレートに関する影響、保持された状態などの数）
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].
また、必要なMPLS TEトンネルの数が増加するにつれて、スケーラビリティの問題が潜在的にスケーラビリティの問題が発生する可能性があると考えられます。各通過POPによって維持されるトンネル状態の数を減らすために、提案されたソリューションは、個々のトンネルを1つ以上の凝集LSPに運ぶことができるようにLSP凝集を可能にする必要があります。たとえば、そのようなメカニズムの1つは、[MPLS-LSPHIE]で説明されています。
There SHOULD be several possibilities to map particular traffic to a particular destination onto a specific inter-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.
提案されたソリューションは、IGPS（ISISまたはOSPF）へのリンクとしてのリンクのコストに関連するコストを使用して、MPLS間のトンネルを「ASINTERINTINTERSTE TUNNELS」を「発表」する機能を提供する必要があります。そうすることで、TE Inter-As Path計算に参加しない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.
トラフィックエンジニアリングトンネルを管理および構成するために、SPSによるネットワーク管理プロトコルで使用するには、管理情報間情報ベース（MIB）が必要です。この新しいMIBは、この新しい機能に対応するために既存のMIBを拡張する（そして再発明するのではなく）する必要があります。
An inter-AS TE MIB should have features that include:
Temibとしている間、Inter-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.:
- 関連する制約（リソースなど）を備えたTETTENINELのセットアップ。 - トンネルヘッドエンドだけでなく、TEトンネルの他のポイントでのトラフィックおよびパフォーマンス統計のコレクション。-IPv4/v6の両方を＃またはパスメッセージ内のEROの＃subobjectsとして含めること、例えば：
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
liblicit_routeクラスオブジェクト：address1（loose ipv4 prefix、 /as1）address2（loose ipv4 prefix、 /as1）as2（as number）address3（loose ipv4 prefix、 /as3）address4（loose ipv4 prefix、 /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
address1（loose ipv4 prefix、 /as1）address2（ルーズIPv4プレフィックス、 /as1）address3（ルーズIPv4プレフィックス、 /as2）address4（loose ipv4 prefix、 /as2）address5（lease ipv4 prefix、 /as3）address6（roos、 /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（必要な場合）など - このドキュメントのセクション5で説明した特定の属性は、たとえば、各セグメントとしてのMPLS TEトンネル会計記録を含む。
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を介した障害検出のためのツールは、これまで広く開発されていません。今日のSPSは、データパス全体でホップバイホップファッションでこのような障害を手動でトラブルシューティングしています。データプレーンのエラーを検出した場合、障害がどこから来たのかを判断するために制御面をチェックする必要があります。
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.
提案されたソリューションは、TEとしての障害検出メカニズムと相互操作できる必要があり、IGP領域（OSPF）またはレベル（IS）で既知またはルーティング可能なTEトンネルエンディングアドレスを必要とする場合としない場合があります。ワーキングリターンパスを備えた通過ASES。
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]は、コントロールプレーンに対するデータプレーンを介した故障検出メカニズムと見なされており、lspsとしてのトラブルシューティングに使用できます。そのような施設は、採用されている場合、その後、パス間で拡張する必要があります。
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パスなど、診断テストパケットが代替データプレーンを介して戻ることができるように、ワーキングリターンパスを必要とするそのようなメカニズムの1つを示しています。
[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ネットワーク全体でどのように処理されるかを示し、このような施設もリンク間で拡張する必要があります。
The solution(s) MUST allow extensions as both inter-AS MPLS TE and current intra-AS MPLS TE specifications evolve.
ソリューションは、MPLS間および現在のMPLSの両方のMPLS仕様が進化するため、拡張を許可する必要があります。
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.
MPLS間の展開は、既存の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.
- lsp間のパスの最適性te lsp経路 - te lspセットアップ時間 - 故障と回復時間 - オーバーヘッドの追加によるコントロールプレーンの衝撃とスケーラビリティ - 追加されたデータ/転送面の衝撃とスケーラビリティオーバーヘッドなど
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 Adminドメインにまたがる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.
Multi-ASネットワークを備えたSPは、独自のドメインにASEを横切って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:
TE LSPの間で異なるSPSに属する複数の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内）からB（SP2のAS2内）までのTe LSPがあるとします。TE LSPパスとしての間に計算すると、AS2内のホップのセットがAS1に隠される可能性があります。この場合、ソリューションにより、AはA AS2内で使用されるホップのリストの詳細な知識なしに、Bへのより最適なTE LSPパス（制約のセットに準拠する）が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パスコストは、たとえばPCC-PCE通信など、A（PCC）を使用して、この情報を使用して最適なパスを計算できるようにすることができます。。（PCC-PCE通信については[PCE-COM]、PCEベースのパス計算アーキテクチャの説明については[PCE]を参照してください。）
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管理ドメインで使用される場合、トランジットまたはピアリングSPSの中間ホップまたはインターフェイスアドレスおよび/またはラベルに関してここで説明する同様の機密性要件を含める必要があります。。
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境界でポリシー管理が必要になる場合があります。つまり、SPSが相互接続契約ごとにAS間のポリシーを実施するか、MPLS間のMPLS TEシグナルリクエストの入力によって伝えられる要求されたパラメーターを変更できるようにするポリシーコントロールが侵入します。
It is worth noting that such a policy control mechanism may also be used between ASes within a SP.
このような政策制御メカニズムは、sp。
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.
このセクションでは、一連のイングレス制御ポリシーを形成するために使用できる要素のみについて説明しますが、SPSが制御ポリシーを構築できる二国間または多国間協定をどのように確立するかについては、この文書の範囲を超えています。
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パスメッセージ）の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帯域幅の入場制御は、RSVP-TEメッセージが割り当てよりも帯域幅リソースを要求しないことを確認する - ヘッドエンドトンネルエンディングIPアドレスで表すことができるオリジンを要求する、＃、neighbor as＃、neighbor asbrインターフェイスIPアドレスなどとして発信する-ds-te te-class <class-type、preemption> - frr属性：ローカル保護希望ビット、ノード保護が望むビット、および帯域幅保護が希望ビットを運ぶ[TE -FRR]で定義されているRSVPパスメッセージ内の - セッション属性またはファストリアウトオブジェクト - 許可または許可されていない最適化
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ポリシーサーバーをInter-as Policiesの実施に使用することもできます。実装では、ポリシー執行サーバーを使用できるようにする必要があります。この要件により、SPSはTET間のポリシーをより良くすることができます。
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:
状況によっては、SPSは、特定の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-CLASS <Class-Type、Preemption> -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.
同様に、書き換えノードは、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シグナル伝達中に交渉された帯域幅を超えないことを確認するために、Inter-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.
たとえば、Ingress Policerは、確立された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管理ドメインにわたるセキュリティ問題に対処する必要があります。MPLS Inter-As-AS MPLSは、現在のAS ASの拡張機能を超えて特定のセキュリティ拡張機能を追加することは期待されていませんが、境界として信頼できるモデルを確立する方法に関して、より大きな考慮事項を与えなければなりません。SPSには、認証（RSVP Integrityオブジェクトの使用など）、許可、および可能性のあるシグナリング要求を拒否する手段が必要です。また、SPSは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.
ユケジリ、デビッド・アラン、カート・エリック・リンドクヴィスト、デイブ・マクディーサン、クリスチャン・ジャケネット、キリエティ・コンペラ、エド・カーン、ジム・ボイル、トーマス・ナドー、ヤコフ・レクター、およびベルト・ウィジネンの提案とベルト・ウィジネンが、この議論に役立つコメントの際のコメントに役立つことに感謝します。書類。
[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.、Malcolm、J.、Agogbua、J.、O'Dell、M。、およびJ. McManus、「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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[BGP-MPLSVPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP VPNs", Work in Progress, October 2004.
[BGP-MPLSVPN] Rosen、E。およびY. Rekhter、「BGP/MPLS IP VPNS」、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、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.、Baker、F.、Weiss、W。、およびJ. Wroclawski、「Assured Forwarding PHB Group」、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] Davie、B.、Charny、A.、Bennet、J.C.、Benson、K.、Le Boudec、J.、Courtney、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-diff] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、 "Multi-protocol差別化されたサービスのラベルスイッチング（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.、Chiu、A.、Elwalid、A.、Widjaja、I。、およびX. Xiao、「インターネットトラフィックエンジニアリングの概要と原則」、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] Li、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] Boyle、J.、Gill、V.、Hannan、A.、Cooper、D.、Awduche、D.、Christian、B。、およびW. Lai、「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] Berger、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. Li、「Border Gateway Protocol 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. Swallow、「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、「マルチプロトコルラベルスイッチング（MPLS）ネットワークでのライブ（TTL）処理」、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] Le Faucheur、F。およびW. Lai、「差別化されたサービス認識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] Pan、P.、Swallow、G。およびA. Atlas、「LSPトンネルのRSVP-TEへの高速再配置」、RFC 4090、2005年5月。
[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、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチ付きパス（LSP）階層」、RFC 4206、2005年9月。
[MPLS-Recov] Sharma, V. and F. Hellstrand, "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.
[MPLS-Recov] Sharma、V。およびF. Hellstrand、「マルチプロトコルラベルスイッチング（MPLS）ベースの回復のフレームワーク」、RFC 3469、2003年2月。
[EXCLUDE-ROUTE] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to RSVP-TE", Work in Progress, August 2005.
[除外] Lee、Cy。、Farrel、A。、およびS. de Cnodder、「除外ルート - RSVP-TEへの拡張」、2005年8月の作業。
[PCE] Farrel, A., Vasseur, J.-P., and J. Ash, "Path Computation Element (PCE) Architecture", Work in Progress, September 2005.
[PCE] Farrel、A.、Vasseur、J.-P.、およびJ. Ash、「Path Computation Element（PCE）Architecture」、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.、et al。、「Path Computation Element（PCE）通信プロトコル（PCEP） - バージョン1」、2005年9月、Work in Progress。
Appendix A. Brief Description of BGP-based Inter-AS Traffic Engineering
付録A. BGPベースのトラフィックエンジニアリング間の簡単な説明
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自律システム（ASE）とネットワークリーチビリティ情報を交換するSPネットワーク内のように異なる可能性
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ベースのルーティングポリシーを適切に実施することにより、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.
- 「最も近い出口」ルーティングでは、あるSPから別のSPへのトラフィックを脱出し、最低のIGPまたはAS Intra-AS MPLS TEトンネルメトリックがBGPの次のASESから学んだ外部ルートから学んだ外部ルートから学習したパスに従うパスに従います - 」bgpパス属性 "based as_path、multi_exit_disc（med）、local_prefなどのBGPパス属性の1つまたは組み合わせに基づいた相互接続（ピアリングまたはトランジット）ポリシーによって出口トラフィックパスが決定される場合のルーティング選択メカニズム。
SPs have often faced a number of nondeterministic factors in the practices of inter-AS traffic engineering employing the methods mentioned above:
SPSは、上記の方法を採用して、トラフィックエンジニアリング間の実践において、多くの非決定的要因にしばしば直面しています。
- 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-PRENDITなど）
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.
さらに、ある程度の粒度を達成するために、SPSはBGP Inter-ASポリシーを実施することを選択できます。これらのポリシーは、1つのリンク間またはイングレストラフィックのリンク間リンクのセットに固有です。特定の属性を特定の属性でタグ付けすることにより、別のASにアナウンスする際に、イングレストラフィックは、特定のポップまたはSPのネットワーク内の領域から別のASから運命づけられます。もちろん、これは、他の人が着信ルートから事前定義された属性を一致させることにより自動化された出力ポリシーを許可するという仮定で動作します。
Editors' Addresses
編集者のアドレス
Raymond Zhang Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025 USA
Raymond Zhang Infonet Services Corporation 2160 E. Grand Ave. El Segundo、CA 90025 USA
EMail: raymond_zhang@infonet.com
J.-P. Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
J.-P.Vasseur Cisco Systems、Inc。300 Beaver Brook Road Boxborough、MA 01719 USA
EMail: jpv@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。