[要約] RFC 4105は、異なるエリア間のMPLSトラフィックエンジニアリングの要件を定義しています。その目的は、エリア間のネットワークトラフィックを効果的に制御し、最適な経路を確保することです。
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
エリア間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）The Internet Society（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）のサポートのための詳細な一連の機能要件がリストされています。これは、これらの要件を満たすための手順とプロトコル拡張を指定するソリューションを意図しています。
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:
[RSVP-TE]、[OSPF-TE]、および[ISIS-TE]で定義されているMPLSトラフィックエンジニアリングコンポーネントのセットは、[TE-REQ]で定義されている要件をサポートしていますが、今日では多くのネットワーク演算子によって使用されています。[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ネットワークでのトラフィックエンジニアリングへのMPLの適用性については、[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.
基本的に、MPLS TE機能をIGPエリア全体に拡張して、エリア間リソースの最適化をサポートし、異なるエリア内にある2つのエッジルーター間の厳格なQoS保証を提供し、エリア間トラフィックをエリアボーダールーター（ABR）から保護することが有用です（ABR）障害。
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トラフィックエンジニアリングをサポートするために、ソリューションが満たさなければならない、または満たす必要がある一連の機能要件について説明します。要件の範囲はオペレーター間で異なるため、一部の要件は必須（必須）になりますが、他の要件はオプションです（必要）。最後に、これらの要件を満たすソリューションの一連の評価基準が示されています。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
インターエリアLSP：ヘッドエンドLSRおよびテールエンドLSRが同じIGP領域内に存在しないか、ヘッドエンドLSRとテールエンドLSRは両方とも同じIGP領域にありますが、TE-LSPは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保証、高速障害回復などの主要な目標を達成するために使用されます。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：[ISIS-TE]、[OSPF-TE]の拡張により保証されます。-LSPの配置を担当するパス計算コンポーネント。CSPFアルゴリズムのおかげで、ヘッドエンドLSRで実行されます。これは、TEトポロジとLSPの制約を入力として使用します。 - 計算されたパスに沿って、LSP（明示的なルーティング、ラベル分布、およびリソース予約）の確立を担当するシグナルコンポーネント。これは、RSVP-TE [RSVP-TE]のおかげで保証されます。
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つのルーター間で使用されるパスを明示的に構成することによって行うことができます。大規模には、ネットワーク内の中央ポイント間にLSPのメッシュを確立できます。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 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ワーキンググループは、[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-proto]で定義されているdiffserv-aware TEと呼ばれるMPLS TEへの拡張が必要です。DS-TEは、厳密なエンドツーエンドのQoS保証を保証することを可能にします。たとえば、EF DS-TE LSPを同じ領域内の音声ゲートウェイ間にプロビジョニングして、トラフィックをVoIPする厳格なQOを確保することができます。
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.
品質に敏感なアプリケーションが展開されるため、主要な要件の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 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のプロビジョニングに基づいています。これらの保護メカニズムの中で、局所保護（Fast Rerouteとも呼ばれます）は、LSPパスに沿ったLink/Node/SRLG障害の場合にサブ50msの回復を達成することを目的としています[Fast-Reroute]。現在、Fast 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]バックアップLSPの2つのモードを定義します。1対1のバックアップと呼ばれる最初のものは、保護されたLSPごとに1つの迂回LSPをセットアップし、保護する要素ごとに構成されています。施設のバックアップと呼ばれる2番目は、特定の施設（リンクまたはノード）を保護するために1つまたは複数のバイパスLSPをセットアップすることで構成されています。障害の場合、保護されたすべてのLSPはバイパスLSPにネストされています（MPLSラベルスタッキングプロパティの恩恵）。
There are several possibilities for directing traffic into intra-area TE LSPs:
Intra-Area ece 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.
1) LSP宛先アドレスまたはその他のアドレスへの静的ルーティング。2）IGP SPFの観点（IGPショートカット）から、LSP宛先を越えたIGPルート。3）BGPピア（またはMP-BGPピア）によって発表されたBGPルートは、対応するBGPネクストホップアドレス（オプション1）またはIGPショートカット（オプション1）への単一の静的ルートによってTE LSPを介して到達可能です（オプション2）。これは多くの場合、BGP再帰ルーティングと呼ばれます。4）LSPをIGPへのリンクとして宣伝して、すべてのノードのIGPデータベースの一部になるため、すべてのノードのSPF中に考慮することができます。概念が類似していても、これは[lsp-hier]で定義されているように、転送順応の概念とは異なることに注意してください。フォワーディングアジェンシーとは、LSPがTE-LinkとしてIGP-TEに宣伝され、TEデータベースの一部になり、CSPFで考慮される場合です。
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保証を提供し、Link/Node/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領域に限定されています。制限は、信号コンポーネントからよりもルーティングおよびパス計算コンポーネントからもたらされます。これは基本的に、階層がヘッドエンドLSRのIGP領域へのトポロジーの可視性を制限し、その結果、ヘッドエンドLSRが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レベルでの交通集約は、効率的な交通工学につながらないいくつかの制約を意味します。実際、このエリアごとのアプローチは、各エリアでリソースを独立して最適化することにより、最適なリソースの利用につながる可能性があります。多くのオペレーターが望んでいるのは、リソース全体を最適化することです。言い換えれば、まるで1つの領域（フラットネットワーク）しかないかのように。 - これにより、エリア間制約の最短パスを計算することはできません。したがって、領域全体でエンドツーエンドのQoS保証が保証されません。 - ABR故障の場合の[Fast-Reroute]などのローカル保護メカニズムでは、エリア間のトラフィックを保護することはできません。
Therefore, existing MPLS TE mechanisms have to be enhanced to support inter-area TE LSPs.
したがって、既存の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メカニズムの現在のセットを拡張することが非常に望まれています。
The solution MUST allow setting up inter-area TE LSPs; i.e., LSPs whose path crosses at least two IGP areas.
このソリューションは、インターエアリーLSPのセットアップを可能にする必要があります。つまり、パスが少なくとも2つの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で述べたように、帯域幅などの制約セットを満たすために、非常に機密性の高いトラフィックを運ぶいくつかのエリア間の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 ABRS-ABR3、ABR4：エリア0エリア2 ABRS
- 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 -R4：エリア2のLSRの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.
通常、両方のLSRが異なるIGP領域に属し、R0とR4の間にインターエアリーLSPがセットアップされます。ソリューションは、任意の領域内の任意のリンク/srlg/ノードの障害から、このようなエリア間のLSPを保護する機能をサポートする必要があることに注意してください。たとえば、TE LSP R0-> R4がR1-> ABR1-> R2を通過する場合、代替パスR1-> ABR2に従う可能性のあるバックアップLSP（迂回またはバイパス）のおかげで、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は、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.
場合によっては、バックボーンエリア（またはIS-ISのその他のレベル）を介してR0からR5への界面指定LSPを持つことも可能かもしれません。エリア内パス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を使用して、インターエアリー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]で定義）を満たす必要があります。この要件文書は、すべてのエリア間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スケーラビリティを維持するために、ソリューションは、要約された形式であっても、地域を漏らすことから動的なテトポロジー関連の情報を避ける必要があります。
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:
- ヘッドエンドLSRおよびABRSのERO拡張に基づくエリアごとのパス計算、ABR選択の2つのオプションがあります。
1) Static configuration of ABRs as loose hops at the head-end LSR. 2) Dynamic ABR selection.
1) ヘッドエンドLSRでのルーズホップとしてのABRの静的構成。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.
- 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.
[クランクバック]で定義されているクランクバックルーティングは、インターエリアのLSPに使用できます。下流のABRの動的な選択を備えたERO拡張のおかげで計算されたパスの場合、選択したダウンストリームABRから宛先までの実行可能なパスがない場合、クランクバックルーティングを使用できます。アップストリーム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）セットアップ障害がある可能性があることに注意してください。ここで、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.
クランクバックは、エリア間の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を多様にルーティングする必要があります。もう1つの例は、異なるIGPエリアに居住するLSRのペア間に複数の多様なLSPをセットアップするための要件です。たとえば、帯域幅の制約を満たす単一のTE LSPが2つのエンドポイント間で見つからない場合、帯域幅の合計が帯域幅要件を満たすように複数のTe LSPをセットアップすることで解決策が構成されます。この場合、2つのエンドポイント間のトラフィックに対する障害の影響を最小限に抑えるために、これらのTELSPを多様にルーティングすることが望ましい場合があります。
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).
したがって、このソリューションは、多様なパスが存在する場合、多様にルーティングされたインターエリア間LSPを確立できる必要があります。あらゆる種類の多様性（Link、Node、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領域に存在するエリア間LSPの場合、エリア内およびエリア間実行可能なパスがある可能性があります。最短経路がエリア間経路である場合、オペレーターは可能な限り避け、したがって、最適なエリア内パスを選択することを好むかもしれません。、たとえそれがエリアを横断しても。したがって、このソリューションにより、ヘッドエンドとテールエンドが同じIGP領域に存在するTE LSPの場合、IGPエリアの交差を有効化/無効にする必要があります。
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.
ソリューションは、より最適なパスがトラバースされたIGP領域に現れた場合、エリア間のLSPを最小限に抑える（休憩前に）再現する能力を提供する必要があります。オペレーターは、タイマーまたはイベント駆動型ベースに従って、このような再最適化をパラメーター化できる必要があります。また、そのような再最適化を手動でトリガーすることも可能です。
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.
このソリューションは、エリア内で地域間LSPを局所的に再現する機能を提供する必要があります。すなわち、同じ輸送ABRのセットを保持しながら。その場合の再最適化プロセスは、エリア間LSPのヘッドエンドLSRまたはABRによって制御される場合があります。ABRは、タイマーまたはイベント駆動型ベースでITを通じて確立されたインターエリア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が下流の領域により最適な経路の存在を通知し、再オプチミー化プロセスを厳密に制御する能力を提供する必要があります。。したがって、一部の下流のIGP領域でより最適なパスについて通知されると、エリア間ヘッドエンドLSRは、局間によると、ブレイク前の再最適化を優雅に実行することを決定することができました。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/リンク/ノードの障害またはプリエンプションの場合の、インターエアリーLSPの再ルーティングをサポートする必要があります。このような再ルーティングは、ヘッドエンドLSRまたはABRによって制御される場合があります（Crankbackのセクション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).
ソリューションは、迅速な回復から利益を得る能力を提供する必要があります。これは、エリア内ネットワーク要素障害（link/srlg/node）の場合の両方との両方で、[ファストリアウト]で指定されたローカル保護技術を利用しています。ABRノードの障害。ネットワークのさまざまな部分でさまざまな保護技術を使用して、インターエアリー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）を使用してインターエアリーLSPをサポートする場合、[高速延長]を使用したABRの保護により、帯域幅の消費量が高くなり、回復遅延が高くなります。ABRを保護するために[Fast-Reroute]の使用は、同じレベルのパフォーマンスを保証しますが、現在、エンドツーエンドのRSVPセッション（連続LSP）を使用する必要があります。したがって、このソリューションは、A-AREA LSPの使用を許可または排除するために、A-A-AREA 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ソリューションは、[DSTE-REQ]で文書化されたコア要件を満たし、現在のエリア内MPLS DS-TEメカニズム[DSTE-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に運ぶことができるように、エリア間TE-LSP凝集（LSPネスティングとも呼ばれます）を許可する必要があります。たとえば、そのようなメカニズムの1つは[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ソリューションは、2つのモデルをサポートする必要があります。
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で定義されている要件に従って、先制型のインターエアリーLSPを再ルーティングする必要があります。
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で定義されている要件に従って、先制型のインターエアリーLSPを再最適化する必要があります。
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メッシュのLSRSメンバーを自動的に発見できるようにする発見メカニズムを提供することが望ましい場合があります。発見メカニズムは、複数の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の場合、現在、トラフィックをエリア内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 Next-Hopアドレスへの静的ルートを備えた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は、IPリーチビリティ情報（OSPFの要約LSAおよびISISのIPリーチビリティTLV）を伝播します。これは、ヘッドエンドLSRがTE-LSPテールヘッドLSRを越えて宛先にトラフィックをルーティングするために使用できます（例：ASBR）。
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領域に存在しない場合、LSPソースへのトラフィックを引き付けるために、IGPへのリンクとしてのインターエアリー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) パスコストの観点から、計算されたエリア間LSPプライマリパスとバックアップパスの最適性。（2）独立した施設を保護するエリア間バックアップLSP間で帯域幅を共有する機能。（3）エリア間TE-LSPセットアップ時間（MSEC）。（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の展開は既存のMPLS TEメカニズムに影響を及ぼさないはずです。特に、このソリューションは、これらのLSRがエリア間手順に参加していない場合、エリア間拡張をサポートしていない輸送LSRの間にエリア間LSPのセットアップを可能にする必要があります。イラストの目的のために、ソリューションは、ABRのエンドポイントLSR、および潜在的に、ABRを保護する局所修理（PLR）のポイントでのみエリア間拡張を必要とする場合があります。
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.
Dimitri Papadimitriou、Adrian Farrel、Vishal Sharma、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
EMail: ting_wo.chung@bell.ca EMail: 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
EMail: raymond_zhang@infonet.com EMail: parantap.lahiri@mci.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN
Kenji Kumaki Kddi Corporation Garden Air Tower Iidabashi、Chiyoda-Ku、Tokyo 102-8460、日本
EMail: ke-kumaki@kddi.com
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirements levels", RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Malcolm、J.、Agogbua、J.、O'Dell、M。、およびJ. McManus、「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] Le Faucheur、F。およびW. Lai、「差別化されたサービス認識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.、Chiu、A.、Elwalid、A.、Widjaja、I。、およびX. Xiao、「インターネットトラフィックエンジニアリングの概要と原則」、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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：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] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to 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] Smit、H。およびT. Li、「トラフィックエンジニアリングの中間システム（IS-IS）拡張（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] Boyle、J.、Gill、V.、Hannan、A.、Cooper、D.、Awduche、D.、Christian、B。、およびW. Lai、「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] Pan、P.、ed。、Swallow、G.、ed。、およびA. Atlas、ed。、「LSP TunnelsのRSVP-TEへのFast Reroute Extensions」、RFC 4090、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-ping] Kompella、K.、Pan、P.、Sheth、N.、Cooper、D.、Swallow、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）処理」、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階層」は進行中です。
[MPLS-RECOV] Sharma, V. and F. Hellstrand, "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.
[MPLS-Recov] Sharma、V。およびF. Hellstrand、「マルチプロトコルラベルスイッチング（MPLS）ベースの回復のフレームワーク」、RFC 3469、2003年2月。
[CRANKBACK] Farrel, A., Ed., "Crankback Signaling Extensions for MPLS Signaling", Work in Progress.
[Crankback] Farrel、A.、ed。、「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] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、 "Multi-protocol差別化されたサービスのラベルスイッチング（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-Proto] Le Faucheur、F.、et al。、「差別化されたサービス認識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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスのアーキテクチャ」、RFC 2475、1998年12月。
[DIFF-AF] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[diff-af] Heinanen、J.、Baker、F.、Weiss、W。、およびJ. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[DIFF-EF] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[Diff-Ef] Davie、B.、Charny、A.、Bennet、J.C.、Benson、K.、Le Boudec、J.、Courtney、W.、Davari、S.、Firoiu、V。、およびD. Stiliadis、「迅速な転送PHB（ホップごとの動作）」、RFC 3246、2002年3月。
[MPLS-PREEMPT] Farrel, A., "Interim Report on MPLS Pre-emption", Work in Progress.
[MPLS-Preempt] Farrel、A。、「MPLS Pre-Emptionに関する暫定レポート」、進行中の作業。
[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.、Vedrenne、A.、Merckx、P。、およびT. Telkamp、「2番目のMPLSトラフィックエンジニアリング（TE）メトリックとしてのインテリアゲートウェイプロトコル（IGP）メトリックの使用」、BCP 87、RFC 3785、2004年5月。
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France
Jean-Louis Le Roux France Telecom 2、Avenue Pierre-Marzin 22307 Lannion Cedex France
EMail: jeanlouis.leroux@francetelecom.com
Jean-Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA - 01719 USA
Jean -Philippe Vasseur Cisco Systems、Inc。300 Beaver Brook Road Boxborough、MA -01719 USA
EMail: jpv@cisco.com
Jim Boyle
ジム・ボイル
EMail: jboyle@pdnets.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。