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
Requirements for Inter-Area MPLS Traffic Engineering
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document 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トラフィックエンジニアリング（エリア間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
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
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:
[TE-REQ]で定義された要件をサポートしています[RSVP-TE]、[OSPF-TE]、および[ISIS-TE]で定義されたMPLSトラフィックエンジニアリングコンポーネントのセットは、達成するために多くのネットワークオペレータによって、今日使用されています[TE-OVW]で定義されている主要なトラフィックエンジニアリングの目的。これらの目的は、次のとおりです。
- 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
- 集約トラフィックの測定 - ネットワークリソースの使用率の最適化 - エンドツーエンドのQoS保証を必要とするサービスのサポート - リンク/ノード/共有リスクリンクグループ（SRLG）障害に対する高速リカバリー
Furthermore, the applicability of MPLS to traffic engineering in IP networks is discussed in [TE-APP].
また、IPネットワークにおけるトラフィックエンジニアリングのMPLSの適用は、[TE-APP]で議論されています。
The set of MPLS Traffic Engineering mechanisms, to date, has been limited to use within a single Interior Gateway Protocol (IGP) area.
MPLSトラフィックエンジニアリングメカニズムのセットは、現在までに、単一インテリアゲートウェイプロトコル（IGP）領域内での使用に限定されています。
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トラフィックエンジニアリングのメカニズムのための要件について説明します。
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保証を提供するために、およびエリア境界ルータ（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トラフィックエンジニアリングの現在の用途に対応します。その後、溶液がまたはエリア間MPLSトラフィックエンジニアリングをサポートするために満たすべき必要がある機能要件のセットについて説明します。要件の範囲はオペレータの間で変化するので、他の人が任意になり、一方、いくつかの要件が（SHOULD）、必須（MUST）であろう。最後に、これらの要件を満たす任意の解決のための評価基準のセットが与えられています。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
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：そのヘッドエンドLSRとテールエンドLSR又はそのヘッドエンドLSRとテールエンドLSR TE-LSPが遷移が同じIGP領域にともに同じIGP領域内に存在しないTE LSPパスが異なるIGP領域を越えています。
IGP area: OSPF area or IS-IS level.
IGPエリア：OSPFエリアまたはIS-ISレベル。
ABR: Area Border Router, a router used to connect two IGP areas (ABR in OSPF, or L1/L2 router in IS-IS).
ABR：エリア境界ルータ、2つのIGP領域を接続するために使用されるルータ（OSPFでABR、またはIS-ISでL1 / L2ルータ）。
CSPF: Constraint-based Shortest Path First.
CSPF：制約ベースの最短パスファースト。
SRLG: Shared Risk Link Group.
SRLG：共有リスクリンクグループ。
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の拡張のための要件を定義するためのものです。
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制御プレーンは、そのパスTE制約条件のセットに従う明示的ルーティングMPLS LSPを確立することができます。このようなリソース使用率の最適化、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トポロジの発見を担当するルーティングコンポーネント、。 [ISIS-TE]、[OSPF-TE]：これは、リンク状態IGPの拡張のおかげで確保されています。 - LSPを配置するための責任経路計算コンポーネント。これは、ヘッドエンドLSRの入力としてTEトポロジーとLSP制約をとるCSPFアルゴリズムのおかげで行われます。 - 計算されたパスに沿ってLSPの確立（明示的ルーティング、ラベル配布、およびリソース予約）を担うシグナル伝達成分、。これは、[RSVP-TE]-TEをRSVPのおかげで確保されています。
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は、ネットワーク内の離れた過剰利用資源から集約フローのパスをリダイレクトするエリア内で使用することができます。小規模では、これは明示的つのルータの間で使用されるパスを設定することによって行うことができます。壮大なスケールで、LSPのメッシュネットワーク内の中心点との間に確立することができます。 LSPパスが設定で静的に定義された、またはそのような帯域幅などの管理の制約を与えられた最短パスを決定するアルゴリズムによって到達することができます。このように、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のLSPを簡単かつスケーラブルな方法でトラフィック行列を測定することができていることにも注意してください。 2つのLSR間の集約トラフィックレートを容易に問題に2つのLSR間プロビジョニングTE LSP上に送信されるトラフィックの課金によって測定されます。
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ワーキンググループでのエッジで、またはDiffServの上に活性化することができる[DIFF-ARCH]、[DIFF-AF]、および[DIFF-EF]または[MPLS-DIFF]で説明されたメカニズムのセットを定義していますドメインは、片方向の最大伝送遅延、パケット間の遅延変動、損失率などの用語で表現することができるQoSポリシーの施行（またはポリシーのセット）、に貢献する多くのオペレータの一部または完全な展開を持っていますそのネットワークでの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.
MPLS TEは、単にのDiffServで使用することができます。その場合には、それだけで全体のトラフィックのための集約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メトリックは伝播遅延を反映する場合は説明のために、このような帯域幅のような様々な制約を満たす最小伝搬遅延経路を見つけることができます。
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.
品質に敏感なアプリケーションがデプロイされると、重要な要件の一つは、ネットワーク構成要素の故障の場合には、トラフィックの回復は、ミリ秒の数十に保証することができるように、高速回復メカニズムを提供することです。これは、古典的な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 failure along the LSP path [FAST-REROUTE]. Fast Reroute is currently used by many operators to protect sensitive traffic inside an IGP area.
さまざまな回復メカニズムはTE LSPの上に伝送されるトラフィックを保護するために使用することができます。これらは[MPLS-RECOV]で定義されています。保護メカニズムは、保護されたLSPの障害が発生した場合にトラフィックを回復するために使用されているバックアップLSPのプロビジョニングに基づいています。これらの保護メカニズムの中でも、（また高速リルート呼ばれる）ローカル保護がLSPパス[FAST-REROUTE]に沿ったリンク/ノード/ SRLGの障害の場合にはサブ50msの回復を達成することを意図しています。高速リルートは現在、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]はバックアップのLSPのための2つのモードを定義しています。 1対1のバックアップと呼ばれ、最初は、保護するために保護されたLSPごとや要素ごとに1つの迂回LSPを設定で構成されています。施設バックアップと呼ばれる第二は、所定の施設（リンクまたはノード）を保護するために、1つまたはいくつかのバイパスLSPをセットアップから成ります。障害が発生した場合に、すべての保護されたLSPは（MPLSラベル積層性から利益を得る）バイパスのLSPに入れ子になっています。
There are several possibilities for directing traffic into intra-area TE LSPs:
エリア内TEのLSPにトラフィックを導くためのいくつかの可能性があります。
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.
LSP宛先アドレスまたは他の任意のアドレスへの1）スタティックルーティング。 2）IGP SPF視点（IGPショートカット）からLSP先を超えIGP経路。対応するBGPネクストホップアドレス（オプション1）に単一の静的ルートによって、またはIGPショートカットによってTE LSPを介して到達可能であるBGPピア（またはMP-BGPピアによってアナウンス3）BGPルート）（オプション2）。これは、多くの場合、BGP再帰ルーティングと呼ばれています。 4）LSPは、すべてのノードのIGPデータベースの一部となるIGPへのリンクとして広告することができ、したがって、すべてのノードのSPF中に考慮することができます。 [LSP-HIER]で定義されるように、これは、フォワーディング、隣接の概念とは異なる概念に類似している場合でも、なお。 LSPは、TEデータベースの一部となるIGP-TEにTEリンクとして広告とCSPFに考慮した場合、隣接関係を転送することです。
5. Problem Statement, Requirements, and Objectives of Inter-Area MPLS TE
5.問題文、要件、およびエリア間MPLS TEの目的
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の障害の場合にはサブ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- 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.
しかし、MPLS-TEメカニズムは、現在、単一のIGP領域に限定されています。制限は、信号成分からよりルーティングおよび経路計算コンポーネントからより来ます。これは、CSPF全体トポロジーを必要とする頭部それらのIGP領域の端部のLSR、その結果、ヘッドエンドのLSRの階層制限トポロジの可視性は、もはや、末尾への最短拘束経路を計算する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のアプローチは、各エリアに独立してリソースを最適化することにより、サブ最適なリソース使用率につながる可能性があります。どのような多くのオペレータが望むことは、全体としてそのリソースを最適化することです。換言すれば、唯一の領域（フラットネットワーク）が存在したかのように。 - これは、このようにエリア間制約最短経路を計算することを可能としない領域を横切ってエンドツーエンドのQoS保証を保証するものではありません。 - インターエリアトラフィックは、ABRの故障の場合には[FAST-REROUTE]などのローカル保護メカニズムで保護することができません。
Therefore, existing MPLS TE mechanisms have to be enhanced to support inter-area TE LSPs.
そのため、既存のMPLS TEメカニズムは、エリア間TE LSPをサポートするように拡張する必要があります。
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メカニズムの現在のセットを拡張することが望まれます。
The solution MUST allow setting up inter-area TE LSPs; i.e., LSPs whose path crosses at least two IGP areas.
ソリューションは、エリア間のTE LSPを設定できるようにしなければなりません。即ち、その経路少なくとも二つのIGP領域を横切るのLSP。
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).
したがって、溶液は、制約のセット（すなわち、帯域幅）を満たすエリア間の最短経路を計算する能力を提供すべきです。
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階層の概念を維持し、ルーティングを維持し、主要目的として、スケーラビリティを信号伝達して設計されなければなりません。
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階層の概念を保存しなければなりません。
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のスケーラビリティを維持する要素は、実際には階層保存目的は、上記のセクションで対処されます。
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.
セクション5.2で述べたように、特に、そのような帯域幅制約のセットを満足する最短エリア間の経路を計算するために非常に敏感なトラフィックを搬送するいくつかのエリア間TE LSPのために所望されてもよいです。ヘッドエンドにおけるベースCSPFがもはやによるトポロジーおよびリソース情報の不足のために使用することができないので、これは、追加のルーティング機構を必要とし得ます。そのようなルーティングメカニズムは、システム全体のスケーラビリティを損なわないしなければなりません。
---area1--------area0------area2--
------R1-ABR1-R2-------ABR3-------
| \ | / | |
| R0 \ | / | R4 |
| R5 \ |/ | |
---------ABR2----------ABR4-------
- ABR1, ABR2: Area0-Area1 ABRs - ABR3, ABR4: Area0-Area2 ABRs
- ABR1、ABR2：エリア0、エリア1のABR - ABR3、ABR4：エリア0、エリア2バール
- R0, R1, R5: LSRs in area 1 - R2: an LSR in area 0 - R4: an LSR in area 2
- R0、R1、R5：領域1のLSR - 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の用語の使用を作りますが、この文書は、同様にIS-ISに適用されます。
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は、両方のLSRが異なるIGP領域に属するR0とR4との間に設定されます。溶液は、任意の領域内の任意のリンク/ SRLG /ノードの障害と任意のABR横断の障害から、このような相互領域TE LSPを保護する能力をサポートしなければならないことに留意されたいです。 TE LSP R0-> R4はR1-> ABR1-> R2を通過する場合、例えば、それは代替パスR1-に従うことができるABR1障害、バックアップLSP（迂回またはバイパス）のおかげで保護することができる> ABR2 - > 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は、R1からR4へのEFに分類ルートのVoIPトラフィックに設定されています。クラスごとのエリア間制約ベースのルーティングは、DS-TE LSPは、VoIPトラフィックのための厳格なQoS保証を確保するパスを介してルーティングすることができます。
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（又はIS-ISを有する任意の他のレベル）を有することが可能であるかもしれません。もはや内エリアパスR0ツーR5に十分なリソースがない場合があるかもしれない、とどこバックボーンエリアを通じて実現可能なエリア間のパスがあります。
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.
提案された解決策は、走行経路に沿って必要さらにプロビジョニングすることなく、（潜在的に緩いパスで）相互接続のABRを横切って通過するエンドツーエンドのRSVPシグナリングとヘッドエンドにプロビジョニングを可能にしなければなりません。
The solution MUST allow for the signaling of inter-area TE LSPs, using RSVP-TE.
溶液はRSVP-TEを用いて、エリア間TE LSPのシグナリングを可能にしなければなりません。
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がインター領域の厳密または緩いホップによって、のABRを含む、明示のLSRのセットを指定することを可能にしなければなりませんTE LSP。
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.
加えて、提案された解決策はまた、明示的に相互領域TE-LSPパスの確立に除外される特定のリソースを指定してシグナリングする能力を提供すべきです。
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メトリック[尺度]のいずれかを考慮して、複数の領域を横切る最短経路として定義されます。換言すれば、このような経路は、複数の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で述べたように、この溶液を複数のIGP領域を横切って（[TE-REQ]で定義される）指定された制約のセットを満足する、動的に最適経路を計算する能力を提供すべきです。この要件文書はすべて相互領域TEのLSPが最適（最短）エリア間経路の計算を必要とすることを強制しないことに留意されたいです。敏感なトラフィックを搬送するいくつかの他の相互領域TE-LSPパスが可能機構を使用することによって計算することができるのに対し、いくつかの相互領域TE-LSPパスは、最適なエンドツーエンドのパスを保証するものではないいくつかの機構を介して計算することができます最適なエンドツーエンドのパスを動的に計算することができます。等帯域幅、親和性、IGP / 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節で述べたように、IGP階層は、ヘッドエンドLSRは、エンドツーエンドの最適経路を計算することはできません。追加のメカニズムは、最適なパスを計算するために必要とされます。これらのメカニズムは、IGP階層の原則を変更してはいけません。特に、ルーティング情報の格納を維持し、全体的なIGPスケーラビリティを維持するために、溶液はさらにまとめる形で、領域を横切って漏れる任意動的-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ノード情報（TEルータIDまたは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:
- パー・エリア経路計算ABR選択のための2つのオプションが、ヘッドエンドLSRにとのABRにERO拡張に基づきます。
1) Static configuration of ABRs as loose hops at the head-end
LSR.
2) Dynamic ABR selection.
- Inter-area end-to-end path computation, which may be based on (for instance) a recursive constraint-based searching thanks to collaboration between ABRs.
- （例えば）に基づくことができる間領域エンドツーエンド経路計算、再帰的な制約ベースのABRの間のコラボレーションのおかげで検索。
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.
ソリューションは、複数のメソッドをサポートしている場合、それは、オペレータが設定で選択できるようにする、とあたり-LSPごと、希望のオプションにする必要があります。
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.
クランクバックルーティングは、[クランクバック]で定義されるように、相互領域TE LSPのために使用することができます。先に選択された下流ABRからの実現可能なパスがない場合、下流のABRの動的選択とERO展開のおかげで計算経路は、クランクバック・ルーティングを使用することができます。上流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.
この方法は、最適なパスちょうど実現可能なパスを計算することはできませんので注意してください。 Nは、2つの領域間のABRの平均数で実現可能な経路を見つける前に0（N ^ 2）LSPセットアップの失敗があってもよいことにも留意されたいです。これは、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.
クランクバックにも、エリア間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のソリューションは、[クランクバック]をサポートするかもしれません。した溶液を、[クランクバック]あたり-LSPに基づいて、シグナリングを介して不活性化/活性化することを可能にしなければなりません。
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の保護の場合には、プライマリおよびバックアップLSPは多様にルーティングする必要があります。別の例では、異なるIGP領域に存在するのLSRの対の間に複数の多様ルーティングTE LSPを設定するための要件です。例えば、帯域幅の制約を満たす単一のTE LSPは、2つのエンドポイント間で見つけることができない場合、解決策は、それらの帯域幅の合計は、帯域幅要件を満たすように、複数のTE LSPを設定することからなります。この場合には、多様に2つのエンドポイント間のトラフィックの障害の影響を最小限にするためにルーティングされ、これらのTE LSPを有することが望ましいです。
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 LSPを確立できなければなりません。これは、多様性（リンク、ノード、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.
ソリューションは、多様にルーティングされたLSPの最適な配置を計算できるようにすべきです。最適な配置を決定するためのさまざまな基準があるかもしれません。例えば、負荷分散の目的のための2つの多様にルーティングされたLSPの配置は、彼らの累積コストを最小限に抑えることで構成することができます。保護の目的のための2つ多様にルーティングされたLSPの配置は、バックアップLSPのコストやホップ数を境界としながら、主LSPのコストを最小限に抑えることで構成することができます。
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.
そのヘッドエンドとテールエンドのLSRが同じIGP領域に存在する相互領域TE LSPのために、イントラ領域と相互領域可能経路があってもよいです。最短経路は、エリア間のパスである場合、オペレータは、領域を横断する、可能な限り回避することができるいずれか従って次善エリア内のパスを選択することを好むか、または、逆に、最短パスを使用することを好むかもしれません、それは領域を横切る場合でも。したがって、溶液は、IGP領域の交差が、そのヘッドエンドとテールエンド同じIGP領域に存在するTE LSPのため、毎LSPに基づいて、有効/無効にすることを可能にするべきです。
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領域に表示されなければならない最小破壊方法（ブレークする前に行う）に再最適化する能力を提供しなければなりません。オペレータは、タイマーまたはイベント・ドリブン基準に従ってこのような再最適化をパラメータ化することができなければなりません。また、手動で、このような再最適化をトリガすることが可能です。
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.
溶液は、領域内で局所的に相互領域TE LSPを再最適化する能力を提供すべきです。すなわち、トランジットのABRの同じセットを保持します。その場合の再最適化プロセスは、エリア間LSPのヘッドエンドLSRによって、又はABRによって制御することができます。 ABRは、タイマーやイベント駆動ベースでそれを介して確立し、エリア間のTE LSPの局所最適をチェックする必要があります。最適かどうかを確認するために、マニュアルトリガのオプションも提供されるべきです。
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.
いくつかのケースでは、唯一のヘッドエンドLSRに再最適化の制御を制限することが重要です。したがって、溶液はLSP-ごとにシグナリングを介して、再最適化の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.
溶液はまた、潜在的にトランジットのABRのセットに変化をもたらす、エンドツーエンドの再最適化を実行する能力を提供すべきです。このような再最適化は、唯一のヘッドエンド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.
再最適化のヘッドエンド制御の場合には、溶液は、下流領域でより最適経路の存在を通知するエリア間のヘッドエンドLSRのための能力を提供するべきであり、再最適化プロセスにわたって厳密な制御を維持します。このように、エリア間ヘッドエンドLSRは、かつていくつかの下流のIGP領域でより最適な経路を知らされ、エリア間によると、優雅に（またはしないように）メイク・ビフォア・ブレーク再最適化を実行することを決定することができTE- LSP特性。
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の再ルーティングをサポートしなければなりません。そのような再ルーティングは、ヘッドエンドLSRによって、またはABR（クランクバックに、第7.6節を参照）によって制御されてもよいです。
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 during failure, along with other potential constraints (such as bounded propagation delay increase along the backup path).
溶液は、エリア内のネットワーク要素の故障（リンク/ SRLG /ノード）の場合との両方において、[FAST-REROUTE]で指定されたローカル保護技術を利用して、高速リカバリから利益を得る能力を提供しなければなりませんABRノード障害が発生。異なる保護技術が相互領域TE LSPを保護するために、ネットワークのさまざまな部分で使用可能であるべきであることに留意されたいです。このノードは、典型的には、エリア間のトラフィックの多くを運ぶ、これは、特にABRノード障害が発生した場合に、最も重要です。また、溶液は、コンピューティングを可能にし、（例えば、バックアップパスに沿って有界伝播遅延の増加のような）他の潜在的な制約とともに、故障時に帯域幅保証を提供する最適なパス次のバックアップトンネルを設定すべきです。
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.
溶液は、エリア内に現在提供される性能の同じレベル（回復遅延、帯域幅消費）を提供しながらのABRは、保護されることを可能にするべきです。
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性能（回復遅延、帯域幅の消費）に影響を与えることができることに留意されたいです。いくつかのエリア内のLSP（LSPセグメント、FA-のLSP）が相互領域TE LSPをサポートするために使用される場合、典型的には、ABRの保護は、より高い帯域幅の消費と、より高い回復の遅延につながる可能性が[FAST-REROUTE]を使用します。 ABRを保護する[FAST-REROUTE]の使用は、性能の同じレベルを確保しているが、現在どのエリア内LSPことなく、使用する単一のエンドツーエンドRSVPセッション（連続LSP）を必要とします。従って、溶液がエリア間LSPをサポートするエリア内のLSPの使用を許可または防止するために、毎LSPに基づいてシグナリングを介して、能力を提供しなければなりません。
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溶液は、[DATE-REQ]に記載のコア要件を満たし、現在のイントラ領域MPLS DS-TE機構[DATE-PROTO]とシームレスに相互運用するべきです。
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].
可能性のLSRの多数を含む大規模なエリア間MPLSの導入の場合には、LSRの上の状態の数を減らすために、階層のあるレベルを導入することが必要/望ましいかもしれない（そのような解決策は、他の挑戦を意味します） 。したがって、提案された解決策は、個々のTEのLSPは、1つ以上の凝集のLSPに行うことができるように（また、LSPのネストと呼ぶ）間領域TE-LSPの集約を可能にすべきです。そのような機構は、例えば、[LSP-HIER]に記載されています。
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.
エリア間MPLS-TEのソリューションは、二つのモデルをサポートする必要があります。
In the case of hard preemption, the preempted inter-area TE LSP should be rerouted, following requirements defined in Section 7.10.1.
ハードプリエンプションの場合には、プリエンプト相互領域TE LSPはセクション7.10.1に定義された要件に従って、再ルーティングされなければなりません。
In the case of soft preemption, the preempted inter-area TE LSP should be re-optimized, following requirements defined in Section 7.9.
ソフトプリエンプションの場合には、プリエンプト相互領域TE LSPは、セクション7.9で定義された要件に従って、再最適化されるべきです。
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 LSPのフルメッシュによって相互接続されているのLSRのセットです。いくつかのTEメッシュに参加するのLSRの数が非常に大きくなる可能性があるため、LSRが自動的にそれが属するTEメッシュ（ES）のLSRのメンバーを発見することができ、いくつかの発見メカニズムを提供することが望ましいかもしれません。発見メカニズムは、複数のIGP領域を横切って適用されるべきであり、IGPスケーラビリティに影響を与えてはならない、IGP拡張が、そのような検出メカニズムのために使用されることを条件とします。
The proposed solution SHOULD be able to interoperate with fault detection mechanisms of intra-area MPLS TE.
提案された解決策は、イントラ領域MPLS TEの故障検出機構と相互運用することができるべきです。
The solution SHOULD support [LSP-PING] and [MPLS-TTL].
溶液をサポートすべきである[LSP-PING]と[MPLS-TTL]。
The solution SHOULD also support fault detection on backup LSPs, in case [FAST-REROUTE] is deployed.
溶液はまた、[FAST-REROUTE]の場合に、バックアップのLSPに故障検出をサポートするべきで配備されます。
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).
ABRは（ASBRに例えば、）TE-LSPテールヘッドLSRを越えた先にトラフィックをルーティングするためにヘッドエンドLSRによって使用されるかもしれIP到達可能性情報（ISISでOSPFやIP到達可能性TLVでの要約LSA）を、伝播します。
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のヘッドエンドとテールエンドのLSRが同じ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のヘッドエンドとテールエンドのLSRが同じIGP領域に常駐していないときIGPへのリンクなど、エリア間TE LSPの広告は、LSPソースへのトラフィックを誘致するために、排除されなければなりません。彼らは同じ領域に存在するときに使用されるかもしれません。
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).
（1）計算された相互領域TE-LSPパスコストの点でプライマリとバックアップパスの最適。 （2）独立した施設を保護エリア間バックアップのLSPの間で帯域幅を共有する能力。 （3）インターエリアTE-LSPのセットアップ時間（ミリ秒単位）。 （4）RSVP-TEとIGPスケーラビリティ（状態の影響、メッセージの数、メッセージサイズ）。
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.
提案された解決策は、それが安定性に影響し、SPネットワーク上でこのようなソリューションを展開する利点を減少させるであろうと、そのような程度に、現在のオペレーティング・ネットワークの複雑さを紹介するべきではありません。
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の展開は、既存のMPLS TEメカニズムに影響を与えるべきではありません。具体的には、解決策は、エリア間の拡張をサポートしていませんトランジットLSRの間、エリア間TE LSPの設定を可能にしなければならない、これらのLSRは、エリア間TEの手続きに参加しないことを条件とします。例示の目的のために、溶液は、ABRを保護ローカル修復（PLR）の点に、潜在的に、のABRにのみ終点LSRの上のエリア間の拡張を必要とするかもしれません。
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のソリューションは、その技術のために提案されている同じメカニズムを使用することができ、エリア間に固有のものを超えて、新たなセキュリティ問題を紹介しません。ただし、管理上設定可能なパラメータの操作が許可されたエンティティによって安全な方法で実行されていることが特に重要です。
We would like to thank Dimitri Papadimitriou, Adrian Farrel, Vishal Sharma, and Arthi Ayyangar for their useful comments and suggestions.
私たちは、彼らの役に立つコメントと提案のためのディミトリPapadimitriou、エードリアンファレル、ヴィシャル・シャルマ、およびArthi Ayyangarに感謝したいと思います。
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
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
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ラヒリインフォネットサービス株式会社MCI 2160 E.グランドアベニュー22001ラウドン郡パークウェイエルセグンドー、CA 90025アッシュバーン、VA 20147 USA USA
EMail: raymond_zhang@infonet.com EMail: parantap.lahiri@mci.com
電子メール：raymond_zhang@infonet.com Eメール：parantap.lahiri@mci.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN
けんじ くまき Ｋっぢ こｒぽらちおん がｒでん あいｒ とうぇｒ いいだばし、 ちよだーく、 ときょ １０２ー８４６０、 じゃぱん
EMail: ke-kumaki@kddi.com
メールアドレス：ke-kumaki@kddi.com
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirements levels", RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すRFCsにおける使用のためのキーワード"、RFC 2119、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のための要件"、RFC 2702、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]ルFaucheur、F.およびW.ライ、 "差別化サービスを意識したMPLSトラフィックエンジニアリングのサポートのための要件"、RFC 3564、2003年7月。
[TE-OVW] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.
[TE-OVW] Awduche、D.、チウ、A.、Elwalid、A.、Widjaja、I.、およびX.シャオ、 "インターネットトラフィックエンジニアリングの概要と原則"、RFC 3272は、2002年5月。
[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.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：ExtensionsがLSPトンネルのためのRSVPする"、RFC 3209 、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.ヨン、 "トラフィックエンジニアリング（TE）OSPFバージョン2への拡張"、RFC 3630、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.
[ISIS-TE]スミット、H.、およびT.李、 "トラフィックエンジニアリングのための中間システム（ISIS）拡張機能（TE）への中間システム"、RFC 3784、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-APP]ボイル、J.、ギル、V.、阪南、A.、クーパー、D.、Awduche、D.、クリスチャン、B.、およびW.ライ、 "MPLSとトラフィックエンジニアリングのための適用性に関する声明"、 RFC 3346、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.
[FAST-REROUTE]パン、P.、エド。、ツバメ、G.、エド。、およびA.アトラス編、RFC 4090、2005年5月 "高速リルート機能拡張LSPトンネルのための-TEをRSVPに"。
[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-PING] 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、 "（TTL）の生存時間（MPLS）ネットワークのマルチプロトコルラベルスイッチングの処理"、RFC 3443、2003年1月。
[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と階層"、ProgressのWork。
[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、RFC 3469、2003年2月の "回復をベースマルチプロトコルラベルスイッチング（MPLS）のためのフレームワーク"。
[CRANKBACK] Farrel, A., Ed., "Crankback Signaling Extensions for MPLS Signaling", Work in Progress.
[クランクバック]ファレル、A.編、「MPLSシグナリングのためのクランクバックシグナリング拡張」が進行中で働いています。
[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]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング差別化サービスの（MPLS）サポート」、RFC 3270、2002年5月。
[DSTE-PROTO] Le Faucheur, F., et al., "Protocol Extensions for Support of Differentiated-Service-aware MPLS Traffic Engineering", Work in Progress.
[DSTE - プロト]ルFaucheur、F.、ら、「差別・サービスを意識したMPLSトラフィックエンジニアリングのサポートのためのプロトコル拡張機能」が進行中で働いています。
[DIFF-ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[DIFF-ARCH]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[DIFF-AF] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[DIFF-AF] Heinanen、J.、ベーカー、F.、ワイス、W.、及びJ. Wroclawski、 "保証転送PHBグループ"、RFC 2597、1999年6月。
[DIFF-EF] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[DIFF-EF]デイビー、B.、Charny、A.、ベネット、JC、ベンソン、K.、ルBoudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、およびD. Stiliadis、 "緊急転送PHB（ホップ単位動作）"、RFC 3246、2002月。
[MPLS-PREEMPT] Farrel, A., "Interim Report on MPLS Pre-emption", Work in Progress.
[MPLS-PREEMPT]ファレル、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.
[尺度]ルFaucheur、F.、Uppili、R.、Vedrenne、A.、メルクス、P.、およびT. Telkamp、 "第二のMPLSトラフィックエンジニアリング（TE）メトリックとしてインテリアゲートウェイプロトコル（IGP）メトリックの使用" 、BCP 87、RFC 3785、2004年5月。
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France
ジャン=ルイ・ルーフランステレコム2、大通りピエールMarzin 22307ラニオンセデックスフランス
EMail: jeanlouis.leroux@francetelecom.com
メールアドレス：jeanlouis.leroux@francetelecom.com
Jean-Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA - 01719 USA
ジャン=フィリップVasseurシスコシステムズ社300ビーバーブルック・ロードボックスボロー、MA - 01719 USA
EMail: jpv@cisco.com
メールアドレス：jpv@cisco.com
Jim Boyle
ジム・ボイル
EMail: jboyle@pdnets.com
メールアドレス：jboyle@pdnets.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。