RFC4105 日本語訳
4105 Requirements for Inter-Area MPLS Traffic Engineering. J.-L. LeRoux, Ed., J.-P. Vasseur, Ed., J. Boyle, Ed.. June 2005. (Format: TXT=50111 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J.-L. Le Roux, Ed.
Request for Comments: 4105 France Telecom
Category: Informational J.-P. Vasseur, Ed.
Cisco Systems, Inc.
J. Boyle, Ed.
PDNETs
June 2005
ワーキンググループJ.-Lをネットワークでつないでください。 エドル・ルー、コメントを求める要求: 4105年のフランス電子通信カテゴリ: 情報のJ.-P。 エドエドVasseur、シスコシステムズのInc.J.ボイル、PDNETs2005年6月
Requirements for Inter-Area MPLS Traffic Engineering
相互領域MPLS交通工学のための要件
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 lists a detailed set of functional requirements for the support of inter-area MPLS Traffic Engineering (inter-area MPLS TE). It is intended that solutions that specify procedures and protocol extensions for inter-area MPLS TE satisfy these requirements.
このドキュメントは相互領域MPLS Traffic Engineering(相互領域MPLS TE)のサポートのための詳細な機能条件書をリストアップします。 相互領域MPLS TEに手順とプロトコル拡大を指定する解決策がこれらの要件を満たすことを意図します。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Terminology .....................................................3
4. Current Intra-Area Uses of MPLS Traffic Engineering .............4
4.1. Intra-Area MPLS Traffic Engineering Architecture ...........4
4.2. Intra-Area MPLS Traffic Engineering Applications ...........4
4.2.1. Intra-Area Resource Optimization ....................4
4.2.2. Intra-Area QoS Guarantees ...........................5
4.2.3. Fast Recovery within an IGP Area ....................5
4.3. Intra-Area MPLS TE and Routing .............................6
5. Problem Statement, Requirements, and Objectives of Inter-Area ...6
5.1. Inter-Area Traffic Engineering Problem Statement ...........6
5.2. Overview of Requirements for Inter-Area MPLS TE ............7
5.3. Key Objectives for an Inter-Area MPLS-TE Solution ..........8
5.3.1. Preserving the IGP Hierarchy Concept ................8
5.3.2. Preserving Scalability ..............................8
6. Application Scenario.............................................9
1. 序論…2 2. このドキュメントで中古のコンベンション…3 3. 用語…3 4. MPLS交通工学の現在のイントラ領域用途…4 4.1. イントラ領域MPLS交通工学構造…4 4.2. イントラ領域MPLS交通工学アプリケーション…4 4.2.1. イントラ領域リソース最適化…4 4.2.2. イントラ領域QoS保証…5 4.2.3. IGP領域の中の速い回復…5 4.3. イントラ領域MPLS Teとルート設定…6 5. 相互領域の問題声明、要件、および目的…6 5.1. 相互領域交通工学問題声明…6 5.2. 相互領域MPLS Teのための要件の概観…7 5.3. 相互領域MPLS-Teソリューションのためのキー目的…8 5.3.1. IGP階層構造概念を保存します…8 5.3.2. スケーラビリティを保存します…8 6. アプリケーションシナリオ…9
Le Roux, et al. Informational [Page 1] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [1ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
7. Detailed Requirements for Inter-Area MPLS TE ...................10
7.1. Inter-Area MPLS TE Operations and Interoperability ........10
7.2. Inter-Area TE-LSP Signaling ...............................10
7.3. Path Optimality ...........................................11
7.4. Inter-Area MPLS-TE Routing ................................11
7.5. Inter-Area MPLS-TE Path Computation .......................12
7.6. Inter-Area Crankback Routing ..............................12
7.7. Support of Diversely-Routed Inter-Area TE LSPs ............13
7.8. Intra/Inter-Area Path Selection Policy ....................13
7.9. Reoptimization of Inter-Area TE LSP .......................13
7.10. Inter-Area LSP Recovery ..................................14
7.10.1. Rerouting of Inter-Area TE LSPs ..................14
7.10.2. Fast Recovery of Inter-Area TE LSP ...............14
7.11. DS-TE support ............................................15
7.12. Hierarchical LSP Support .................................15
7.13. Hard/Soft Preemption .....................................15
7.14. Auto-Discovery of TE Meshes ..............................16
7.15. Inter-Area MPLS TE Fault Management Requirements .........16
7.16. Inter-Area MPLS TE and Routing ...........................16
8. Evaluation criteria ............................................17
8.1. Performances ..............................................17
8.2. Complexity and Risks ......................................17
8.3. Backward Compatibility ....................................17
9. Security Considerations ........................................17
10. Acknowledgements ..............................................17
11. Contributing Authors ..........................................18
12. Normative References ..........................................19
13. Informative References ........................................19
7. 相互領域MPLS Teのための要件を詳しく述べます…10 7.1. 相互領域MPLS Te操作と相互運用性…10 7.2. 相互領域Te-LSPシグナリング…10 7.3. 経路の最適…11 7.4. 相互領域MPLS-Teルート設定…11 7.5. 相互領域MPLS-Te経路計算…12 7.6. 相互領域Crankbackルート設定…12 7.7. さまざまに発送された相互領域Te LSPsのサポート…13 7.8. 相互イントラ/領域経路選択方針…13 7.9. 相互領域Te LSPのReoptimization…13 7.10. 相互領域LSP回復…14 7.10.1. 相互領域Te LSPsのコースを変更します…14 7.10.2. 相互領域Te LSPの速い回復…14 7.11. DS-TEサポート…15 7.12. 階層的なLSPサポート…15 7.13. 困難であるか柔らかい先取り…15 7.14. Teの自動発見はかみ合います…16 7.15. 相互領域MPLS Te障害管理要件…16 7.16. 相互領域MPLS Teとルート設定…16 8. 評価基準…17 8.1. パフォーマンス…17 8.2. 複雑さとリスク…17 8.3. 後方の互換性…17 9. セキュリティ問題…17 10. 承認…17 11. 作者を寄付します…18 12. 標準の参照…19 13. 有益な参照…19
1. Introduction
1. 序論
The set of MPLS Traffic Engineering components, defined in [RSVP-TE], [OSPF-TE], and [ISIS-TE], which supports the requirements defined in [TE-REQ], is used today by many network operators to achieve major Traffic Engineering objectives defined in [TE-OVW]. These objectives include:
MPLS Traffic Engineeringの部品のセット、[RSVP-TE]で定義されています、[OSPF-TE]、および[イシス-TE]([TE-REQ]で定義された要件を支持する)は、今日、[TE-OVW]で定義された主要なTraffic Engineering目的を達成するのに多くのネットワーク・オペレータによって使用されます。 これらの目的は:
- Aggregated Traffic measurement
- Optimization of network resources utilization
- Support for services requiring end-to-end QoS guarantees
- Fast recovery against link/node/Shared Risk Link Group (SRLG)
failures
- 集められたTraffic測定--ネットワーク資源利用の最適化--終わりから終わりへのQoS保証を必要とするサービスのサポート--リンク/ノード/共有されたRisk Link Group(SRLG)の故障に対する速い回復
Furthermore, the applicability of MPLS to traffic engineering in IP networks is discussed in [TE-APP].
その上、[TE-APP]でIPネットワークにおける交通工学へのMPLSの適用性について議論します。
The set of MPLS Traffic Engineering mechanisms, to date, has been limited to use within a single Interior Gateway Protocol (IGP) area.
MPLS Traffic Engineeringメカニズムのこれまでであるセットは、ただ一つのInteriorゲートウェイプロトコル(IGP)の中で領域を使用するために制限されました。
Le Roux, et al. Informational [Page 2] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [2ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
This document discusses the requirements for an inter-area MPLS Traffic Engineering mechanism that may be used to achieve the same set of objectives across multiple IGP areas.
このドキュメントは複数のIGP領域の向こう側に同じセットの目的を達成するのに使用されるかもしれない相互領域MPLS Traffic Engineeringメカニズムのための要件について議論します。
Basically, it would be useful to extend MPLS TE capabilities across IGP areas to support inter-area resources optimization, to provide strict QoS guarantees between two edge routers located within distinct areas, and to protect inter-area traffic against Area Border Router (ABR) failures.
基本的に、相互領域リソース最適化を支持して、異なった領域の中に位置した2つの縁のルータの間に厳しいQoS保証を提供して、Area Border Router(ABR)の故障に対して相互領域交通を保護するIGP領域中のMPLS TE能力を広げるのは役に立つでしょう。
First, this document addresses current uses of MPLS Traffic Engineering within a single IGP area. Then, it discusses a set of functional requirements that a solution must or should satisfy in order to support inter-area MPLS Traffic Engineering. Because the scope of requirements will vary between operators, some requirements will be mandatory (MUST), whereas others will be optional (SHOULD). Finally, a set of evaluation criteria for any solution meeting these requirements is given.
まず最初に、このドキュメントはただ一つのIGP領域の中にMPLS Traffic Engineeringの現在の用途を記述します。 そして、それは解決策に相互領域MPLS Traffic Engineeringを支持するために満足させるべきでなければならないか、または満足させられるべきであるという1セットの機能条件書について議論します。 要件の範囲がオペレータの間で異なるので、いくつかの要件が義務的な(MUST)になるでしょうが、他のものは任意でしょう(SHOULD)。 最終的に、これらの必要条件を満たすどんな解決策のための1セットの評価基準も与えます。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Terminology
3. 用語
LSR: Label Switching Router
LSR: ラベル切り換えルータ
LSP: Label Switched Path
LSP: ラベルは経路を切り換えました。
TE LSP: Traffic Engineering Label Switched Path
Te LSP: 交通工学のラベルの切り換えられた経路
Inter-area TE LSP: TE LSP whose head-end LSR and tail-end LSR do not
reside within the same IGP area or whose head-end
LSR and tail-end LSR are both in the same IGP area
although the TE-LSP transiting path is across
different IGP areas.
相互領域Te LSP: TE-LSPトランジット経路が異なったIGP領域のむこうにありますが、LSRがギヤエンドLSRと末端をするTE LSPは同じIGP領域かそれともLSRと末端LSRがギヤエンドに同じIGP領域への両方であるかの中に住んでいません。
IGP area: OSPF area or IS-IS level.
IGP領域: または、OSPF領域、-、レベル。
ABR: Area Border Router, a router used to connect two
IGP areas (ABR in OSPF, or L1/L2 router in IS-IS).
ABR: 領域Border Router、2つのIGP領域をつなげるのに使用されるルータ、(OSPFのABR、または中のL1/L2ルータ、-、)
CSPF: Constraint-based Shortest Path First.
CSPF: 最短パス規制ベースの1番目。
SRLG: Shared Risk Link Group.
SRLG: 共有されたリスクリンク群。
Le Roux, et al. Informational [Page 3] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [3ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
4. Current Intra-Area Uses of MPLS Traffic Engineering
4. MPLS交通工学の現在のイントラ領域用途
This section addresses architecture, capabilities, and uses of MPLS TE within a single IGP area. It first summarizes the current MPLS-TE architecture, then addresses various MPLS-TE capabilities, and finally lists various approaches to integrate MPLS TE into routing. This section is intended to help define the requirements for MPLS-TE extensions across multiple IGP areas.
このセクションはただ一つのIGP領域の中にMPLS TEの構造、能力、および用途を記述します。 それは、最初に現在のMPLS-TE建築をまとめて、次に、様々なMPLS-TE能力を記述して、MPLS TEをルーティングと統合するために最終的に様々なアプローチを記載します。 このセクションが、複数のIGP領域の向こう側にMPLS-TE拡張子のための要件を定義するのを助けることを意図します。
4.1. Intra-Area MPLS Traffic Engineering Architecture
4.1. イントラ領域MPLS交通工学構造
The MPLS-TE control plane allows establishing explicitly routed MPLS LSPs whose paths follow a set of TE constraints. It is used to achieve major TE objectives such as resource usage optimization, QoS guarantee and fast failure recovery. It consists of three main components:
MPLS-TE制御飛行機で、経路が1セットのTE規制に続く明らかに発送されたMPLS LSPsを設立します。 それは、リソース用法最適化や、QoS保証や速い失敗回復などの主要なTE目的を達成するのに使用されます。 それは3つの主なコンポーネントから成ります:
- The routing component, responsible for the discovery of the TE
topology. This is ensured thanks to extensions of link state IGP:
[ISIS-TE], [OSPF-TE].
- The path computation component, responsible for the placement of
the LSP. It is performed on the head-end LSR thanks to a CSPF
algorithm, which takes TE topology and LSP constraints as input.
- The signaling component, responsible for the establishment of the
LSP (explicit routing, label distribution, and resources
reservation) along the computed path. This is ensured thanks to
RSVP-TE [RSVP-TE].
- TEトポロジーの発見に原因となるルーティングコンポーネント。 これはリンク州のIGPの拡大のおかげで確実にされます: [イシス-Te]、[OSPF-Te。] - LSPのプレースメントに原因となる経路計算コンポーネント。 それはCSPFアルゴリズムのおかげでギヤエンドLSRで実行されます。アルゴリズムは入力されるようにTEトポロジーとLSP規制を取ります。 - 計算された経路に沿ってLSP(明白なルーティング、ラベル分配、およびリソースの予約)の設立に原因となるシグナリングコンポーネント。 これはRSVP-TE[RSVP-TE]のおかげで確実にされます。
4.2. Intra-Area MPLS Traffic Engineering Applications
4.2. イントラ領域MPLS交通工学アプリケーション
4.2.1. Intra-Area Resource Optimization
4.2.1. イントラ領域リソース最適化
MPLS TE can be used within an area to redirect paths of aggregated flows away from over-utilized resources within a network. In a small scale, this may be done by explicitly configuring a path to be used between two routers. On a grander scale, a mesh of LSPs can be established between central points in a network. LSPs paths can be defined statically in configuration or arrived at by an algorithm that determines the shortest path given administrative constraints such as bandwidth. In this way, MPLS TE allows for greater control over how traffic demands are routed over a network topology and utilize a network's resources.
ネットワークの中で利用され過ぎるリソースから集められた流れの経路遠くで向け直す領域の中でMPLS TEを使用できます。 小規模では、2つのルータの間で使用されるために明らかに経路を構成することによって、これをするかもしれません。 より壮大なスケールでは、主要なポイントの間にLSPsのメッシュをネットワークに設立できます。 帯域幅などの管理規制を考えて、最短パスを決定するアルゴリズムで、LSPs経路に構成で静的に定義されるか、または達することができます。 このように、MPLS TEは交通需要がどうネットワーク形態の上に発送されて、ネットワークのリソースを利用するかの、より大きいコントロールを考慮します。
Note also that TE LSPs allow measuring traffic matrix in a simple and scalable manner. The aggregated traffic rate between two LSRs is easily measured by accounting of traffic sent onto a TE LSP provisioned between the two LSRs in question.
また、TE LSPsが簡単でスケーラブルな方法で交通マトリクスを測定させることに注意してください。 2LSRsの間の集められた交通率は問題の2LSRsの間で食糧を供給されたTE LSPに送られた交通の会計で容易に測定されます。
Le Roux, et al. Informational [Page 4] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [4ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
4.2.2. Intra-Area QoS Guarantees
4.2.2. イントラ領域QoS保証
The DiffServ IETF working group has defined a set of mechanisms described in [DIFF-ARCH], [DIFF-AF], and [DIFF-EF] or [MPLS-DIFF], that can be activated at the edge of or over a DiffServ domain to contribute to the enforcement of a QoS policy (or set of policies), which can be expressed in terms of maximum one-way transit delay, inter-packet delay variation, loss rate, etc. Many Operators have some or full deployment of DiffServ implementations in their networks today, either across the entire network or at least at its edge.
DiffServ IETFワーキンググループは最大の片道トランジット遅れ、相互パケット遅れ変化、損失率などで言い表すことができるQoS方針(または、方針のセット)の実施に貢献するためにドメインかDiffServドメインの上の縁で動かすことができる[DIFF-ARCH]か、[DIFF-AF]と、[DIFF-EF]か[MPLS-DIFF]で説明された1セットのメカニズムを定義しました。 多くのOperatorsには、いくつかか今日の全体のネットワークか少なくともその縁のそれらのネットワークにおける、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. 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.
いくつかの場合、厳しいQoS領域が必要である状況で、現在のDiffServメカニズムに加えてネットワークの背骨における入場コントロールが必要です。最大の片道トランジット遅れなどのように、達成目標は、いつ、伝播遅延があることができるかがバウンドしたのがDiffServによって可能にされた経路に沿って帯域幅保証を提供することによって、保証されるかもしれません。
MPLS TE can be simply used with DiffServ: in that case, it only ensures aggregate QoS guarantees for the whole traffic. It can also be more intimately combined with DiffServ to perform per-class of service admission control and resource reservation. This requires extensions to MPLS TE called DiffServ-Aware TE, which are defined in [DSTE-PROTO]. DS-TE allows ensuring strict end-to-end QoS guarantees. For instance, an EF DS-TE LSP may be provisioned between voice gateways within the same area to ensure strict QoS to VoIP traffic.
DiffServと共にMPLS TEを単に使用できます: その場合、それは全体の交通のための集合QoS保証を確実にするだけです。 また、サービス入場コントロールと資源予約のクラスを実行するために、より親密にそれをDiffServに結合できます。 これは[DSTE-プロト]で定義されるDiffServ意識しているTEと呼ばれるMPLS TEに拡大を必要とします。 DS-TEは終わりから終わりへのQoS厳しい保証を確実にさせます。 例えば、EF DS-TE LSPは、VoIP交通に厳しいQoSを確実にするために同じ領域の中の声のゲートウェイの間で食糧を供給されるかもしれません。
MPLS TE allows computing intra-area shortest paths, which satisfy various constraints, including bandwidth. For the sake of illustration, if the IGP metrics reflects the propagation delay, it allows finding a minimum propagation delay path, which satisfies various constraints, such as bandwidth.
MPLS TEはイントラ領域最短パスを計算させます。(最短パスは帯域幅を含む様々な規制を満たします)。 イラストのために、IGP測定基準が伝播遅延を反映するなら、それで、最小の伝播遅れ経路を見つけます、帯域幅などのように。(経路は様々な規制を満たします)。
4.2.3. Fast Recovery within an IGP Area
4.2.3. IGP領域の中の速い回復
As quality-sensitive applications are deployed, one of the key requirements is to provide fast recovery mechanisms, allowing traffic recovery to be guaranteed on the order of tens of msecs, in case of network element failure. Note that this cannot be achieved by relying only on classical IGP rerouting.
品質敏感なアプリケーションが配備されるとき、主要な要件の1つは速い回収機構を提供することです、交通回復が何十msecもの注文ときに保証されるのを許容して、ネットワーク要素の故障の場合に。 単に古典的なIGPのコースを変更することを当てにすることによってこれを達成できないことに注意してください。
Various recovery mechanisms can be used to protect traffic carried onto TE LSPs. They are defined in [MPLS-RECOV]. Protection mechanisms are based on the provisioning of backup LSPs that are used to recover traffic in case of failure of protected LSPs. Among those protection mechanisms, local protection (also called Fast Reroute) is intended to achieve sub-50ms recovery in case of link/node/SRLG
TE LSPsまで運ばれた交通を保護するのに様々な回収機構を使用できます。 それらは[MPLS-RECOV]で定義されます。 保護メカニズムは保護されたLSPsの失敗の場合に交通を回復するのに使用されるバックアップLSPsの食糧を供給するのに基づいています。 それらの保護メカニズムの中では、地方の保護(また、Fast Rerouteと呼ばれる)がリンク/ノード/SRLGの場合にsub-50ms回復を達成することを意図します。
Le Roux, et al. Informational [Page 5] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [5ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
failure along the LSP path [FAST-REROUTE]. Fast Reroute is currently used by many operators to protect sensitive traffic inside an IGP area.
LSP経路[FAST-REROUTE]に沿った失敗。 速く、Rerouteは、現在、IGP領域の中に敏感な交通を保護するのに多くのオペレータによって使用されます。
[FAST-REROUTE] defines two modes for backup LSPs. The first, called one-to-one backup, consists of setting up one detour LSP per protected LSP and per element to protect. The second, called facility backup, consists of setting up one or several bypass LSPs to protect a given facility (link or node). In case of failure, all protected LSPs are nested into the bypass LSPs (benefiting from the MPLS label stacking property).
[FAST-REROUTE]はバックアップLSPsのために2つのモードを定義します。 1〜1つのバックアップと呼ばれる1番目は保護するために保護されたLSPと要素あたり1回り道LSPをセットアップするのから成ります。 施設バックアップと呼ばれる2番目は与えられた施設(リンクかノード)を保護するために1か数個の迂回LSPsをセットアップするのから成ります。 失敗の場合には、すべての保護されたLSPsが迂回LSPsに入れ子にされます(MPLSラベル積み重ねの特性の利益を得て)。
4.3. Intra-Area MPLS TE and Routing
4.3. イントラ領域MPLS Teとルート設定
There are several possibilities for directing traffic into intra-area TE LSPs:
イントラ領域TE LSPsに交通整理するためのいくつかの可能性があります:
1) Static routing to the LSP destination address or any other
addresses.
2) IGP routes beyond the LSP destination, from an IGP SPF perspective
(IGP shortcuts).
3) BGP routes announced by a BGP peer (or an MP-BGP peer) that is
reachable through the TE LSP by means of a single static route to
the corresponding BGP next-hop address (option 1) or by means of
IGP shortcuts (option 2). This is often called BGP recursive
routing.
4) The LSP can be advertised as a link into the IGP to become part of
IGP database for all nodes, and thus can be taken into account
during SPF for all nodes. Note that, even if similar in concept,
this is different from the notion of Forwarding-Adjacency, as
defined in [LSP-HIER]. Forwarding-Adjacency is when the LSP is
advertised as a TE-link into the IGP-TE to become part of the TE
database and taken into account in CSPF.
1) LSP送付先アドレスかいかなる他のアドレスへのスタティックルーティング。 2) IGP SPF見解からのLSPの目的地(IGP近道)を超えたIGPルート。 3) 対応するBGP次のホップアドレス(オプション1)かIGP近道(オプション2)によるただ一つのスタティックルートによるTE LSPを通して届いているBGP同輩(または、MP-BGP同輩)でBGPルートは発表しました。 これはしばしばBGPの再帰的なルーティングと呼ばれます。 4) LSPはすべてのノードのためのIGPデータベースの一部になるようにリンクとしてIGPに広告を出すことができて、その結果、すべてのノードのためにSPFの間、考慮に入れることができます。 [LSP-HIER]で定義されるように概念において同様であってもこれがForwarding-隣接番組の概念と異なっていることに注意してください。 推進隣接番組はLSPがTEデータベースの一部になるようにTE-リンクとしてIGP-TEに広告を出して、CSPFで考慮に入れられる時です。
5. Problem Statement, Requirements, and Objectives of Inter-Area
MPLS TE
5. 相互領域MPLS Teの問題声明、要件、および目的
5.1. Inter-Area Traffic Engineering Problem Statement
5.1. 相互領域交通工学問題声明
As described in Section 4, MPLS TE is deployed today by many operators to optimize network bandwidth usage, to provide strict QoS guarantees, and to ensure sub-50ms recovery in case of link/node/SRLG failure.
セクション4で説明されるように、MPLS TEは今日、ネットワーク回線容量用法を最適化して、厳しいQoS保証を提供して、リンク/ノード/SRLGの故障の場合にsub-50ms回復を確実にするために多くのオペレータによって配備されます。
However, MPLS-TE mechanisms are currently limited to a single IGP area. The limitation comes more from the Routing and Path computation components than from the signaling component. This is basically because the hierarchy limits topology visibility of head-
しかしながら、MPLS-TEメカニズムは現在、ただ一つのIGP領域に制限されます。 制限はシグナリングコンポーネントよりルート設定とPath計算の部品から来ます。 これは階層構造がヘッドのトポロジー目に見えることを制限するから基本的にです
Le Roux, et al. Informational [Page 6] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [6ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
end LSRs to their IGP area, and consequently head-end LSRs can no longer run a CSPF algorithm to compute the shortest constrained path to the tail-end, as CSPF requires the whole topology to compute an end-to-end shortest constrained path.
彼らのIGP領域へのLSRsを終わらせてください。そうすれば、その結果、ギヤエンドLSRsは最も短い強制的な経路を末端まで計算するためにもうCSPFアルゴリズムを走らせることができません、CSPFが終わりから端への最も短い強制的な経路を計算するために全体のトポロジーを必要とするとき。
Several operators have multi-area networks, and many operators that are still using a single IGP area may have to migrate to a multi-area environment, as their network grows and single area scalability limits are approached.
数人のオペレータには、マルチ領域ネットワークがあります、そして、まだただ一つのIGP領域を使用している多くのオペレータがマルチ領域環境にわたらなければならないかもしれません、彼らのネットワークが成長して、ただ一つの領域のスケーラビリティ限界がアプローチされるとき。
Thus, those operators may require inter-area traffic engineering to:
したがって、それらのオペレータが、以下のことが相互領域交通工学は必要であるかもしれません。
- Perform inter-area resource optimization.
- Provide inter-area QoS guarantees for traffic between edge nodes
located in different areas.
- Provide fast recovery across areas, to protect inter-area traffic
in case of link or node failure, including ABR node failures.
- 相互領域リソース最適化を実行してください。 - QoSが異なった領域に位置する縁のノードの間の交通に保証する相互領域を提供してください。 - リンクかノード障害の場合に相互領域交通を保護するためにABRノード障害を含む領域の向こう側に速い回復を供給してください。
For instance, an operator running a multi-area IGP may have voice gateways located in different areas. Such VoIP transport requires inter-area QoS guarantees and inter-area fast protection.
例えば、マルチ領域IGPを走らせているオペレータは異なった領域に声のゲートウェイを位置させているかもしれません。 そのようなVoIP輸送は相互領域QoS保証と相互領域の速い保護を必要とします。
One possible approach for inter-area traffic engineering could consist of deploying MPLS TE on a per-area basis, but such an approach has several limitations:
相互領域交通工学のための1つの可能なアプローチが地域制でMPLS TEを配備するのから成ることができましたが、そのようなアプローチには、いくつかの制限があります:
- Traffic aggregation at the ABR levels implies some constraints that
do not lead to efficient traffic engineering. Actually, this per-
area TE approach might lead to sub-optimal resource utilization, by
optimizing resources independently in each area. What many
operators want is to optimize their resources as a whole; in other
words, as if there was only one area (flat network).
- This does not allow computing an inter-area constrained shortest
path and thus does not ensure end-to-end QoS guarantees across
areas.
- Inter-area traffic cannot be protected with local protection
mechanisms such as [FAST-REROUTE] in case of ABR failure.
- ABRレベルにおける交通集合は効率的な交通工学につながらないいくつかの規制を含意します。 実際にこれ、-、領域TEアプローチは、各領域で独自にリソースを最適化することによって、サブ最適のリソース利用につながるかもしれません。 多くのオペレータが欲しいものは全体で彼らのリソースを最適化することになっています。 まるで言い換えれば、1つの領域(平坦なネットワーク)しかないかのように。 - これは、相互領域の強制的な最短パスを計算するのを許容しないで、またその結果、領域の向こう側に終わりから終わりへのQoS保証を確実にしません。 - ABRの故障の場合の[FAST-REROUTE]などのローカルの保護メカニズムで相互領域交通を保護できません。
Therefore, existing MPLS TE mechanisms have to be enhanced to support inter-area TE LSPs.
したがって、既存のMPLS TEメカニズムは、相互領域TE LSPsを支持するために高められなければなりません。
5.2. Overview of Requirements for Inter-Area MPLS TE
5.2. 相互領域MPLS Teのための要件の概観
For the reasons mentioned above, it is highly desired to extend the current set of MPLS-TE mechanisms across multiple IGP areas in order to support the intra-area applications described in Section 4 across areas.
前記のように理由で、領域の向こう側にセクション4で説明されたイントラ領域アプリケーションを支持するために複数のIGP領域の向こう側に現在のセットのMPLS-TEメカニズムを広げることが非常に望まれています。
Le Roux, et al. Informational [Page 7] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [7ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
The solution MUST allow setting up inter-area TE LSPs; i.e., LSPs whose path crosses at least two IGP areas.
解決策で、相互領域TE LSPsをセットアップしなければなりません。 すなわち、経路が少なくとも2つのIGP領域に交差するLSPs。
Inter-area MPLS-TE extensions are highly desired in order to provide:
相互領域MPLS-TE拡張子は提供するために非常に望まれています:
- Inter-area resources optimization.
- Strict inter-area QoS guarantees.
- Fast recovery across areas, particularly to protect inter-area
traffic against ABR failures.
- 相互領域リソース最適化。 - 厳しい相互領域QoS保証。 - 速い回復、領域の向こう側に、特に相互領域を保護するために、ABRの故障に対して取引してください。
It may be desired to compute inter-area shortest paths that satisfy some bandwidth constraints or any other constraints, as is currently possible within a single IGP area. For the sake of illustration, if the IGP metrics reflects the propagation delay, it may be necessary to be able to find the optimal (shortest) path satisfying some constraints (e.g., bandwidth) across multiple IGP areas. Such a path would be the inter-area path offering the minimal propagation delay.
現在ただ一つのIGP領域の中で可能な状態でいくつかの帯域幅規制かそのままないかなる他の規制も満たす相互領域最短パスを計算するのは必要であるかもしれません。 イラストのために、IGP測定基準が伝播遅延を反映するなら、複数のIGP領域の向こう側に最適(最も短い)の経路の満足させるのがいくつかの規制(例えば、帯域幅)であることがわかることができるのが必要であるかもしれません。 そのような経路は最小量の伝播遅延を提供する相互領域経路でしょう。
Thus, the solution SHOULD provide the ability to compute inter-area shortest paths satisfying a set of constraints (i.e., bandwidth).
したがって、解決策SHOULDは1セットの規制(すなわち、帯域幅)を満たす相互領域最短パスを計算する能力を提供します。
5.3. Key Objectives for an Inter-Area MPLS-TE Solution
5.3. 相互領域MPLS-Teソリューションのための主要目的
Any solution for inter-area MPLS TE should be designed with preserving IGP hierarchy concept, and preserving routing and signaling scalability as key objectives.
相互領域MPLS TEのどんな解決策もIGP階層構造概念を保存して、主要目的としてルーティングとシグナリングスケーラビリティを保存するのに設計されるべきです。
5.3.1. Preserving the IGP Hierarchy Concept
5.3.1. IGP階層構造概念を保存します。
The absence of a full link-state topology database makes the computation of an end-to-end optimal path by the head-end LSR not possible without further signaling and routing extensions. There are several reasons that network operators choose to break up their network into different areas. These often include scalability and containment of routing information. The latter can help isolate most of a network from receiving and processing updates that are of no consequence to its routing decisions. Containment of routing information MUST not be compromised to allow inter-area traffic engineering. Information propagation for path-selection MUST continue to be localized. In other words, the solution MUST entirely preserve the concept of IGP hierarchy.
完全なリンク州のトポロジーデータベースの欠如はさらに合図しないで可能でないギヤエンドLSRとルーティング拡大による終わりから端への最適経路の計算をします。 ネットワーク・オペレータが、異なった領域に彼らのネットワークを壊れさせるのを選ぶいくつかの理由があります。 これらはしばしばルーティング情報のスケーラビリティと封じ込めを含んでいます。 後者は、結果の全くものでない受信と処理アップデートからルーティング決定までネットワークの大部分を隔離するのを助けることができます。 ルーティング情報の封じ込めは、相互領域交通工学を許容するために妥協してはいけません。 経路選択のための情報伝播は、局所化され続けなければなりません。 言い換えれば、解決策はIGP階層構造の概念を完全に保存しなければなりません。
5.3.2. Preserving Scalability
5.3.2. スケーラビリティを保存します。
Achieving the requirements listed in this document MUST be performed while preserving the IGP scalability, which is of the utmost importance. The hierarchy preservation objective addressed in the above section is actually an element to preserve IGP scalability.
IGPスケーラビリティ(最重要性のものである)を保存している間、本書ではリストアップされた要件を達成するのを実行しなければなりません。 上のセクションで記述された階層構造保存目的は実際にIGPスケーラビリティを保存する要素です。
Le Roux, et al. Informational [Page 8] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [8ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
The solution also MUST not increase IGP load unreasonably, which could compromise IGP scalability. In particular, a solution satisfying those requirements MUST not require the IGP to carry some unreasonable amount of extra information and MUST not unreasonably increase the IGP flooding frequency.
解決策もIGP荷重を無分別に増加させてはいけません(IGPスケーラビリティで妥協できました)。 それらの要件を満たす解決策は、特に、IGPがいくらかの無理な量のその他の情報を運ぶのが必要であってはいけなく、IGP氾濫頻度を無分別に増加させてはいけません。
Likewise, the solution MUST also preserve scalability of RSVP-TE ([RSVP-TE]).
また、同様に、解決策はRSVP-TE([RSVP-TE])のスケーラビリティを保存しなければなりません。
Additionally, the base specification of MPLS TE is architecturally structured and relatively devoid of excessive state propagation in terms of routing or signaling. Its strength in extensibility can also be seen as an Achilles heel, as there is no real limit to what is possible with extensions. It is paramount to maintain architectural vision and discretion when adapting it for use for inter-area MPLS TE. Additional information carried within an area or propagated outside of an area (via routing or signaling) should be neither excessive, patchwork, nor non-relevant.
さらに、MPLS TEの基礎仕様は、建築上、構造化されていて過度の州の伝播に比較的ルーティングかシグナリングに欠けています。 また、伸展性における強さを弁慶の泣き所と考えることができます、拡大で可能なことへのどんな本当の限界もないとき。 相互領域MPLS TEの使用のためにそれを適合させるとき、建築ビジョンと思慮深さを維持するのは最高のです。 追加情報は領域の中で運ばれるべきではありませんでしたか、伝播されて、過度のどちらも領域(ルーティングかシグナリングを通した)の外にあるべきではありません、パッチワーク、または、非関連しています。
Particularly, as mentioned in Section 5.2, it may be desired for some inter-area TE LSP carrying highly sensitive traffic to compute a shortest inter-area path, satisfying a set of constraints such as bandwidth. This may require an additional routing mechanism, as base CSPF at head-end can no longer be used due to the lack of topology and resource information. Such a routing mechanism MUST not compromise the scalability of the overall system.
特に、非常に敏感な交通を運ぶいくらかの相互領域TE LSPのためにセクション5.2で言及されるように最も短い相互領域経路を計算することが望まれるかもしれません、1セットの帯域幅などの規制を満たして。 これは追加ルーティングメカニズムを必要とするかもしれません、トポロジーとリソース情報の不足のためもうギヤエンドのベースCSPFを使用できないとき。 そのようなルーティングメカニズムは総合体系のスケーラビリティで妥協してはいけません。
6. Application Scenario
6. アプリケーションシナリオ
---area1--------area0------area2--
------R1-ABR1-R2-------ABR3-------
| \ | / | |
| R0 \ | / | R4 |
| R5 \ |/ | |
---------ABR2----------ABR4-------
---area1--------area0------area2--------R1-ABR1-R2-------ABR3------- | \ | / | | | R0\| / | R4| | R5\|/ | | ---------ABR2----------ABR4-------
- ABR1, ABR2: Area0-Area1 ABRs
- ABR3, ABR4: Area0-Area2 ABRs
- ABR1、ABR2: Area0-Area1 ABRs--ABR3、ABR4: Area0-Area2 ABRs
- R0, R1, R5: LSRs in area 1
- R2: an LSR in area 0
- R4: an LSR in area 2
- R0、R1、R5: 領域1のLSRs--、R2: 領域0のLSR--、R4: 領域2のLSR
Although the terminology and examples provided in this document make use of the OSPF terminology, this document equally applies to IS-IS.
本書では提供された用語と例がOSPF用語を利用しますが、このドキュメントが、等しく利用する、-
Le Roux, et al. Informational [Page 9] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [9ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
Typically, an inter-area TE LSP will be set up between R0 and R4, where both LSRs belong to different IGP areas. Note that the solution MUST support the capability to protect such an inter-area TE LSP from the failure on any Link/SRLG/Node within any area and the failure of any traversed ABR. For instance, if the TE LSP R0->R4 goes through R1->ABR1->R2, then it can be protected against ABR1 failure, thanks to a backup LSP (detour or bypass) that may follow the alternate path R1->ABR2->R2.
通常、相互領域TE LSPはR0とR4の間でセットアップされるでしょう。そこでは、両方のLSRsが異なったIGP領域に属します。 解決策がどんな横断されたABRのどんな領域と失敗の中にもどんなLink/SRLG/ノードの上の失敗からそのような相互領域TE LSPを保護する能力を支持しなければならないことに注意してください。 ->R2、次に、ABR1の故障に対してそれを保護できます、代替パスR1に続くかもしれないバックアップLSP(迂回するか、または迂回する)に>ABR2->に感謝します。例えば、R4がTE LSP R0->であるならR1->を通る、ABR1、R2。
For instance, R0 and R4 may be two voice gateways located in distinct areas. An inter-area DS-TE LSP with class-type EF is set up from R1 to R4 to route VoIP traffic classified as EF. Per-class inter-area constraint-based routing allows the DS-TE LSP to be routed over a path that will ensure strict QoS guarantees for VoIP traffic.
例えば、R0とR4は異なった領域に位置する2声の門であるかもしれません。 クラスタイプEFと相互領域DS-TE LSPは、EFとして分類されたVoIP交通を発送するためにR1からR4までセットアップされます。 1クラスあたりの相互領域の規制ベースのルーティングは、DS-TE LSPが厳しいQoSがVoIPのために交通を保証するのを確実にする経路の上に発送されるのを許容します。
In another application, R0 and R4 may be two pseudo wire gateways residing in different areas. An inter-area LSP may be set up to carry pseudo wires.
別のアプリケーションでは、R0とR4は異なった領域に住んでいる2疑似ワイヤ門であるかもしれません。 相互領域LSPは、疑似ワイヤを運ぶためにセットアップされるかもしれません。
In some cases, it might also be possible to have an inter-area TE LSP from R0 to R5 transiting via the backbone area (or any other levels with IS-IS). There may be cases where there are no longer enough resources on any intra area path R0-to-R5, and where there is a feasible inter-area path through the backbone area.
または、また、いくつかの場合、R0から背骨領域を通って通過するR5まで相互領域TE LSPを持っているのも可能であるかもしれない、(いかなる他のも率直に話す、-、) ケースがどんなイントラ領域経路のR0からR5上までも背骨領域を通って可能な相互領域経路があるところにリソースがもう十分ないところにあるかもしれません。
7. Detailed Requirements for Inter-Area MPLS TE
7. 相互領域MPLS Teのための詳細な要件
7.1. Inter-Area MPLS TE Operations and Interoperability
7.1. 相互領域MPLS Te操作と相互運用性
The inter-area MPLS TE solution MUST be consistent with requirements discussed in [TE-REQ], and the derived solution MUST interoperate seamlessly with current intra-area MPLS TE mechanisms and inherit its capability sets from [RSVP-TE].
相互領域MPLS TE解決策が[TE-REQ]で議論する要件と一致しているに違いなくて、派生している解決策は、継ぎ目なく現在のイントラ領域MPLS TEメカニズムで共同利用して、[RSVP-TE]から能力セットを引き継がなければなりません。
The proposed solution MUST allow provisioning at the head-end with end-to-end RSVP signaling (potentially with loose paths) traversing across the interconnected ABRs, without further provisioning required along the transit path.
提案された解決策は、終わりから終わりへのRSVPが合図していてギヤエンドに食糧を供給するのを許容しなければなりません。(潜在的に、ゆるい経路) 横断が直径で、さらに食糧を供給することのないインタコネクトされたABRsがトランジット経路に沿って必要です。
7.2. Inter-Area TE-LSP Signaling
7.2. 相互領域Te-LSPシグナリング
The solution MUST allow for the signaling of inter-area TE LSPs, using RSVP-TE.
RSVP-TEを使用して、解決策は相互領域TE LSPsのシグナリングを考慮しなければなりません。
In addition to the signaling of classical TE constraints (bandwidth, admin-groups), the proposed solution MUST allow the head-end LSR to specify a set of LSRs explicitly, including ABRs, by means of strict or loose hops for the inter-area TE LSP.
古典的なTE規制(帯域幅、アドミングループ)のシグナリングに加えて、ギヤエンドLSRは提案された解決策で明らかにLSRsの1セットを指定できなければなりません、ABRsを含んでいて、相互領域TE LSPへの厳しいかゆるいホップによる。
Le Roux, et al. Informational [Page 10] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [10ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
In addition, the proposed solution SHOULD also provide the ability to specify and signal certain resources to be explicitly excluded in the inter-area TE-LSP path establishment.
また、さらに、提案された解決策SHOULDは相互領域TE-LSP経路設立で明らかに除かれるようにあるリソースに指定して、合図する能力を提供します。
7.3. Path Optimality
7.3. 経路の最適
In the context of this requirement document, an optimal path is defined as the shortest path across multiple areas, taking into account either the IGP or TE metric [METRIC]. In other words, such a path is the path that would have been computed by making use of some CSPF algorithm in the absence of multiple IGP areas.
この要件ドキュメントの文脈では、最適経路は複数の領域の向こう側に最短パスと定義されます、IGPかTEのメートル法の[METRIC]のどちらかを考慮に入れて。 言い換えれば、そのような経路は複数のIGP領域がないとき何らかのCSPFアルゴリズムを利用することによって計算された経路です。
As mentioned in Section 5.2, the solution SHOULD provide the capability to compute an optimal path dynamically, satisfying a set of specified constraints (defined in [TE-REQ]) across multiple IGP areas. Note that this requirement document does not mandate that all inter-area TE LSPs require the computation of an optimal (shortest) inter-area path. Some inter-area TE-LSP paths may be computed via some mechanisms that do not guarantee an optimal end-to-end path, whereas some other inter-area TE-LSP paths carrying sensitive traffic could be computed by making use of mechanisms allowing an optimal end-to-end path to be computed dynamically. Note that regular constraints such as bandwidth, affinities, IGP/TE metric optimization, path diversity, etc., MUST be taken into account in the computation of an optimal end-to-end path.
セクション5.2で言及されるように、解決策SHOULDはダイナミックに最適経路を計算する能力を提供します、複数のIGP領域の向こう側に1セットの指定された規制([TE-REQ]では、定義される)を満たして。 この要件ドキュメントが、相互領域TE LSPsがすべて、最適(最も短い)の相互領域経路の計算を必要とするのを強制しないことに注意してください。 いくつかの相互領域TE-LSP経路が終わりから端への最適の経路を保証しないいくつかのメカニズムで計算されるかもしれませんが、終わりから端への最適の経路がダイナミックに計算されるのを許容するメカニズムを利用することによって、敏感な交通を運ぶある他の相互領域TE-LSP経路は計算できるでしょう。 終わりから端への最適の経路の計算で帯域幅などの定期的な規制、親近感、IGP/TEのメートル法の最適化、経路の多様性などを考慮に入れなければならないことに注意してください。
7.4. Inter-Area MPLS-TE Routing
7.4. 相互領域MPLS-Teルート設定
As mentioned in Section 5.3, IGP hierarchy does not allow the head- end LSR to compute an end-to-end optimal path. Additional mechanisms are required to compute an optimal path. These mechanisms MUST not alter the IGP hierarchy principles. Particularly, in order to maintain containment of routing information and to preserve the overall IGP scalability, the solution SHOULD avoid any dynamic-TE- topology-related information from leaking across areas, even in a summarized form.
セクション5.3で言及されるように、ヘッド終わりのLSRはIGP階層構造で終わりから端への最適経路を計算できません。 追加メカニズムは最適経路を計算しなければなりません。 これらのメカニズムはIGP階層構造原則を変更してはいけません。 特に、ルーティング情報の封じ込めを維持して、総合的なIGPスケーラビリティを保存するために、解決策SHOULDは領域の向こう側に漏れるのからのどんなダイナミックなTEトポロジー関連の情報も避けます、まとめられたフォームでさえ。
Conversely, this does not preclude the leaking of non-topology- related information that is not taken into account during path selection, such as static TE Node information (TE router ids or TE node capabilities).
逆に、これが漏出を排除しない、非、-連れていかれないトポロジーに関連する情報は経路選択の間、説明されます、静的なTE Node情報(TEルータイドかTEノード能力)などのように。
Le Roux, et al. Informational [Page 11] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [11ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
7.5. Inter-Area MPLS-TE Path Computation
7.5. 相互領域MPLS-Te経路計算
Several methods may be used for path computation, including the following:
いくつかの方法が以下を含む経路計算に使用されるかもしれません:
- Per-area path computation based on ERO expansion on the head-end
LSR and on ABRs, with two options for ABR selection:
- EROに基づいたギヤエンドLSRの上と、そして、ABRsにおけるABR選択のための2つのオプションによる1領域あたりの経路計算拡大:
1) Static configuration of ABRs as loose hops at the head-end
LSR.
2) Dynamic ABR selection.
1) ゆるい同じくらいABRsの静的な構成はギヤエンドLSRのときに跳びます。 2) ダイナミックなABR選択。
- Inter-area end-to-end path computation, which may be based on (for
instance) a recursive constraint-based searching thanks to
collaboration between ABRs.
- 相互領域終わりから終わりへの経路計算。(その計算はABRsの間の共同のおかげで再帰的な規制ベースの探すのに基づくかもしれません(例えば))。
Note that any path computation method may be used provided that it respect key objectives pointed out in Section 5.3.
セクション5.3で指摘された主要目的を尊敬すればどんな経路計算方法も使用されるかもしれないことに注意してください。
If a solution supports more than one method, it should allow the operator to select by configuration, and on a per-LSP basis, the desired option.
解決策が1つ以上の方法を支持するなら、それは構成の近くと、そして、1LSPあたり1個のベースの上で選ぶオペレータ、必要なオプションを許容するべきです。
7.6. Inter-Area Crankback Routing
7.6. 相互領域Crankbackルート設定
Crankback routing, as defined in [CRANKBACK], may be used for inter- area TE LSPs. For paths computed thanks to ERO expansions with a dynamic selection of downstream ABRs, crankback routing can be used when there is no feasible path from a selected downstream ABR to the destination. The upstream ABR or head-end LSR selects another downstream ABR and performs ERO expansion.
[CRANKBACK]で定義されるCrankbackルーティングは相互領域TE LSPsに使用されるかもしれません。 選択された川下のABRから目的地まで実行可能経路が全くないとき、川下のABRsのダイナミックな品揃えによるERO拡大のおかげで計算された経路のために、crankbackルーティングを使用できます。 上流のABRかギヤエンドLSRが別の川下のABRを選択して、ERO拡大を実行します。
Note that this method does not allow computing an optimal path but just a feasible path. Note also that there can be 0(N^2) LSP setup failures before finding a feasible path, where N is the average number of ABR between two areas. This may have a non-negligible impact on the LSP setup delay.
この方法で最適経路にもかかわらず、まさしく実行可能経路を計算しないことに注意してください。 また、実行可能経路を見つける前に、0回(N^2)のLSPセットアップの故障があることができることに注意してください。そこでは、Nが2つの領域の間のABRの平均した数です。 これはLSPセットアップ遅れに非取るにたらない影響力を持っているかもしれません。
Crankback may also be used for inter-area LSP recovery. If a link/node/SRLG failure occurs in the backbone or tail-end area, the ABR upstream to the failure computes an alternate path and reroutes the LSP locally.
また、Crankbackは相互領域LSP回復に使用されるかもしれません。 リンク/ノード/SRLGの故障が背骨か末端領域に起こるなら、失敗へのABR上流は、代替パスを計算して、局所的にLSPを別ルートで送ります。
An inter-area MPLS-TE solution MAY support [CRANKBACK]. A solution that does, MUST allow [CRANKBACK] to be activated/deactivated via signaling, on a per-LSP basis.
相互領域MPLS-TE解決策は[CRANKBACK]を支持するかもしれません。 それがして、1LSPあたり1個のベースで合図することを通して動かされるか、または非活性化されるのを許容しなければならない[CRANKBACK]解決策。
Le Roux, et al. Informational [Page 12] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [12ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
7.7. Support of Diversely-Routed Inter-Area TE LSPs
7.7. さまざまに発送された相互領域Te LSPsのサポート
There are several cases where the ability to compute diversely-routed TE-LSP paths may be desirable. For instance, in the case of LSP protection, primary and backup LSPs should be diversely routed. Another example is the requirement to set up multiple diversely- routed TE LSPs between a pair of LSRs residing in different IGP areas. For instance, when a single TE LSP satisfying the bandwidth constraint cannot be found between two end-points, a solution would consist of setting up multiple TE LSPs so that the sum of their bandwidth satisfy the bandwidth requirement. In this case, it may be desirable to have these TE LSPs diversely routed in order to minimize the impact of a failure, on the traffic between the two end-points.
数個のケースがさまざまに発送されたTE-LSP経路を計算する能力が望ましいかもしれないところにあります。 例えば、LSP保護の場合では、予備選挙とバックアップLSPsはさまざまに発送されるべきです。 別の例は異なったIGP領域に住みながら1組のLSRsの間で複数のさまざまに発送されたTE LSPsをセットアップするという要件です。 例えば、2つのエンドポイントの間で帯域幅規制を満たす独身のTE LSPを見つけることができないとき、解決策は彼らの帯域幅の合計が帯域幅要件を満たすように複数のTE LSPsをセットアップするのから成るでしょう。 この場合、失敗の影響を最小にするためにこれらのTE LSPsをさまざまに発送させるのは望ましいかもしれません、2つのエンドポイントの間の交通に関して。
Thus, the solution MUST be able to establish diversely-routed inter- area TE LSPs when diverse paths exist. It MUST support all kinds of diversity (link, node, SRLG).
さまざまの経路が存在するとき、したがって、解決策はさまざまに発送された相互領域TE LSPsを設立できなければなりません。 それはすべての種類の多様性(リンク、ノード、SRLG)を支持しなければなりません。
The solution SHOULD allow computing an optimal placement of diversely-routed LSPs. There may be various criteria to determine an optimal placement. For instance, the placement of two diversely routed LSPs for load-balancing purposes may consist of minimizing their cumulative cost. The placement of two diversely-routed LSPs for protection purposes may consist of minimizing the cost of the primary LSP while bounding the cost or hop count of the backup LSP.
解決策SHOULDはさまざまに発送されたLSPsの最適のプレースメントを計算させます。 最適のプレースメントを決定する様々な評価基準があるかもしれません。 例えば、負荷分散目的のための2さまざまに発送されたLSPsのプレースメントはそれらの累積している費用を最小にするのから成るかもしれません。 保護目的のための2さまざまに発送されたLSPsのプレースメントはバウンドしていて、費用かホップがバックアップLSPに重要である間、第一のLSPの費用を最小にするのから成るかもしれません。
7.8. Intra/Inter-Area Path Selection Policy
7.8. 相互イントラ/領域経路選択方針
For inter-area TE LSPs whose head-end and tail-end LSRs reside in the same IGP area, there may be intra-area and inter-area feasible paths. If the shortest path is an inter-area path, an operator either may want to avoid, as far as possible, crossing area and thus may prefer selecting a sub-optimal intra-area path or, conversely, may prefer to use a shortest path, even if it crosses areas. Thus, the solution should allow IGP area crossing to be enabled/disabled, on a per-LSP basis, for TE LSPs whose head-end and tail-end reside in the same IGP area.
ギヤエンドと末端LSRsが同じIGP領域に住んでいる相互領域TE LSPsのために、イントラ領域と相互領域実行可能経路があるかもしれません。 最短パスが相互領域経路であるなら、オペレータは、領域にできるだけ交差するのを避けたくて、その結果、サブ最適のイントラ領域経路を選択するのを好むか、または逆に最短パスを使用するのを好むかもしれません、領域に交差していても。 したがって、解決策は可能にされるか、または無能にされるために交差する領域をIGPに許容するべきです、1LSPあたり1個のベースで、ギヤエンドと末端が同じIGP領域にあるTE LSPsのために。
7.9. Reoptimization of Inter-Area TE LSP
7.9. 相互領域Te LSPのReoptimization
The solution MUST provide the ability to reoptimize in a minimally disruptive manner (make before break) an inter-area TE LSP, should a more optimal path appear in any traversed IGP area. The operator should be able to parameterize such a reoptimization according to a timer or event-driven basis. It should also be possible to trigger such a reoptimization manually.
解決策は最少量で破壊的な方法(以前、開閉する)で相互領域TE LSPを再最適化する能力を提供しなければなりません、より最適の経路がどんな横断されたIGP領域にも現れるなら。 タイマかイベントドリブン基礎に従って、オペレータはそのような「再-最適化」をparameterizeすることができるべきです。 また、手動でそのような「再-最適化」の引き金となるのも可能であるべきです。
Le Roux, et al. Informational [Page 13] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [13ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
The solution SHOULD provide the ability to reoptimize an inter-area TE LSP locally within an area; i.e., while retaining the same set of transit ABRs. The reoptimization process in that case MAY be controlled by the head-end LSR of the inter-area LSP, or by an ABR. The ABR should check for local optimality of the inter-area TE LSPs established through it on a timer or event driven basis. The option of a manual trigger to check for optimality should also be provided.
解決策SHOULDは領域の中で局所的に相互領域TE LSPを再最適化する能力を提供します。 すなわち、トランジットABRsの同じセットを保有している間。 「再-最適化」の過程はその場合相互領域LSPのギヤエンドLSR、またはABRによって制御されるかもしれません。 ABRはTE LSPsがそれを通してタイマかイベントドリブンベースで確立した相互領域の地方の最適がないかどうかチェックするはずです。 また、最適がないかどうかチェックする手動の引き金のオプションを提供するべきです。
In some cases it is important to restrict the control of reoptimization to the Head-End LSR only. Thus, the solution MUST allow for activating/deactivating ABR control of reoptimization, via signaling on a per LSP-basis.
いくつかの場合、「再-最適化」のコントロールをHead-終わりのLSRだけに制限するのは重要です。 したがって、解決策は、LSP-基礎あたりのaで合図することを通して「再-最適化」のABRコントロールを起動するか、または非活性化すると考慮しなければなりません。
The solution SHOULD also provide the ability to perform an end-to-end reoptimization, potentially resulting in a change on the set of transit ABRs. Such reoptimization can only be controlled by the Head-End LSR.
また、解決策SHOULDは終わりから終わりへの「再-最適化」を履行能力に提供します、トランジットABRsのセットで潜在的に変化をもたらして。 Head-終わりのLSRまでにそのような「再-最適化」を制御できるだけです。
In the case of head-end control of reoptimization, the solution SHOULD provide the ability for the inter-area head-end LSR to be informed of the existence of a more optimal path in a downstream area and keep a strict control over the reoptimization process. Thus, the inter-area head-end LSR, once informed of a more optimal path in some downstream IGP areas, could decide to perform a make-before-break reoptimization gracefully (or not to), according to the inter-area TE-LSP characteristics.
「再-最適化」のギヤエンドのコントロールの場合では、解決策SHOULDは相互領域のギヤエンドLSRが川下の領域で、より最適の経路の存在において知識があって、「再-最適化」の過程の上に厳重な管理を保つ能力を提供します。 相互領域TE-LSPの特性に従ったその結果、いくつかの川下のIGP領域で、より最適の経路においてかつて知識があるLSRが優雅に以前開閉している「再-最適化」を実行すると決めることができた相互領域のギヤエンド(or not to)。
7.10. Inter-Area LSP Recovery
7.10. 相互領域LSP回復
7.10.1. Rerouting of Inter-Area TE LSPs
7.10.1. 相互領域Te LSPsについてコースを変更すること
The solution MUST support rerouting of an inter-area TE LSP in case of SRLG/link/node failure or preemption. Such rerouting may be controlled by the Head-End LSR or by an ABR (see Section 7.6, on crankback).
解決策は、SRLG/リンク/ノード障害か先取りの場合に相互領域TE LSPのコースを変更するのを支持しなければなりません。 そのようなコースを変更することはHead-終わりのLSRかABRによって制御されるかもしれません(crankbackの上のセクション7.6を見てください)。
7.10.2. Fast Recovery of Inter-Area TE LSP
7.10.2. 相互領域Te LSPの速い回復
The solution MUST provide the ability to benefit from fast recovery, making use of the local protection techniques specified in [FAST-REROUTE] both in the case of an intra-area network element failure (link/SRLG/node) and in that of an ABR node failure. Note that different protection techniques SHOULD be usable in different parts of the network to protect an inter-area TE LSP. This is of the utmost importance, particularly in the case of an ABR node failure, as this node typically carries a great deal of inter-area traffic. Moreover, the solution SHOULD allow computing and setting up a backup tunnel following an optimal path that offers bandwidth guarantees
解決策は速い回復の利益を得る能力を提供しなければなりません、イントラ領域ネットワーク要素の故障(リンク/SRLG/ノード)に関するケースの中と、そして、ABRノード障害のもので[FAST-REROUTE]で指定されたローカルの保護のテクニックを利用して。 異なった保護テクニックSHOULDがネットワークの異なった部分で使用可能であることに注意して、相互領域TE LSPを保護してください。 これは最重要性のものです、特にABRノード障害の場合で、このノードが大きな相互領域交通を通常載せるとき。 そのうえ、帯域幅保証を提供する最適経路に続いて、解決策SHOULDはバックアップトンネルを計算して、設立させます。
Le Roux, et al. Informational [Page 14] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [14ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
during failure, along with other potential constraints (such as bounded propagation delay increase along the backup path).
他の潜在的規制に伴う失敗(バックアップ道に沿った境界がある伝播遅れ増加などの)の間。
The solution SHOULD allow ABRs to be protected, while providing the same level of performances (recovery delay, bandwidth consumption) as provided today within an area.
解決策SHOULDは、今日領域の中で提供するように同じレベルの性能(回復遅れ、帯域幅消費)を提供している間、ABRsが保護されるのを許容します。
Note that some signaling approaches may have an impact on FRR performances (recovery delay, bandwidth consumption). Typically, when some intra-area LSPs (LSP-Segment, FA-LSPs) are used to support the inter-area TE LSP, the protection of ABR using [FAST-REROUTE] may lead to higher bandwidth consumption and higher recovery delays. The use of [FAST-REROUTE] to protect ABRs, although ensuring the same level of performances, currently requires a single end-to-end RSVP session (contiguous LSP) to be used, without any intra-area LSP. Thus, the solution MUST provide the ability, via signalling on a per-LSP basis, to allow or preclude the use of intra-area LSPs to support the inter-area LSPs.
いくつかのシグナリングアプローチがFRR性能(回復遅れ、帯域幅消費)に影響を与えるかもしれないことに注意してください。 いくつかのイントラ領域LSPs(LSP-セグメント、FA-LSPs)が相互領域TE LSPを支持するのに使用されるとき、通常、[FAST-REROUTE]を使用するABRの保護は、より高い帯域幅消費と、より高い回復遅れにつながるかもしれません。 同じレベルの性能を確実にしますが、ABRsを保護する[FAST-REROUTE]の使用は、現在ただ一つの終わりから終わりへのRSVPセッション(隣接のLSP)が使用されるのを必要とします、少しもイントラ領域LSPなしで。 したがって、解決策は能力を提供しなければなりません、1LSPあたり1個のベースで相互領域LSPsを支持するためにイントラ領域LSPsの使用を許容するか、または排除すると合図することを通して。
7.11. DS-TE support
7.11. DS-TEサポート
The proposed inter-area MPLS TE solution SHOULD also satisfy core requirements documented in [DSTE-REQ] and interoperate seamlessly with current intra-area MPLS DS-TE mechanism [DSTE-PROTO].
提案された相互領域MPLS TE解決策SHOULDはまた、[DSTE-REQ]に記録されたコア要件を満たして、継ぎ目なく現在のイントラ領域MPLS DS-TEメカニズム[DSTE-プロト]で共同利用します。
7.12. Hierarchical LSP Support
7.12. 階層的なLSPサポート
In the case of a large inter-area MPLS deployment, potentially involving a large number of LSRs, it may be desirable/necessary to introduce some level of hierarchy in order to reduce the number of states on LSRs (such a solution implies other challenges). Thus, the proposed solution SHOULD allow inter-area TE-LSP aggregation (also referred to as LSP nesting) so that individual TE LSPs can be carried onto one or more aggregating LSPs. One such mechanism, for example, is described in [LSP-HIER].
大きい相互領域MPLS展開の場合では、潜在的に多くを伴って、何らかのレベルの階層構造を紹介するのが、LSRsで州の数を減少させるのにLSRsでは、望ましいか、または必要であるかもしれません(そのような解決策は他の挑戦を含意します)。 したがって、提案された解決策SHOULDは、LSPsに集めながら個々のTE LSPsを1つ以上まで運ぶことができるように、相互領域TE-LSP集合(また、LSP巣篭もりと呼ばれる)を許容します。 例えばそのようなメカニズムの1つは[LSP-HIER]で説明されます。
7.13. Hard/Soft Preemption
7.13. 困難であるか柔らかい先取り
As defined in [MPLS-PREEMPT], two preemption models are applicable to MPLS: Soft and Hard Preemption.
[MPLS-PREEMPT]で定義されるように、2つの先取りモデルがMPLSに適切です: 柔らかくて困難な先取り。
An inter-area MPLS-TE solution SHOULD support the two models.
2がモデル化する相互領域MPLS-TE解決策SHOULDサポート。
In the case of hard preemption, the preempted inter-area TE LSP should be rerouted, following requirements defined in Section 7.10.1.
困難な先取りの場合では、セクション7.10.1で定義された要件に続いて、先取りされた相互領域TE LSPは別ルートで送られるべきです。
Le Roux, et al. Informational [Page 15] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [15ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
In the case of soft preemption, the preempted inter-area TE LSP should be re-optimized, following requirements defined in Section 7.9.
柔らかい先取りの場合では、セクション7.9で定義された要件に続いて、先取りされた相互領域TE LSPは再最適化されているべきです。
7.14. Auto-Discovery of TE Meshes
7.14. Teメッシュの自動発見
A TE mesh is a set of LSRs that are fully interconnected by a full mesh of TE LSPs. Because the number of LSRs participating in some TE mesh might be quite large, it might be desirable to provide some discovery mechanisms allowing an LSR to discover automatically the LSRs members of the TE mesh(es) that it belongs to. The discovery mechanism SHOULD be applicable across multiple IGP areas, and SHOULD not impact the IGP scalability, provided that IGP extensions are used for such a discovery mechanism.
TEメッシュはTE LSPsの完全なメッシュによって完全にインタコネクトされるLSRsの1セットです。 いくらかのTEメッシュに参加するLSRsの数がかなり大きいかもしれないので、LSRが自動的にTEのLSRsメンバーを発見できるメカニズムがかみ合うというそれが属す何らかの発見(es)を提供するのは望ましいかもしれません。 発見メカニズムSHOULD、複数のIGP領域の向こう側に適切にしてください、そして、SHOULDはIGPスケーラビリティに影響を与えません、IGP拡張子がそのような発見メカニズムに使用されれば。
7.15. Inter-Area MPLS TE Fault Management Requirements
7.15. 相互領域MPLS Te障害管理要件
The proposed solution SHOULD be able to interoperate with fault detection mechanisms of intra-area MPLS TE.
提案された解決策SHOULD、イントラ領域MPLS TEの欠点検出メカニズムで共同利用できてください。
The solution SHOULD support [LSP-PING] and [MPLS-TTL].
解決策SHOULDは[LSP-PING]と[MPLS-TTL]を支持します。
The solution SHOULD also support fault detection on backup LSPs, in case [FAST-REROUTE] is deployed.
また、[FAST-REROUTE]が配備されるといけないので、解決策SHOULDはバックアップLSPsで欠点検出を支持します。
7.16. Inter-Area MPLS TE and Routing
7.16. 相互領域MPLS Teとルート設定
In the case of intra-area MPLS TE, there are currently several possibilities for routing traffic into an intra-area TE LSP. They are listed in Section 4.2.
イントラ領域MPLS TEの場合には、イントラ領域TE LSPにはルーティング交通への現在、いくつかの可能性があります。 それらはセクション4.2に記載されています。
In the case of inter-area MPLS TE, the solution MUST support static routing into the LSP, and also BGP recursive routing with a static route to the BGP next-hop address.
相互領域MPLS TEの場合では、解決策はLSPへのサポートスタティックルーティング、およびBGP次のホップアドレスへのスタティックルートがあるBGPの再帰的なルーティングもそうしなければなりません。
ABRs propagate IP reachability information (summary LSA in OSPF and IP reachability TLV in ISIS), that MAY be used by the head-end LSR to route traffic to a destination beyond the TE-LSP tail-head LSR (e.g., to an ASBR).
ABRsは5月がTE-LSP尾根LSR(例えば、ASBRへの)を超えて交通を目的地に発送するのにギヤエンドLSRまでに使用されるというIP可到達性情報(OSPFの概要LSAとイシスのIPの可到達性TLV)を伝播します。
The use of IGP shortcuts MUST be precluded when TE-LSP head-end and tail-end LSRs do not reside in the same IGP area. It MAY be used when they reside in the same area.
TE-LSPギヤエンドと末端LSRsが同じIGP領域に住んでいないとき、IGP近道の使用を排除しなければなりません。 彼らが同じ領域に住んでいるとき、それは使用されるかもしれません。
The advertisement of an inter-area TE LSP as a link into the IGP, in order to attract traffic to an LSP source, MUST be precluded when TE-LSP head-end and tail-end LSRs do not reside in the same IGP area. It MAY be used when they reside in the same area.
TE-LSPギヤエンドと末端LSRsが同じIGP領域に住んでいないとき、LSPソースに交通を引き付けるためにIGPへのリンクとしての相互領域TE LSPの広告を排除しなければなりません。 彼らが同じ領域に住んでいるとき、それは使用されるかもしれません。
Le Roux, et al. Informational [Page 16] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [16ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
8. Evaluation criteria
8. 評価基準
8.1. Performances
8.1. パフォーマンス
The solution will be evaluated with respect to the following criteria:
解決策は以下の評価基準に関して評価されるでしょう:
(1) Optimality of the computed inter-area TE-LSP primary and backup
paths, in terms of path cost.
(2) Capability to share bandwidth among inter-area backup LSPs
protecting independent facilities.
(3) Inter-area TE-LSP setup time (in msec).
(4) RSVP-TE and IGP scalability (state impact, number of messages,
message size).
計算された相互領域TE-LSP予備選挙の(1)の最適と経路費用に関するバックアップ道。 (2) 独立している施設を保護する相互領域バックアップLSPsの中で帯域幅を共有する能力。 (3) 相互領域TE-LSP準備時間(msecにおける)。 (4) RSVP-TEとIGPスケーラビリティ(州の衝撃、メッセージの数、メッセージサイズ)。
8.2. Complexity and Risks
8.2. 複雑さとリスク
The proposed solution SHOULD not introduce 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は現在の操作ネットワークに複雑さを安定性に影響するだろうというそのような程度まで紹介して、SPネットワークの上でそのような解決策を配備する利益を減少させません。
8.3. Backward Compatibility
8.3. 後方の互換性
In order to allow for a smooth migration or co-existence, the deployment of inter-area MPLS TE SHOULD not affect existing MPLS TE mechanisms. In particular, the solution SHOULD allow the setup of an inter-area TE LSP among transit LSRs that do not support inter-area extensions, provided that these LSRs do not participate in the inter-area TE procedure. For illustration purposes, the solution MAY require inter-area extensions only on end-point LSRs, on ABRs, and, potentially, on Points of Local Repair (PLR) protecting an ABR.
特に滑らかな移動か共存(MPLS TE SHOULDが影響しない相互領域の既存のMPLS TEメカニズムの展開)を考慮するために、解決策SHOULDは相互領域拡大を支持しないトランジットLSRsの中で相互領域TE LSPのセットアップを許します、これらのLSRsが相互領域TE手順に参加しなければ。 イラスト目的のために、解決策はエンドポイントLSRsの上とだけ、そして、ABRsの上と、そして、潜在的にABRを保護するLocal Repair(PLR)のPointsの上で相互領域拡大を必要とするかもしれません。
9. Security Considerations
9. セキュリティ問題
This document does not introduce new security issues beyond those inherent in MPLS TE [RSVP-TE] and an inter-area MPLS-TE solution may use the same mechanisms proposed for that technology. It is, however, specifically important that manipulation of administratively configurable parameters be executed in a secure manner by authorized entities.
このドキュメントはMPLS TE[RSVP-TE]に固有のそれらを超えて新しい安全保障問題を紹介しません、そして、相互領域MPLS-TE解決策はその技術のために提案された同じメカニズムを使用するかもしれません。 しかしながら、行政上構成可能なパラメタの操作が権限のある機関によって安全な方法で実行されるのは、明確に重要です。
10. Acknowledgements
10. 承認
We would like to thank Dimitri Papadimitriou, Adrian Farrel, Vishal Sharma, and Arthi Ayyangar for their useful comments and suggestions.
彼らの役に立つコメントと提案についてディミトリPapadimitriou、エードリアン・ファレル、Vishalシャルマ、およびArthi Ayyangarに感謝申し上げます。
Le Roux, et al. Informational [Page 17] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [17ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
11. Contributing Authors
11. 作者を寄付します。
This document was the collective work of several authors. The text and content of this document was contributed by the editors and the co-authors listed below (the contact information for the editors appears in Section 14 and is not repeated below):
このドキュメントは数人の作者の集合著作物でした。 このドキュメントのテキストと中身はエディタと以下に記載された共著者によって寄付されました(エディタへの問い合わせ先は、セクション14に現れて、以下で繰り返されません):
Ting-Wo Chung Yuichi Ikejiri Bell Canada NTT Communications Corporation 181 Bay Street, Suite 350, 1-1-6, Uchisaiwai-cho, Toronto, Chiyoda-ku, Tokyo 100-8019 Ontario, Canada, M5J 2T3 JAPAN
チリンチリン-Wo青Yuichi IkejiriベルカナダNTTコミュニケーションズ株式会社181カナダ金融界、スイート350、1-1-6、内幸町、トロント、千代田区、オンタリオ(カナダ)M5J 2T3日本東京100-8019
EMail: ting_wo.chung@bell.ca EMail: y.ikejiri@ntt.com
メール: ting_wo.chung@bell.ca メール: y.ikejiri@ntt.com
Raymond Zhang Parantap Lahiri Infonet Services Corporation MCI 2160 E. Grand Ave. 22001 Loudoun Cty Pky El Segundo, CA 90025 Ashburn, VA 20147 USA USA
レイモンドチャンParantap Lahiri Infonetは社のMCI2160のE.の壮大なAveを調整します。 22001 Loudoun Cty Pkyエルセガンド(カリフォルニア)90025Ashburn、ヴァージニア20147米国米国
EMail: raymond_zhang@infonet.com EMail: parantap.lahiri@mci.com
メール: raymond_zhang@infonet.com メール: parantap.lahiri@mci.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN
Kenji Kumaki KDDI社の庭の空気Tower飯田橋、千代田区、東京102-8460(日本)
EMail: ke-kumaki@kddi.com
メール: ke-kumaki@kddi.com
Le Roux, et al. Informational [Page 18] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [18ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
12. Normative References
12. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
[RFC2119]ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、RFC2119、1997年3月。
[TE-REQ] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and
J. McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
[Te-REQ] AwducheとD.とマルコムとJ.とAgogbuaとJ.とオデル、M.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(1999年9月)。
[DSTE-REQ] Le Faucheur, F. and W. Lai, "Requirements for Support
of Differentiated Services-aware MPLS Traffic
Engineering", RFC 3564, July 2003.
[DSTE-REQ] Le FaucheurとF.とW.レイ、「微分されたサービス意識しているMPLS交通工学のサポートのための要件」、RFC3564、2003年7月。
13. Informative References
13. 有益な参照
[TE-OVW] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and
X. Xiao, "Overview and Principles of Internet Traffic
Engineering", RFC 3272, May 2002.
[Te-OVW] Awduche、D.、チウ、A.、Elwalid、A.、ウィジャヤ、I.、およびX.Xiao、「概観とインターネットプリンシプルズ交通工学」(RFC3272)は2002がそうするかもしれません。
[RSVP-TE] 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.
[RSVP-Te] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[OSPF-Te] キャッツ、D.、Kompella、K.、およびD.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計する交通、RFC3630、2003年9月。」
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to
Intermediate System (IS-IS) Extensions for Traffic
Engineering (TE)", RFC 3784, June 2004.
[イシス-Te] スミット、H.、およびT.李、「中間システムへの中間システム、(-、)、交通工学(Te)のための拡大、」、RFC3784(2004年6月)
[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装置] ボイル、J.、エラ、V.、ハナン、A.、クーパー、D.、Awduche、D.、クリスチャン、B.、およびW.レイ、「MPLSとの交通工学のための適用性証明」、RFC3346(2002年8月)。
[FAST-REROUTE] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed.,
"Fast Reroute Extensions to RSVP-TE for LSP Tunnels",
RFC 4090, May 2005.
[速く、コースを変更します] なべ、P.(エド)、ツバメ、G.(エド)、およびA.Atlas(エド)は「LSP Tunnelsのために速くRSVP-Teに拡大を別ルートで送ります」、RFC4090、2005年5月。
[LSP-PING] Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow,
G., Wadhwa, S., Bonica, R., "Detecting Data Plane
Liveliness in MPLS", Work in Progress.
[LSP-ピング]Kompella(K.)は撮影します、P.、Sheth、N.、クーパー、D.、ツバメ、G.、Wadhwa、S.、Bonica、R.、「MPLSにデータ飛行機活気を検出し」て、処理中の作業。
[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)」、RFC3443、2003年1月。
Le Roux, et al. Informational [Page 19] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [19ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
[LSP-HIER] Kompella, K., and Y. Rekhter, "LSP Hierarchy with
Generalized MPLS TE", Work in Progress.
[LSP-HIER] Kompella、K.、およびY.Rekhter、「一般化されたMPLS TeがあるLSP階層構造」が進行中で働いています。
[MPLS-RECOV] Sharma, V. and F. Hellstrand, "Framework for Multi-
Protocol Label Switching (MPLS)-based Recovery", RFC
3469, February 2003.
[MPLS-RECOV] シャルマとV.とF.Hellstrand、「マルチプロトコルのラベルの切り換えの(MPLS)ベースの回復のための枠組み」、RFC3469、2003年2月。
[CRANKBACK] Farrel, A., Ed., "Crankback Signaling Extensions for
MPLS Signaling", Work in Progress.
[CRANKBACK] エドファレル、A.、「MPLSのためのCrankbackシグナリング拡張子は合図すること」での処理中の作業。
[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-デフ]Le Faucheur(F.、ウー、L.、デイビー、B.、Davari、S.、バーナネン、P.、クリシュナン、R.、シェヴァル、P.、およびJ.Heinanen、「微分されたサービスのマルチプロトコルラベルスイッチング(MPLS)サポート」、RFC3270)は2002がそうするかもしれません。
[DSTE-PROTO] Le Faucheur, F., et al., "Protocol Extensions for
Support of Differentiated-Service-aware MPLS Traffic
Engineering", Work in Progress.
[DSTE-プロト] Le Faucheur、F.、他、「意識していた状態でサービスを微分しているMPLS交通工学のサポートのためのプロトコル拡大」、ProgressのWork。
[DIFF-ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[デフアーチ] ブレーク、S.は黒くされます、D.、カールソン、M.、デイヴィース、E.、ワング、Z.とW.ウィス、「微分されたサービスのための構造」RFC2475、1998年12月。
[DIFF-AF] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[デフ-AF] HeinanenとJ.とベイカーとF.とウィス、W.とJ.Wroclawski、「相対的優先転送PHBは分類する」RFC2597、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.
[デフ-EF] デイビー、B.、シャルニー、A.、アメリカダイコンソウ、J.C.、ベンソン、K.、Le Boudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、および2002年のD.Stiliadis、「完全優先転送PHB(1ホップあたりの振舞い)」、RFC3246行進。
[MPLS-PREEMPT] Farrel, A., "Interim Report on MPLS Pre-emption", Work
in Progress.
[MPLS先取りします] ファレル、A.、「MPLS先取りでの中間報告」が進行中で働いています。
[METRIC] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P.,
and T. Telkamp, "Use of Interior Gateway Protocol
(IGP) Metric as a second MPLS Traffic Engineering (TE)
Metric", BCP 87, RFC 3785, May 2004.
[METRIC] Le Faucheur、F.、Uppili、R.、ベドレン、A.、メルクス、P.、およびT.Telkamp、「a第2MPLS Traffic Engineering(TE)メートル法としてのメートル法のInteriorゲートウェイプロトコル(IGP)の使用」、BCP87、RFC3785(2004年5月)。
Le Roux, et al. Informational [Page 20] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [20ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
14. Editors' Addresses
14. エディタのアドレス
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France
ジャン・ルイル・ルーフランステレコム2、大通りピアー-Marzin22307Lannion Cedexフランス
EMail: jeanlouis.leroux@francetelecom.com
メール: jeanlouis.leroux@francetelecom.com
Jean-Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA - 01719 USA
ジャンフィリップVasseurシスコシステムズInc.300ビーバーブルック道路Boxborough、MA--01719米国
EMail: jpv@cisco.com
メール: jpv@cisco.com
Jim Boyle
ジム・ボイル
EMail: jboyle@pdnets.com
メール: jboyle@pdnets.com
Le Roux, et al. Informational [Page 21] RFC 4105 Inter-Area MPLS TE Reqs June 2005
ル・ルー、他 [21ページ]情報のRFC4105相互領域MPLS Te Reqs2005年6月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Le Roux, et al. Informational [Page 22]
ル・ルー、他 情報[22ページ]
一覧
スポンサーリンク
