RFC4216 日本語訳
4216 MPLS Inter-Autonomous System (AS) Traffic Engineering (TE)Requirements. R. Zhang, Ed., J.-P. Vasseur, Ed.. November 2005. (Format: TXT=64640 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Zhang, Ed.
Request for Comments: 4216 Infonet Services Corporation
Category: Informational J.-P. Vasseur, Ed.
Cisco Systems, Inc.
November 2005
ワーキンググループのR.チャン、エドをネットワークでつないでください。コメントのために以下を要求してください。 4216年のInfonetサービス社のカテゴリ: 情報のJ.-P。 エドVasseur、シスコシステムズInc.2005年11月
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)インターネット協会(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 Traffic Engineering(MPLS TE)のサポートのための要件について議論します。 主な目標はこれらの必要条件を満たして、シナリオをサポートしながら定義のためのガイドライン、選択、およびどんな技術的解決法のための仕様開発も一般に、結果として生じる1セットの要件とシナリオに提示することです。
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
1. 序論…3 1.1. このドキュメントで中古のコンベンション…3 2. 作者を寄付します…4 3. 定義と要件声明…5 3.1. 定義…5 3.2. 目的と要件、相互、交通工学…7 3.2.1. 相互、帯域幅保証…7 3.2.2. 相互、リソース最適化…8 3.2.3. ASesの向こう側の速い回復…8 3.3. 相互、交通工学要件声明…9 4. アプリケーションシナリオ…9 4.1. アプリケーションシナリオが前提となる、相互、帯域幅保証…9 4.1.1. シナリオの私--広がっているか、仮想の大衆的な(VPoP)…9 4.1.2. シナリオII--広がっているか、仮想のトランク…11
Zhang & Vasseur Informational [Page 1] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[1ページ]のRFC4216MPLS、相互、Te要件2005年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
4.1.3. シナリオIII--終わるために終わってください、相互、CeからCeまでのMPLS Te…12 4.2. アプリケーションシナリオが前提となる、相互、リソース最適化…13 4.2.1. シナリオIV--、Te、直径、マルチ、独身のSPの中で…13 4.2.2. シナリオV--プライマリの、そして、余分な輸送としてのトランジットASes…14 5. 要件を詳しく述べる、相互、MPLS交通工学…16 5.1. 1つのSPの管理ドメインの中の要件…16 5.1.1. 相互、MPLS Te操作と相互運用性…16 5.1.2. シグナリングと経路計算について議定書の中で述べてください…16 5.1.3. 最適…17 5.1.4. さまざまに発送されていることのサポート、相互、Te LSP…17 5.1.5. 再最適化…18 5.1.6. 速くMPLS Teを使用する速い回復支援がコースを変更します…18 5.1.7. DS-Teサポート…18 5.1.8. スケーラビリティと階層的なLSPサポート…19 5.1.9. トラフィックに関するマッピング、相互、MPLS Teはトンネルを堀ります…19 5.1.10. 相互、MPLS Te管理…19 5.1.10.1. 相互、MPLS Te MIB要件…19 5.1.10.2. 相互、MPLS Te障害管理要件…20 5.1.11. 伸展性…21 5.1.12. 複雑さとリスク…21 5.1.13. 後方の互換性…21 5.1.14. パフォーマンス…21 5.2. 要件、相互、複数のSPの向こう側のMPLS Te…22 5.2.1. 秘密性…22 5.2.2. 方針コントロール…23 5.2.2.1. 相互、実施が取り締まるTe協定…23 5.2.2.2. 相互、Te書き直し方針…24 5.2.2.3. 相互、トラフィックの取り締まり…24 6. セキュリティ問題…24 7. 承認…24 8. 標準の参照…25 9. 有益な参照…25付録A.がBGPベースの記述に事情を知らせる、相互、交通工学…27
Zhang & Vasseur Informational [Page 2] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[2ページ]のRFC4216MPLS、相互、Te要件2005年11月
1. Introduction
1. 序論
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 Traffic Engineering(TE)メカニズムは、[TE-OVW]で説明されるようにネットワーク交通工学の最も重要な目的のいくつかを達成するためにService Providers(SPs)によって配布されるかもしれません。 これらの目的は以下としてまとめられます。
- Supporting end-to-end services requiring Quality of Service (QoS)
guarantees
- Performing network resource optimization
- Providing fast recovery
- 終わりから終わりに対する速い回復を供給して、ネットワーク資源最適化を実行して、Service(QoS)保証をQualityに要求するサービスをサポートします。
However, this traffic engineering mechanism can only be used within an Autonomous System (AS).
しかしながら、Autonomous System(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 Traffic Engineeringメカニズムのための要件について議論します。
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交通工学メカニズムが必要であるかもしれない1セットのアプリケーションシナリオを提示するでしょう。 本書では提示された要件に基づいた状態でこのメカニズムを実装することができました。
These application scenarios will also facilitate discussions for a detailed requirements list for this inter-AS Traffic Engineering mechanism.
また、これらのアプリケーションシナリオはこの相互AS Traffic Engineeringメカニズムのための詳細な要件リストのための議論を容易にするでしょう。
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.
交通工学がInteriorゲートウェイプロトコル(IGP)を含む他の手段があります。 測定基準ベース(ASの中の使用のための)。 そして、ボーダ・ゲイトウェイ・プロトコル、(トラフィック経路の、より下品なコントロールを提供する属性ベース(ASesの向こう側の使用Appendix Aで説明されるように)のBGP。 しかしながら、このドキュメントは相互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.
このドキュメントは本書ではリストアップされたすべての必要条件を満たす実際的な解決を持っているのが可能であるかどうかに関してどんなクレームもしません。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC-2119]で説明されるように本書では解釈されることであるべきですか?
Zhang & Vasseur Informational [Page 3] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[3ページ]のRFC4216MPLS、相互、Te要件2005年11月
2. Contributing Authors
2. 作者を寄付します。
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社の庭の空気Tower飯田橋、千代田区、東京102-8460(日本)はメールされます: ke-kumaki@kddi.com
Paul Mabey Qwest Communications 950 17th Street, Denver, CO 80202, USA EMail: pmabey@qwest.com
第17通り、ポールMabeyクエストコミュニケーションズ950デンバー、CO 80202、米国はメールされます: pmabey@qwest.com
Nadim Constantine Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025. USA EMail: nadim_constantine@infonet.com
ナディムコンスタンティーヌInfonetは社2160のE.の壮大なAveを調整します。 エルセガンド、カリフォルニア 90025。 米国メール: nadim_constantine@infonet.com
Pierre Merckx EQUANT 1041 route des Dolines - BP 347 06906 SOPHIA ANTIPOLIS Cedex, FRANCE EMail: pierre.merckx@equant.com
ピアーメルクスイクアント1041ルートdes Dolines--ソフィアANTIPOLIS Cedex、BP347 06906フランスEMail: 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
Wo青ベルカナダ181カナダ金融界、スイート350トロント、オンタリオ(カナダ)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
ジャン・ルイル・ルーフランステレコム2、Lannion Cedex、大通りピアー-Marzin22307フランスEMail: jeanlouis.leroux@francetelecom.com
Yonghwan Kim SBC Laboratories, Inc. 4698 Willow Road Pleasanton, CA 94588, USA EMail: Yonghwan_Kim@labs.sbc.com
YonghwanキムSBC研究所Roadプレザントン、Inc.4698Willowカリフォルニア 94588、米国EMail: Yonghwan_Kim@labs.sbc.com
Zhang & Vasseur Informational [Page 4] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[4ページ]のRFC4216MPLS、相互、Te要件2005年11月
3. Definitions and Requirements Statement
3. 定義と要件声明
3.1. Definitions
3.1. 定義
The following provides a list of abbreviations and acronyms specifically pertaining to this document:
以下は明確にこのドキュメントに関係する略語と頭文字語のリストを提供します:
SP: Service Providers including regional or global
providers.
SP: 地方の、または、グローバルなプロバイダーを含むProvidersを調整してください。
SP Administrative
Domain: a single SP administration over a network or
networks that may consist of one AS or multiple
ASes.
SPの管理ドメイン: 1ASか複数のASesから成るかもしれないネットワークかネットワークの上のただ一つの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.
イントラ、-、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.
相互、Te: 1の向こう側にIPだけ、そして/または、IP/MPLSネットワークの上で動作する交通工学メカニズムか複数のASesのためのジェネリック定義。 このドキュメントが、IP/MPLSがネットワークであると扱うだけであるので、Inter-AS TEの少しの参照も、本書ではIP/MPLSネットワークだけを示して、TE要件をIPだけに扱うことを意図しません。
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.
イントラ、-、MPLS Te: TE Label Switched Path(LSP)、Head-終わりのLabel Switching Router(LSR)、およびTail-終わりのLSRが交通工学目的のための同じASに住んでいるMPLS Traffic Engineeringメカニズム。
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 Te: TE LSPs、Head-終わりのLSR、およびTail-終わりのLSRが同じASの中に住んでいないか、Head-終わりのLSRとTail終わりのLSRの両方が同じASにありますが、またはTE LSPトランジット経路が異なったASesのむこうにあるかもしれないMPLS Traffic Engineeringメカニズム。
Zhang & Vasseur Informational [Page 5] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[5ページ]のRFC4216MPLS、相互、Te要件2005年11月
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: 自治のSystem Border RoutersはASesとインタコネクトする1個以上のリンクを通して異なるか同じService Providerの別の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.
相互、Te経路: 複数のASesを横断するTE経路とASBRs、例えば、AS1-ASBR1相互ASは(s)-ASBR2-AS2をリンクします… ASBRn-ASn。
Inter-AS TE Segment: A portion of the Inter-AS TE path.
相互、Teセグメント: Inter-AS TE経路の部分。
Inter-AS DS-TE: Diffserv-aware Inter-AS TE.
相互、DS-Te: Diffserv意識する、相互、Te。
CE: Customer Edge Equipment
Ce: 顧客縁の設備
PE: Provider Edge Equipment that has direct connections
to CEs.
PE: CEsにはダイレクト接続があるプロバイダーEdge Equipment。
P: Provider Equipment that has backbone trunk
connections only.
P: バックボーントランク接続しかないプロバイダーEquipment。
VRF: Virtual Private Network (VPN) Routing and
Forwarding Instance.
VRF: 仮想私設網(VPN)ルート設定とインスタンスを進めること。
PoP: Point of presence or a node in SP's network.
以下を飛び出させてください。 存在のポイントか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]で定義されるようにセットにおけるすべてのリンクに影響するかもしれないリソースを共有するなら、1セットのリンクは'共有されたリスクリンク群'(SRLG)を構成するかもしれません。
PCC: Path Computation Client; any client application
requesting a path computation to be performed by
the Path Computation Element.
PCC: 経路計算クライアント。 Path Computation Elementによって実行されるよう経路計算に要求するどんなクライアントアプリケーション。
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に接続されることを意味するというわけではありません。
Zhang & Vasseur Informational [Page 6] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[6ページ]のRFC4216MPLS、相互、Te要件2005年11月
3.2. Objectives and Requirements of Inter-AS Traffic Engineering
3.2. 目的と要件、相互、交通工学
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が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) 相互、リソース最適化と3) すなわち、ASesの向こう側の速いRecovery、Inter-ASリンクス/SRLGとASBR NodesのRecovery。
3.2.1. Inter-AS Bandwidth Guarantees
3.2.1. 相互、帯域幅は保証します。
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-デフ]で説明された1セットのメカニズムを定義しました。 これらのメカニズムは、最大の一方向トランジット遅れ、相互パケット遅れ変化、損失率などで言い表すことができるQoS方針(または、1セットの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.
多くの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つの典型的な例はEF(Forwarding[DIFF_EF]を速める)のクラスとしてDiffservによって可能にされたネットワークで分類されたVoIPトラフィックのために終わりから端への経路の上に帯域幅保証を提供することです。 EF経路が複数のASesの向こう側に広げられると、相互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帯域幅保証のための別のケースは、1か複数のASesの向こう側にある量のトランジット帯域幅を保証するための要件です。
Several application scenarios are presented to further illustrate this requirement in section 4 below.
いくつかのアプリケーションシナリオが、下のセクション4でさらにこの要件を例証するために提示されます。
Zhang & Vasseur Informational [Page 7] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[7ページ]のRFC4216MPLS、相互、Te要件2005年11月
3.2.2. Inter-AS Resource Optimization
3.2.2. 相互、リソース最適化
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.
Service Provider(SP)ネットワークでは、BGPプロトコル[BGP]は、ASesの間でルーティング情報を交換するために配布されます。 また、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.
SPsは相互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.
しかしながら、SPネットワークが複数のASesの上で配布される(相互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.
別の例は異なったSP管理ドメインの間の相互ASリンクが設立されるところです。 非調整されたルーティングや、ネットワーク変化や、サブ最適な交通状況などの非決定論的要素は潜在的に現在の交通工学メカニズムがたぶんよく比例しない複雑なセットの相互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交通工学メカニズムで補足となる必要があるでしょう。
3.2.3. Fast Recovery across ASes
3.2.3. ASesの向こう側の速い回復
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.
ASesの向こう側のVoIPなどのサービスを広げるとき、顧客は、しばしばSPsが同じ技量目標を維持するのを必要とします、パケット損失やサービスの有用性のように、ASの中で達成されるように。 結果として、リンク/SRLG/ノード障害での安定したファッションにおける速い集合は強い要件になります。 これは現在の相互ドメインのテクニックで達成するのが明確に難しいです、特にASBRsの間のリンク/SRLGの故障かASBRノード障害の場合で。
Zhang & Vasseur Informational [Page 8] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[8ページ]のRFC4216MPLS、相互、Te要件2005年11月
3.3. Inter-AS Traffic Engineering Requirements Statement
3.3. 相互、交通工学要件声明
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を配布する適切なケースのように、相互ASの向こう側に配布するべきBGPベースの交通工学能力の必要性に加えた相互AS TEメソッドはリソース最適化、帯域幅保証、および速い回復が必要であるところにリンクされます。
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.
これは異なったASesの向こう側に全体の経路に関して一貫して統計的な性能目標を維持しなければならない[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ネットワークのものへの同様の要件に関する十分な関心がないので、今後の考慮のためにIPだけの上の相互AS交通工学ネットワークはものです。 より明確に、このドキュメントはパケットベースのIP/MPLSネットワークのための相互AS TE要件をカバーするだけです。
4. Application Scenarios
4. アプリケーションシナリオ
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メカニズムで要件を扱うことができないIP/MPLSネットワークの上にいくつかのアプリケーションシナリオを提示して、相互AS 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.
以下の議論では明らかに注意されませんが、ここに提示されたすべてのアプリケーションシナリオには、安定したファッションで複数のASesに交差するトラフィック経路の速い回復はAS境界でリンク/SRLG/ノード障害の場合で特に重要です。
4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees
4.1. アプリケーションシナリオが前提となる、相互、帯域幅は保証します。
4.1.1. Scenario I - Extended or Virtual PoP (VPoP)
4.1.1. シナリオI--広げられたか仮想のポップス(VPoP)
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)のネットワークが既により濃いネットワーク存在を確立した領域に範囲を広くしたがっています。
Zhang & Vasseur Informational [Page 9] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[9ページ]のRFC4216MPLS、相互、Te要件2005年11月
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.
このシナリオに、1のSP2か複数のポイントがその領域にある状態で、SP1はインタコネクトを確立するかもしれません。 それらの顧客濃い領域では、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のASBRかPEルータと以下のダイヤグラムで例証されるようにSP2のPoPsに共同位置するSP1のPEルータの間に1相互AS MPLS TE LSPsを造ることができます:
<===========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------+
<======相互、MPLS Teトンネル===========>。----- ----- ________|ASBR|___相互___|ASBR|________ | | RTR| リンク| RTR| | ---- ----- ----- ----- ----- |SP1|_相互、_| SP2| | SP1| |VPoP| リンク|P/PE| |P/PE| ---- ----- ----- ----- ----- |________|ASBR|___相互___|ASBR|________| | RTR| リンク| RTR| ----- ----- <=========相互、MPLS Teトンネル======================>+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のネットワークは、コンパチブル性能目標で1セットのトラフィックのクラスをサポートするために各ホップで支給に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トンネルのHead-終わりとTail-終わりのLSRsには、この場合、そのようなTEトンネルは数個のASesに交差するかもしれませんが、同じAS番号があるかもしれません、上のダイヤグラムで示されるように。
Zhang & Vasseur Informational [Page 10] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[10ページ]のRFC4216MPLS、相互、Te要件2005年11月
4.1.2. Scenario II - Extended or Virtual Trunk
4.1.2. シナリオII--広げられたか仮想のトランク
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は、SP1のネットワークの中でSP2のPEルータへのSP2 PoP(SP1と顧客CEsが直接接続される)とSP1のASBRの間のSP2のMPLSネットワークを通して相互AS TEトンネルを建設して、合図できる顧客VPNサイトか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--SP1のCEの回線折返しに集められる広げられたか仮想のトランクとしての相互AS MPLS TEトンネル機能はSP1のネットワークで位置するTE LSP末端ルータに帯域幅を保証できるSP2のMPLSネットワークの回路にアクセスします、以下のダイヤグラムで示されるように:
<====Inter-AS MPLS TE Tunnel====>
or
< ===Inter-AS MPLS TE Tunnel===============>
<==相互、MPLS Teトンネル====>か<。===相互、MPLS Teトンネル===============>。
---- ----- ----- ----- -----
| CE |_____Local___| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 |
| | Loop | PE | | RTR | Link | RTR | |PE |
---- ----- ----- ----- -----
---- ----- ----- ----- ----- | Ce|_____ローカル___| SP2|___|ASBR|___相互___|ASBR|___|SP1| | | 輪| PE| | RTR| リンク| RTR| |PE| ---- ----- ----- ----- -----
+SP1 Customer ASx+ +-----SP2 AS2---+ +-SP1 AS1-------+
+ SP1顧客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--相互AS MPLS TEトンネルはこの場合アクセスSP1のSP2のネットワークのSP1のCEからASBRかPEへの広げられたか仮想の地方のリンクとして機能します:
<==============Inter-AS MPLS TE Tunnel==============>
or
<==============Inter-AS MPLS TE Tunnel========================>
<=======相互、MPLS Teトンネル==============>か<。==============相互、MPLS Teトンネル========================>。
---- ----- ----- ----- -----
| CE |____Local_____| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 |
| | Loop | PE | | RTR | Link | RTR | |PE |
---- ----- ----- ----- -----
---- ----- ----- ----- ----- | Ce|____ローカル_____| SP2|___|ASBR|___相互___|ASBR|___|SP1| | | 輪| PE| | RTR| リンク| RTR| |PE| ---- ----- ----- ----- -----
+SP1 Customer ASx+ +------SP2 AS2---+ +--SP1 AS1-----+
+ SP1顧客ASx++------SP2 AS2---+ +--SP1 AS1-----+
Zhang & Vasseur Informational [Page 11] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[11ページ]のRFC4216MPLS、相互、Te要件2005年11月
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.
Case2では、上では、SP2が、ただSP2 PEからSP1のCEsが接続されているところまで合図されたトンネル州の数を減少させるためにトランジットPかPEルータとSP2のASBRルータの間の集合か階層的なイントラ-AS MPLS TEトンネルを確立するのを選ぶかもしれません。
4.1.3. Scenario III - End-to-End Inter-AS MPLS TE from CE to CE
4.1.3. シナリオIII--終わるために終わってください、相互、CeからCeまでのMPLS Te
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==================>
<===========相互、MPLS Teトンネル==================>。
--- ----- ----- ----- ----- ---
|CE1|_____| SP2 |___|ASBR |__Inter-AS__|ASBR |____| SP1 |_____|CE2|
| | | PE | | RTR | Link | RTR | | PE | | |
--- ----- ----- ----- ----- ---
--- ----- ----- ----- ----- --- |CE1|_____| SP2|___|ASBR|__相互、__|ASBR|____| SP1|_____|CE2| | | | PE| | RTR| リンク| RTR| | PE| | | --- ----- ----- ----- ----- ---
+Cust ASx+ +---SP2 AS-----+ +-------SP1 AS-------+ +Cust ASy+
+ Cust ASx++---SP2-----+ +-------SP1-------+ + 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が外部のBGP(eBGP)がじっと見ているSP1の顧客である関係がCE-PEリンクの向こう側に確立した別の例を例証します。 そして、相互AS MPLS TEトンネルはAS2のSP1のネットワークの向こう側のCE1のものよりASxのCE1からCE2まで確立されるかもしれません。(CE2は同じASか異なったASに属すかもしれません)。
<===============Inter-AS MPLS TE Tunnel=====================>
<========相互、MPLS Teトンネル=====================>。
--- ----- ---- ---- ----- ---
|CE1|______| SP1 |_____|SP1 |____|SP1 |____| SP1 |_________|CE2|
| | | PE1 | |P1 | |P2 | | PE2 | | |
--- ----- ---- ---- ----- ---
--- ----- ---- ---- ----- --- |CE1|______| SP1|_____|SP1|____|SP1|____| SP1|_________|CE2| | | | PE1| |P1| |P2| | PE2| | | --- ----- ---- ---- ----- ---
+-Cust ASx-+ +-------------SP1 AS2----------------+ +-Cust ASy-+
+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トンネルが数度の部分的なメッシュか完全なメッシュにあると、Scenario IIIはよく比例しないでしょう。 したがって、このシナリオにはわずかな展開しかないと予想されます、階層的なイントラ-AS TE-LSPsなどのいくつかのメカニズムがシグナリング州の数を減少させるのに使用されない場合。
Zhang & Vasseur Informational [Page 12] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[12ページ]のRFC4216MPLS、相互、Te要件2005年11月
4.2. Application Scenarios Requiring Inter-AS Resource Optimization
4.2. アプリケーションシナリオが前提となる、相互、リソース最適化
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--、Te、直径、マルチ、ただ一つのSP管理ドメイン
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メカニズムが1セットのオンラインの、または、オフラインの規制ベースの経路計算アルゴリズムで交通経路最適化[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(特に複数の大陸の向こう側のネットワークがあるそれら、およびまばらに接続されたネットワークがあるそれら)が境界に沿って、または、ASesの数が数十にほんのわずかなaから変化できる自制的であるか亜大陸の境界の中でそれらのマルチASルーティング方針を設計しました。 一般に、相互大陸かサブ大陸容量は非常に高価です。 いくつかのService Providersが同じ国に複数のASesを持って、それらの相互領域のリンクの上にリソースを最適化したがっています。 これは、よりスケーラブルな度のリソース最適化を要求するでしょう。(それは、相互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:
さらに、部分的というよりむしろ全体ですべてのネットワーク資源を調整するとき計画されている交通最適化と経路保護/復元模型を行う際に、より高い効率を達成するだけであるかもしれません。 多くのASesから成るかもしれないネットワークにおいて相互AS TE LSPsの設立を通してこれを実感できました、以下のダイヤグラムで示されるように:
Zhang & Vasseur Informational [Page 13] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[13ページ]のRFC4216MPLS、相互、Te要件2005年11月
<===================Inter-AS MPLS Tunnel=============>
-------- -------- --------
| |_______________| |____________| |
| SP1 |_______________| SP1 |____________| SP1 |
| AS1 |_______________| AS2 |____________| AS3 |
| | | | | |
-------- -------- --------
|| ||
|| --------- ||
||___________________| SP1 |________________||
|____________________| AS4 |_________________|
| |
---------
<==========相互、MPLSはトンネルを堀ります。=============>。-------- -------- -------- | |_______________| |____________| | | 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 LSPがあるダイヤグラムで例証されるように任意な点からネットワークの任意な点まで維持される統計的な達成目標がことであるDiffservによって可能にされたネットワークでさらに際立っています:
<===================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------+
<==========相互、MPLS DS-Teトンネル=============>。---- ----- ----- ----- ----- ---- | PE|__| P|___|ASBR|___相互___|ASBR|___|P|___|PE| | RTR| | RTR| | RTR| リンク| 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.
例えば、対応する帯域幅要件があるL2 Pseudo WiresかVoIPの1セットを輸送するのに使用できるのが上のダイヤグラムで示された相互AS MPLS DS-TE LSP交通。
Furthermore, fast recovery in case of ASBR-ASBR link failure or ASBR node failure is a strong requirement for such services.
その上、ASBR-ASBRリンクの故障かASBRノード障害の場合の速い回復はそのようなサービスのための強い要件です。
4.2.2. Scenario V - Transit ASes as Primary and Redundant Transport
4.2.2. シナリオV--第一で余分であるとしてのASesが輸送するトランジット
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は1以上の相互AS MPLS TEトンネルかSP2、SP3などに属す複数のトランジットASesを建設することによって、コア背骨に地域ネットワークをリンクしたがっています、以下のダイヤグラムで示されるように:
Zhang & Vasseur Informational [Page 14] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[14ページ]のRFC4216MPLS、相互、Te要件2005年11月
<===========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-+
<======相互、MPLS Teトンネル=======> [ ] [ ] [ ] [ ---- ---- ] [ ---- ---- ] [ ---- ---- ] [ |P/PE|__|ASBR|]_Inter-AS_[|ASBR|.|ASBR|]_Inter-AS_[|ASBR| |P/PE|] [ |RTR | |RTR |] Link [|RTR | |RTR |] Link [|RTR | |RTR |] [ ---- ---- ] [ ---- ---- ] [ ---- ---- ] [ ] [ ] [ ] <================相互、MPLS Teトンネル=====================>+SP1の地方のASx++トランジットSP2 AS2など。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.
セクション4.1.1で"VPoP"がどこにあるかもしれないかが示されたScenario Iの、より広いケースがSP1の地域ネットワークに拡大するのに従って、このシナリオを見ることができます。 同様に、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+
<======相互、MPLS Teトンネル=======>+----------------------------SP1 AS1-----------------------------+ [ ] [ ---- ---- ---- ---- ] [ |P/PE|__|ASBR|__________Primary Intera-AS________|P | |PE |] [ |RTR | |RTR | Link |RTR | |RTR |] [ ---- ---- ---- ---- ] [ | | ] [ ---- ---- ] [ |ASBR| |ASBR| ] [ |RTR | |RTR | ] [ ---- ---- ] ^ | | ^ | | | | | | [ ] | | | | [ ---- ---- ] | | | |__ 相互、_、[| ASBR|、| ASBR|、]、_、相互、_| | | リンク[| RTR| | RTR|]リンク| | [ ---- ---- ] | | [ ] | | | +======バックアップ、相互、MPLS Teトンネル======+ + トランジットSP2 AS2、SP3 AS3など…SPi ASi+
Zhang & Vasseur Informational [Page 15] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[15ページ]のRFC4216MPLS、相互、Te要件2005年11月
5. Detailed Requirements for Inter-AS MPLS Traffic Engineering
5. 要件を詳しく述べる、相互、MPLS交通工学
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つの主要な領域で相互AS MPLS TEのための詳細な要件について論じます: 同じSPの管理ドメインと2における相互AS MPLS TEのための1)の要件) 異なったSP管理ドメイン中の相互AS MPLS TEのための要件。
5.1. Requirements within One SP Administrative Domain
5.1. 1つのSPの管理ドメインの中の要件
This section presents detailed requirements for inter-AS MPLS TE within the same SP administrative domain.
このセクションは同じSPの管理ドメインの中に相互AS MPLS TEのための詳細な要件を提示します。
5.1.1. Inter-AS MPLS TE Operations and Interoperability
5.1.1. 相互、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解決策SHOULDは[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.
提案された解決策SHOULDは終わりから終わりへのResource予約プロトコル(RSVP)が合図しているHead/末端でTE LSPの食糧を供給することを許します。(結局、ゆるい経路) 横断が直径で、さらに食糧を供給することのないインタコネクトされたASBRsがトランジット経路に沿って必要です。
5.1.2. Protocol Signaling and Path Computations
5.1.2. プロトコルシグナリングと経路計算
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.
1つは、相互ASリンクの向こう側に合図された相互AS MPLS TEトンネル経路がASes、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:
または、提案された解決策SHOULDが明らかに選択するために能力を提供する、自動、発見、以下の要素、相互AS TE LSP経路に合図するとき:
- a set of AS numbers as loose hops and/or
- a set of LSRs including ASBRs
- そして/または、1セットのゆるいAS同じくらい番号が跳ぶ、--aがLSRsがASBRsを含んでいるのをセットした
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.
それは、また、Explicit Route Object(ERO)の上の要素を指定して、まさしく相互AS TE LSPによって横断されたASesかASBRsのセットの動向をおさえるResvメッセージのRecord Route Object(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ネットワークの中の複数のASesを横断しながら相互AS TE LSPを設立する場合では、解決策SHOULDはHead-終わりのLSRにトランジットのASesのどれかの向こう側に明らかにホップを指定させます、そして、また、TEトンネルHead-終わりのSHOULDは規制が迎えられるのを確実にするために明白なセグメントをチェックします。
Zhang & Vasseur Informational [Page 16] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[16ページ]のRFC4216MPLS、相互、Te要件2005年11月
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].
さらに、提案された解決策SHOULDは指定して、あるゆるいか明白なノード(例えば、AS番号など)とリソースが相互AS TE LSP経路設立で明らかに除かれることであると合図する能力を提供します、[EXCLUDE-ROUTE]で定義されたものなどのように。
5.1.3. Optimality
5.1.3. 最適
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.
解決策SHOULDは[TE-REQ)で定義される1セットのTE規制に応じて、最適経路に続く相互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メートル法の方針を持っている数個のASesの向こう側の相互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とSHOULDが経路以来の減少している最適(または、サブの最適)を考慮するので、SHOULDが終わりから端への最適の経路を計算して、証明するためにメカニズムを提供する解決策はLSPの生涯最適のままで残らないかもしれません。
5.1.4. Support of Diversely Routed Inter-AS TE LSP
5.1.4. さまざまに発送されていることのサポート、相互、Te LSP
Setting up multiple inter-AS TE LSPs between a pair of LSRs might be desirable when:
1組のLSRsの間の複数の相互AS TE LSPsをセットアップするのが望ましいかもしれない、いつ:
(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経路がネットワーク要素の故障の影響を交通の部分に制限するのに必要であるかもしれません(例、2VoIP門がロードされるかもしれないように、相互AS TE LSPsの1セットの中で交通のバランスをとってください)。
(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.
例では、上では、さまざまに発送されたTE LSPsはセットアップできるのが相互AS TEのための要件になります。
The solution SHOULD be able to set up a set of link/SRLG/Node diversely routed inter-AS TE LSPs.
解決策SHOULD、さまざまに発送されたリンク/SRLG/ノードの1セットに相互AS TE LSPsを設定できてください。
Zhang & Vasseur Informational [Page 17] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[17ページ]のRFC4216MPLS、相互、Te要件2005年11月
5.1.5. Re-Optimization
5.1.5. 再最適化
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がいったん設立されて、いずれかがリソースか他の変化であるならASesのだれのも中にそこに設立されると、解決策はTEトンネルHead-エンドのときに構成可能なタイマの満了かネットワークイベントか手動要求で引き起こされるときそれに従って、非破壊的にLSPを再最適化できなければなりません。
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.
ASesの1つの、より最適の経路が存在しているなら再最適化するなら、Head-終わりのLSRsが制御するように、解決策SHOULDはオプションを提供します。
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.
同じセットの横断された経路の場合では、Head-終わりのLSRsが、相互AS TE LSP経路に沿ってトランジットASesの1つにおける、より最適の経路が存在できたので再最適化が起こるかどうかを制御するように、解決策SHOULDはオプションを提供します。
Furthermore, the solution MUST provide the ability to reject re- optimization at AS boundaries.
その上、解決策はAS境界で再最適化を拒絶する能力を提供しなければなりません。
5.1.6. Fast Recovery Support Using MPLS TE Fast Reroute
5.1.6. 速くMPLS Teを使用する速い回復支援がコースを変更します。
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].
一般に、冗長のための複数の組のASBRsの間には、2個以上の相互ASリンクがあります。 一般に、マルチASesとのSPネットワークにおけるASesの間の位相的な密度ははるかに高いです。 相互ASリンクの故障の場合、急速な地方の保護SHOULDはまた、利用可能に作られていて、現在のイントラ-AS MPLS TEと共に[TE-FRR]からメカニズムを速く別ルートで送りますSHOULDが、共同利用する。
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トンネルSHOULDに掘られました、また、ノードがASに内部であるかもしれないところかAS境界のどんなノード障害に対して速く保護されてください。
5.1.7. DS-TE Support
5.1.7. DS-Teサポート
The proposed inter-AS MPLS TE solution SHOULD satisfy core requirements documented in [DS-TE].
提案された相互AS MPLS TE解決策SHOULDは[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]SHOULDのセクション4.1の互換性節が解決策開発に忠実に適用されると指摘する価値があります。
Zhang & Vasseur Informational [Page 18] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[18ページ]のRFC4216MPLS、相互、Te要件2005年11月
5.1.8. Scalability and Hierarchical LSP Support
5.1.8. スケーラビリティと階層的なLSPサポート
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.)
- 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].
また、必要な相互AS MPLS TEトンネルの数が増加するのに従ってスケーラビリティ問題が潜在的にあるだろうというのが想像できます。 PoPを通過しながらそれぞれによって維持されるようにトンネル州の数を減少させて、提案された解決策SHOULDは、LSP(s)に集めながら個々のトンネルを1つ以上まで運ぶことができるようにTE LSPに集合を許容します。 例えばそのようなメカニズムの1つは[MPLS-LSPHIE]で説明されます。
5.1.9. Mapping of Traffic onto Inter-AS MPLS TE Tunnels
5.1.9. 交通に関するマッピング、相互、MPLS Teはトンネルを堀ります。
There SHOULD be several possibilities to map particular traffic to a particular destination onto a specific inter-AS TE LSP.
そこ、SHOULD、特定の目的地への特定の交通を特定の相互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.
また、提案された解決策SHOULDはリンクとしてそれがあるリンクの費用が関連しているIGPs(イシスかOSPF)に相互AS MPLS TEトンネルを「発表する」能力を提供します。 そうすることによって、相互AS TE経路計算に参加しないPEルータはIGPベースのSPF計算でそのようなリンクを考慮に入れることができます。
5.1.10. Inter-AS MPLS TE Management
5.1.10. 相互、MPLS Te管理
5.1.10.1. Inter-AS MPLS TE MIB Requirements
5.1.10.1. 相互、MPLS Te MIB要件
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によるネットワーク管理プロトコルによる使用が相互AS交通工学トンネルを管理して、構成するのに相互AS TE Management Information基地(MIB)が必要です。 そして、この新しいMIB SHOULDが広がっている、(再発明しない、)、この新しい機能性に対応する既存のMIBs。
Zhang & Vasseur Informational [Page 19] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[19ページ]のRFC4216MPLS、相互、Te要件2005年11月
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のクラスは反対します: address1(IPv4 Prefixを発射してください、/AS1)address2(IPv4 Prefixを発射してください、/AS1)AS2(AS番号)address3(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
address1(IPv4 Prefixを発射してください、/AS1)address2(IPv4 Prefixを発射してください、/AS1)address3(IPv4 Prefixを発射してください、/AS2)address4(IPv4 Prefixを発射してください、/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.
- 同様に、RROの包含は、インタフェースIPv4/v6アドレス(そうでなければ、隠される)、AS番号、ラベル、ノードイド(必要であると)などのサブ物を記録しながら、Resvメッセージで反対します。 - このドキュメント包含のセクション5で議論する相互ASの特定の属性、例えば、相互AS MPLS TEはそれぞれのASセグメントの向こう側に会計帳簿にトンネルを堀ります。
5.1.10.2. Inter-AS MPLS TE Fault Management Requirements
5.1.10.2. 相互、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は制御飛行機とデータ飛行機の故障の両方を検出したがっています。 しかし、LSPsの上の欠点検出のためのツールは今までのところ、広く開発されていません。 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.
提案された解決策SHOULDがイントラ-AS TEの欠点検出メカニズムで共同利用できて、IGP領域(OSPF)かレベルの向こう側に知られているか、または発送可能するように相互AS TEトンネル終了アドレスを必要とするかもしれない、(-、)、トランジットの中では、働きがあるASesは経路を返します。
Zhang & Vasseur Informational [Page 20] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[20ページ]のRFC4216MPLS、相互、Te要件2005年11月
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 LSPsを障害調査するのに使用できました。 そのような施設の、そして、採用されたSHOULD、そして、相互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ネットワーク、およびこのSHOULDのような施設の向こう側にどう処理されるかもしれないかを提示します、また、相互AS TEリンクに広げられてください。
5.1.11. Extensibility
5.1.11. 伸展性
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仕様の両方が発展するとき、解決策は拡大を許さなければなりません。
5.1.12. Complexity and Risks
5.1.12. 複雑さとリスク
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.
提案された解決策SHOULD NOTは現在の操作ネットワークに不要な複雑さを安定性に影響するだろうというそのような程度まで紹介して、SPネットワークの上でそのような解決策を配備する利益を減少させます。
5.1.13. Backward Compatibility
5.1.13. 後方の互換性
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 SHOULD NOT衝撃既存のBGP交通工学かMPLS TEメカニズムの展開。
5.1.14. Performance
5.1.14. パフォーマンス
The solution SHOULD be evaluated taking into account various performance criteria:
解決策SHOULD、様々なパフォーマンス基準を考慮に入れながら、評価されてください:
- 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準備時間--失敗と回復時間--影響を与えて、加えられたオーバーヘッドによる制御飛行機のスケーラビリティなど - 加えられたオーバーヘッドなどによるデータ/推進飛行機の衝撃とスケーラビリティ
Zhang & Vasseur Informational [Page 21] RFC 4216 MPLS Inter-AS TE Requirements November 2005
チャンとVasseurの情報[21ページ]のRFC4216MPLS、相互、Te要件2005年11月
5.2. Requirements for Inter-AS MPLS TE across Multiple SP
Administrative Domains
5.2. 要件、相互、複数のSPの管理ドメイン中の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アドミンドメインSHOULDの向こう側の相互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は、それ自身のドメインのASesの向こう側にTEにトンネルを建設するとき、以下の2つのセクションで議論した特徴をつけないのを選ぶかもしれません。
5.2.1. Confidentiality
5.2.1. 秘密性
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が異なったSPsに属す複数のASesにかかるかもしれないので、解決策MIGHTはASの中でTE LSPによって使用されたホップのセットを隠させます、以下の例で例証されるように:
[ ASBR1-----ASBR2 ] [ ] [ ] [ A ] [ B ] [ AS1 ] [ AS2 ] [ SP1 ]-----[ SP2 ] [ ] [ ]
[ASBR1-----ASBR2] [ ] [ ] [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の中の)まで相互AS TE LSPがあると仮定してください。 相互AS TE LSP経路を計算するとき、AS2の中のホップのセットはAS1に隠されるかもしれません。 この場合、Aは、解決策でB(それは規制のセットに従う)への、より最適のTE LSP経路がASBR2を横断することを学ぶことができるでしょう、AS2の中で使用されたホップのリストに関する詳細な知識なしで。
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.)
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.)
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.
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.
Zhang & Vasseur Informational [Page 22] RFC 4216 MPLS Inter-AS TE Requirements November 2005
Zhang & Vasseur Informational [Page 22] RFC 4216 MPLS Inter-AS TE Requirements November 2005
5.2.2. Policy Control
5.2.2. Policy Control
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.
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.
It is worth noting that such a policy control mechanism may also be used between ASes within a SP.
It is worth noting that such a policy control mechanism may also be used between ASes within a 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.
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.
5.2.2.1. Inter-AS TE Agreement Enforcement Polices
5.2.2.1. Inter-AS TE Agreement Enforcement Polices
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:
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:
- 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 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
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.
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.
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.
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.
Zhang & Vasseur Informational [Page 23] RFC 4216 MPLS Inter-AS TE Requirements November 2005
Zhang & Vasseur Informational [Page 23] RFC 4216 MPLS Inter-AS TE Requirements November 2005
5.2.2.2. Inter-AS TE Rewrite Policies
5.2.2.2. Inter-AS TE Rewrite Policies
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:
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:
- RSVP-TE session attributes: affinities and preemption priorities
- DS-TE TE-Class <Class-Type, Preemption>
- ERO expansion requests
- RSVP-TE session attributes: affinities and preemption priorities - DS-TE TE-Class <Class-Type, Preemption> - ERO expansion requests
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.
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.
5.2.2.3. Inter-AS Traffic Policing
5.2.2.3. Inter-AS Traffic Policing
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.
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.
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.
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.
6. Security Considerations
6. Security Considerations
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.
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.
7. Acknowledgements
7. Acknowledgements
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.
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.
Zhang & Vasseur Informational [Page 24] RFC 4216 MPLS Inter-AS TE Requirements November 2005
Zhang & Vasseur Informational [Page 24] RFC 4216 MPLS Inter-AS TE Requirements November 2005
8. Normative References
8. Normative References
[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., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[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., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
9. Informative References
9. Informative References
[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC
3031, January 2001.
[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[BGP-MPLSVPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP VPNs", Work in
Progress, October 2004.
[BGP-MPLSVPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP VPNs", Work in Progress, October 2004.
[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., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[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., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[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., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[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., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[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., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.
[PSTE] Li, T. and Y. Rekhter, "A Provider Architecture for
Differentiated Services and Traffic Engineering
(PASTE)", RFC 2430, October 1998.
[PSTE] Li, T. and Y. Rekhter, "A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC 2430, October 1998.
Zhang & Vasseur Informational [Page 25] RFC 4216 MPLS Inter-AS TE Requirements November 2005
Zhang & Vasseur Informational [Page 25] RFC 4216 MPLS Inter-AS TE Requirements November 2005
[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., and W. Lai, "Applicability Statement for Traffic Engineering with MPLS", RFC 3346, August 2002.
[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., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[LSPPING] Kompella, K. and G. Swallow, "Detecting MPLS Data
Plane Failures", Work in Progress, May 2005.
[LSPPING] Kompella, K. and G. Swallow, "Detecting MPLS Data Plane Failures", Work in Progress, May 2005.
[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. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[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. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[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. and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[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. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, September 2005.
[MPLS-Recov] Sharma, V. and F. Hellstrand, "Framework for Multi-
Protocol Label Switching (MPLS)-based Recovery", RFC
3469, February 2003.
[MPLS-Recov] Sharma, V. and F. Hellstrand, "Framework for Multi- Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.
[EXCLUDE-ROUTE] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude
Routes - Extension to RSVP-TE", Work in Progress,
August 2005.
[EXCLUDE-ROUTE] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to RSVP-TE", Work in Progress, August 2005.
[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., and J. Ash, "Path Computation Element (PCE) Architecture", Work in Progress, September 2005.
[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) communication Protocol (PCEP) - Version 1", Work in Progress, September 2005.
Zhang & Vasseur Informational [Page 26] RFC 4216 MPLS Inter-AS TE Requirements November 2005
Zhang & Vasseur Informational [Page 26] RFC 4216 MPLS Inter-AS TE Requirements November 2005
Appendix A. Brief Description of BGP-based Inter-AS Traffic
Engineering
Appendix A. Brief Description of BGP-based Inter-AS Traffic Engineering
In today's Service Provider (SP) network, BGP is deployed to meet two different sets of requirements:
In today's Service Provider (SP) network, BGP is deployed to meet two different sets of requirements:
- 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
- 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
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:
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:
- "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.
- "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.
SPs have often faced a number of nondeterministic factors in the practices of inter-AS traffic engineering employing the methods mentioned above:
SPs have often faced a number of nondeterministic factors in the practices of inter-AS traffic engineering employing the methods mentioned above:
- 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.)
- 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.)
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.
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.
Zhang & Vasseur Informational [Page 27] RFC 4216 MPLS Inter-AS TE Requirements November 2005
Zhang & Vasseur Informational [Page 27] RFC 4216 MPLS Inter-AS TE Requirements November 2005
Editors' Addresses
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
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
EMail: jpv@cisco.com
Zhang & Vasseur Informational [Page 28] RFC 4216 MPLS Inter-AS TE Requirements November 2005
Zhang & Vasseur Informational [Page 28] RFC 4216 MPLS Inter-AS TE Requirements November 2005
Full Copyright Statement
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Zhang & Vasseur Informational [Page 29]
Zhang & Vasseur Informational [Page 29]
一覧
スポンサーリンク
