[要約] RFC 5298は、インタードメインのラベルスイッチパス（LSP）の回復に関する分析を提供しています。その目的は、インタードメインLSPの回復メカニズムを評価し、ネットワークの信頼性と可用性を向上させることです。
Network Working Group T. Takeda, Ed.
Request for Comments: 5298 NTT
Category: Informational A. Farrel, Ed.
Old Dog Consulting
Y. Ikejiri
NTT Communications
JP. Vasseur
Cisco Systems, Inc.
August 2008
Analysis of Inter-Domain Label Switched Path (LSP) Recovery
ドメイン間ラベルスイッチドパス（LSP）回復の分析
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.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
Protection and recovery are important features of service offerings in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networks are being extended from single domain scope to multi-domain environments.
保護と回復は、マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPL（GMPLS）ネットワークのサービス提供の重要な機能です。ますます、MPLSおよびGMPLSネットワークは、単一のドメインスコープからマルチドメイン環境に拡張されています。
Various schemes and processes have been developed to establish Label Switched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering".
マルチドメイン環境でラベルスイッチパス（LSP）を確立するために、さまざまなスキームとプロセスが開発されています。これらについては、RFC 4726で説明されています。「ドメイン間マルチプロトコルラベルスイッチングトラフィックエンジニアリングのフレームワーク」。
This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks.
このドキュメントは、マルチドメインネットワークでの保護と回復へのこれらの手法の適用を分析します。このドキュメントの主な焦点は、マルチドメインネットワークでエンドツーエンドの多様なトラフィックエンジニアリング（TE）LSPを確立することです。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Domain .....................................................4
1.3. Document Scope .............................................5
1.4. Note on Other Recovery Techniques ..........................6
1.5. Signaling Options ..........................................6
2. Diversity in Multi-Domain Networks ..............................6
2.1. Multi-Domain Network Topology ..............................7
2.2. Note on Domain Diversity ...................................8
3. Factors to Consider .............................................9
3.1. Scalability versus Optimality ..............................9
3.2. Key Concepts ..............................................10
4. Diverse LSP Setup Schemes without Confidentiality ..............12
4.1. Management Configuration ..................................12
4.2. Head-End Path Computation (with Multi-Domain Visibility) ..12
4.3. Per-Domain Path Computation ...............................12
4.3.1. Sequential Path Computation ........................13
4.3.2. Simultaneous Path Computation ......................14
4.4. Inter-Domain Collaborative Path Computation ...............15
4.4.1. Sequential Path Computation ........................15
4.4.2. Simultaneous Path Computation ......................15
5. Diverse LSP Setup Schemes with Confidentiality .................16
5.1. Management Configuration ..................................17
5.2. Head-End Path Computation (with Multi-Domain Visibility) ..17
5.3. Per-Domain Path Computation ...............................17
5.3.1. Sequential Path Computation ........................18
5.3.2. Simultaneous Path Computation ......................19
5.4. Inter-Domain Collaborative Path Computation ...............20
5.4.1. Sequential Path Computation ........................20
5.4.2. Simultaneous Path Computation ......................20
6. Network Topology Specific Considerations .......................20
7. Addressing Considerations ......................................21
8. Note on SRLG Diversity .........................................21
9. Security Considerations ........................................21
10. References ....................................................22
10.1. Normative References .....................................22
10.2. Informative References ...................................22
11. Acknowledgements ..............................................25
Protection and recovery in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks are described in [RFC4428]. These are important features for service delivery in MPLS and GMPLS networks.
マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPLS（GMPLS）ネットワークの保護と回復は、[RFC4428]で説明されています。これらは、MPLSおよびGMPLSネットワークでのサービス提供のための重要な機能です。
MPLS and GMPLS networks were originally limited to single domain environments. Increasingly, multi-domain MPLS and GMPLS networks are being considered, where a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes).
MPLSおよびGMPLSネットワークは、もともと単一ドメイン環境に限定されていました。ますます、マルチドメインMPLSおよびGMPLSネットワークが考慮されています。ドメインは、アドレス管理またはパス計算責任の共通領域内のネットワーク要素のコレクションと見なされます。このようなドメインの例には、インテリアゲートウェイプロトコル（IGP）領域と自律システム（ASES）が含まれます。
[RFC4726] provides a framework for inter-domain MPLS and GMPLS traffic engineering. It introduces and discusses the various schemes and processes to establish Label Switched Paths (LSPs) in multi-domain environments.
[RFC4726]は、ドメイン間MPLSおよびGMPLSトラフィックエンジニアリングのフレームワークを提供します。マルチドメイン環境でラベルスイッチパス（LSP）を確立するためのさまざまなスキームとプロセスを導入および議論します。
However, protection and recovery introduce additional complexities to LSP establishment. Protection LSPs are generally required to be path diverse from the working LSPs that they protect. Achieving this is particularly challenging in multi-domain environments because no single path computation or planning point is capable of determining path diversity for both paths from one end to the other.
ただし、保護と回復により、LSP施設に追加の複雑さが導入されます。保護LSPは一般に、保護する動作LSPから多様であることが必要です。これを達成することは、マルチドメイン環境で特に困難です。なぜなら、単一のパス計算または計画ポイントは、片方の端から他方のパスのパスの多様性を決定することができないからです。
This document analyzes various schemes to realize MPLS and GMPLS LSP recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks.
このドキュメントでは、さまざまなスキームを分析して、マルチドメインネットワークでMPLSおよびGMPLS LSP回復を実現します。このドキュメントの主な焦点は、マルチドメインネットワークでエンドツーエンドの多様なトラフィックエンジニアリング（TE）LSPを確立することです。
The reader is assumed to be familiar with the terminology for LSP recovery set out in [RFC4427], and with the terms introduced in [RFC4726] that provides a framework for inter-domain Label Switched Path (LSP) setup. Key terminology may also be found in [RFC4216] that sets out requirements for inter-AS MPLS traffic engineering.
読者は、[RFC4427]に設定されたLSP回復の用語と、[RFC4726]で導入された用語に精通していると想定されており、ドメイン間ラベルスイッチドパス（LSP）セットアップのフレームワークを提供します。主要な用語は、MPLSトラフィックエンジニアリングの要件を設定する[RFC4216]にも見られる場合があります。
The following key terms from those sources are used within this document.
これらのソースからの次の重要な用語は、このドキュメント内で使用されます。
- Domain: See [RFC4726]. A domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Note that nested domains continue to be out of scope. Section 1.2 provides additional details.
- ドメイン：[RFC4726]を参照してください。ドメインは、アドレス管理またはパス計算責任の共通の領域内のネットワーク要素の任意のコレクションと見なされます。ネストされたドメインは引き続き範囲外であることに注意してください。セクション1.2では、追加の詳細を示します。
- Working LSP: See [RFC4427]. The working LSP transports normal user traffic. Note that the term LSP and TE LSP will be used interchangeably.
- 作業LSP：[RFC4427]を参照してください。動作するLSPは、通常のユーザートラフィックを輸送します。LSPとTE LSPという用語は同じ意味で使用されることに注意してください。
- Recovery LSP: See [RFC4427]. The recovery LSP transports normal user traffic when the working LSP fails. The recovery LSP may also carry user traffic even when the working LSP is operating normally and transporting the user traffic (e.g., 1+1 protection). The recovery LSP is sometimes referred to as a protecting LSP.
- Recovery LSP：[RFC4427]を参照してください。回復LSPは、作業LSPが故障したときに通常のユーザートラフィックを輸送します。回復LSPは、作業LSPが正常に動作し、ユーザートラフィックを輸送している場合でも、ユーザートラフィックを運ぶ場合があります（例：1 1保護）。回復LSPは、保護LSPと呼ばれることがあります。
- Diversity: See [RFC4726]. Diversity means the relationship of multiple LSPs, where those LSPs do not share some specific type of resource (e.g., link, node, or shared risk link group (SRLG)). Diversity is also referred to as disjointness.
- 多様性：[RFC4726]を参照してください。多様性とは、これらのLSPが特定のタイプのリソース（リンク、ノード、または共有リスクリンクグループ（SRLG）など）を共有しない複数のLSPの関係を意味します。多様性は、ばらばらとも呼ばれます。
Diverse LSPs may be used for various purposes, such as load-balancing and recovery. In this document, the recovery aspect of diversity, specifically the end-to-end diversity of two traffic engineering (TE) LSPs, is the focus. The two diverse LSPs are referred to as the working LSP and recovery LSP.
多様なLSPは、負荷分散や回復など、さまざまな目的に使用できます。このドキュメントでは、多様性の回復の側面、特に2つのトラフィックエンジニアリング（TE）LSPのエンドツーエンドの多様性が焦点です。2つの多様なLSPは、作業LSPおよび回復LSPと呼ばれます。
- Confidentiality: See [RFC4216]. Confidentiality refers to the protection of information about the topology and resources of one domain from visibility by people or applications outside that domain.
- 機密性：[RFC4216]を参照してください。機密性とは、1つのドメインのトポロジーとリソースに関する情報の保護と、そのドメイン以外の人々またはアプリケーションによる視界からのリソースです。
In order to fully understand the issues addressed in this document, it is necessary to carefully define and scope the term "domain".
このドキュメントで扱われている問題を完全に理解するには、「ドメイン」という用語を慎重に定義し、範囲する必要があります。
As defined in [RFC4726], a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. Networks accessed over the GMPLS User-to-Network Interface (UNI) [RFC4208], and Layer One Virtual Private Networks (L1VPNs) [RFC4847] are special cases of multi-domain networks.
[RFC4726]で定義されているように、ドメインは、アドレス管理またはパスの計算責任の共通領域内のネットワーク要素の任意のコレクションと見なされます。このようなドメインの例には、IGP領域と自律システムが含まれます。GMPLSユーザーからネットワークインターフェイス（UNI）[RFC4208]でアクセスされ、1つの仮想プライベートネットワーク（L1VPNS）[RFC4847]をレイヤーするネットワークは、マルチドメインネットワークの特別なケースです。
Example motivations for using more than one domain include administrative separation, scalability, and the construction of domains for the purpose of providing protection. These latter "protection domains" offer edge-to-edge protection facilities for spans or segments of end-to-end LSPs.
複数のドメインを使用するための動機の例には、管理の分離、スケーラビリティ、および保護を提供する目的でドメインの構築が含まれます。これらの後者の「保護ドメイン」は、エンドツーエンドLSPのスパンまたはセグメントのエッジツーエッジ保護施設を提供します。
As described in [RFC4726], there could be TE parameters (such as color and priority) whose meanings are specific to each domain. In such scenarios, in order to set up inter-domain LSPs, mapping functions may be needed to transform the TE parameters based on policy agreements between domain administrators.
[RFC4726]で説明されているように、意味が各ドメインに固有のTEパラメーター（色や優先度など）がある可能性があります。このようなシナリオでは、ドメイン間LSPを設定するために、ドメイン管理者間のポリシー契約に基づいてTEパラメーターを変換するためにマッピング関数が必要になる場合があります。
This document analyzes various schemes to realize MPLS and GMPLS LSP recovery in multi-domain networks. It is based on the existing framework for multi-domain LSP setup [RFC4726]. Note that this document does not prevent the development of additional techniques where appropriate (i.e., additional to the ones described in this document). In other words, this document shows how the existing techniques can be applied.
このドキュメントでは、さまざまなスキームを分析して、マルチドメインネットワークでMPLSおよびGMPLS LSP回復を実現します。マルチドメインLSPセットアップ[RFC4726]の既存のフレームワークに基づいています。このドキュメントは、必要に応じて追加の手法の開発を妨げないことに注意してください（つまり、このドキュメントで説明されている手法に追加）。言い換えれば、このドキュメントは、既存の手法をどのように適用できるかを示しています。
There are various recovery techniques for LSPs. For TE LSPs, the major techniques are end-to-end recovery [RFC4872], local protection such as Fast Reroute (FRR) [RFC4090] (in packet switching environments), and segment recovery [RFC4873] (in GMPLS).
LSPにはさまざまな回復手法があります。TE LSPの場合、主要な手法はエンドツーエンドの回復[RFC4872]、高速リルート（FRR）[RFC4090]（パケットスイッチング環境）、セグメントリカバリ[RFC4873]（GMPLS）などの局所保護です。
The main focus of this document is the analysis of diverse TE LSP setup schemes that can be used in the context of end-to-end recovery. The methodology is to show different combinations of functional elements such as path computation and signaling techniques.
このドキュメントの主な焦点は、エンドツーエンドの回復のコンテキストで使用できる多様なTE LSPセットアップスキームの分析です。方法論は、パス計算やシグナル伝達手法などの機能要素のさまざまな組み合わせを示すことです。
[RFC4105] and [RFC4216] describe requirements for diverse LSPs. There are various types of diversity, and this document focuses on node, link, and shared risk link group (SRLG) diversity.
[RFC4105]および[RFC4216]は、多様なLSPの要件を説明しています。さまざまな種類の多様性があり、このドキュメントでは、ノード、リンク、および共有リスクリンクグループ（SRLG）の多様性に焦点を当てています。
Recovery LSPs may be used for 1+1 protection, 1:1 protection, or shared mesh restoration. However, the requirements for path diversity, the ways to compute diverse paths, and the signaling of these TE LSPs are common across all uses. These topics are the main scope of this document.
回復LSPは、1 1保護、1：1の保護、または共有メッシュの復元に使用できます。ただし、パスの多様性の要件、多様なパスを計算する方法、およびこれらのLSPのシグナル伝達は、すべての用途で一般的です。これらのトピックは、このドキュメントの主な範囲です。
Note that diverse LSPs may be used for various purposes in addition to recovery. An example is for load-balancing, so as to limit the traffic disruption to a portion of the traffic flow in case of a single node failure. This document does not preclude use of diverse LSP setup schemes for other purposes.
回復に加えて、さまざまな目的に多様なLSPが使用される場合があることに注意してください。例は、単一のノード障害の場合にトラフィックの破壊をトラフィックフローの一部に制限するために、負荷分散のためのものです。このドキュメントは、他の目的のために多様なLSPセットアップスキームの使用を妨げるものではありません。
The following are beyond the scope of this document.
以下は、このドキュメントの範囲を超えています。
- Analysis of recovery techniques other than the use of link, node, or SRLG diverse LSPs (see Section 1.4).
- リンク、ノード、またはSRLG多様なLSPの使用以外の回復手法の分析（セクション1.4を参照）。
- Details of maintenance of diverse LSPs, such as re-optimization and Operations and Maintenance (OAM).
- 再最適化や運用とメンテナンス（OAM）など、多様なLSPのメンテナンスの詳細。
- Comparative evaluation of LSP setup schemes.
- LSPセットアップスキームの比較評価。
Fast Reroute and segment recovery in multi-domain networks are described in Section 5.4 of [RFC4726], and a more detailed analysis is provided in Section 5 of [RFC5151]. This document does not cover any additional analysis for Fast Reroute and segment recovery in multi-domain networks.
マルチドメインネットワークの高速リルートとセグメントの回復は、[RFC4726]のセクション5.4で説明されており、[RFC5151]のセクション5でより詳細な分析が提供されています。このドキュメントでは、マルチドメインネットワークでの高速リルートおよびセグメントの回復に関する追加の分析をカバーしていません。
The recovery type of an LSP or service may change at a domain boundary. That is, the recovery type could remain the same within one domain, but might be different in the next domain or on the connections between domains. This may be due to the capabilities of each domain, administrative policies, or to topology limitations. An example is where protection at the domain boundary is provided by link protection on the inter-domain links, but where protection within each domain is achieved through segment recovery. This mixture of protection techniques is beyond the scope of this document.
LSPまたはサービスの回復タイプは、ドメイン境界で変更される場合があります。つまり、回復タイプは1つのドメイン内で同じままである可能性がありますが、次のドメインまたはドメイン間の接続で異なる場合があります。これは、各ドメインの能力、管理ポリシー、またはトポロジの制限が原因である可能性があります。例としては、ドメイン境界での保護がドメイン間リンクのリンク保護によって提供されますが、各ドメイン内の保護はセグメントリカバリを通じて達成されます。保護技術のこの混合は、このドキュメントの範囲を超えています。
Domain diversity (that is, the selection of paths that have only the ingress and egress domains in common) may be considered as one form of diversity in multi-domain networks, but this is beyond the scope of this document (see Section 2.2).
ドメインの多様性（つまり、侵入ドメインと退出ドメインのみが共通しているパスの選択）は、マルチドメインネットワークの多様性の1つの形態と見なされる場合がありますが、これはこのドキュメントの範囲を超えています（セクション2.2を参照）。
There are three signaling options for establishing inter-domain TE LSPs: nesting, contiguous LSPs, and stitching [RFC4726]. The description in this document of diverse LSP setup is agnostic in relation to the signaling option used, unless otherwise specified.
ドメイン間TELSPを確立するための3つのシグナル伝達オプションがあります：ネスティング、隣接するLSP、およびステッチ[RFC4726]。多様なLSPセットアップのこのドキュメントの説明は、特に指定されていない限り、使用されたシグナリングオプションに関連して不可知論されます。
Note that signaling option considerations for Fast Reroute and segment recovery are described in [RFC5151].
高速再ルートおよびセグメントの回復に関するシグナリングオプションの考慮事項は、[RFC5151]で説明されていることに注意してください。
This section describes some assumptions about achieving path diversity in multi-domain networks.
このセクションでは、マルチドメインネットワークのパスの多様性を達成することに関するいくつかの仮定について説明します。
Figures 1 and 2 show examples of multi-domain network topologies. In Figure 1, domains are connected in a linear topology. There are multiple paths between nodes A and L, but all of them cross domain#1- domain#2-domain#3 in that order.
図1と2は、マルチドメインネットワークトポロジの例を示しています。図1では、ドメインは線形トポロジに接続されています。ノードAとLの間には複数のパスがありますが、それらはすべて、ドメイン＃1-ドメイン＃2ドメイン＃3をその順序でクロスします。
+--Domain#1--+ +--Domain#2--+ +--Domain#3--+
| | | | | |
| B------+---+---D-----E--+---+------J |
| / | | \ / | | \ |
| / | | \ / | | \ |
| A | | H | | L |
| \ | | / \ | | / |
| \ | | / \ | | / |
| C------+---+---F-----G--+---+------K |
| | | | | |
+------------+ +------------+ +------------+
Figure 1: Linear Domain Connectivity
図1：線形ドメイン接続
+-----Domain#2-----+
| |
| E--------------F |
| | | |
| | | |
+-+--------------+-+
| |
| |
+--Domain#1-+--+ +-------+------+
| | | | | |
| | | | | |
| A----B--+---+--C----D |
| | | | | |
| | | | | |
+------+-------+ +--+-Domain#4--+
| |
+-+--------------+-+
| | | |
| | | |
| G--------------H |
| |
+-----Domain#3-----+
Figure 2: Meshed Domain Connectivity In Figure 2, domains are connected in a mesh topology. There are multiple paths between nodes A and D, and these paths do not cross the same domains. If inter-domain connectivity forms a mesh, domain-level routing is required (even for the unprotected case). This is tightly coupled with the next-hop domain resolution/discovery mechanisms used in IP networks.
図2：図2のメッシュドメイン接続性、ドメインはメッシュトポロジに接続されています。ノードAとDの間には複数のパスがあり、これらのパスは同じドメインを通過しません。ドメイン間接続がメッシュを形成する場合、ドメインレベルのルーティングが必要です（保護されていない場合でも）。これは、IPネットワークで使用されるNext-Hopドメイン解像度/発見メカニズムと密接に結びついています。
In this document, we assume that domain-level routing is given via configuration, policy, or some external mechanism, and that this is not part of the path computation process described later in this document.
このドキュメントでは、ドメインレベルのルーティングが構成、ポリシー、または外部メカニズムを介して提供され、これはこのドキュメントで後述するパス計算プロセスの一部ではないと仮定します。
Domain-level routing may also allow "domain re-entry" where a path re-enters a domain that it has previously exited (e.g., domain#X-domain#Y-domain#X). This requires specific considerations when confidentiality (described in Section 3.2) is required, and is beyond the scope of this document.
ドメインレベルのルーティングでは、パスが以前に終了したドメインに再び入る「ドメイン再突入」を許可する場合があります（例：ドメイン＃x-domain＃y-domain＃x）。これには、機密性（セクション3.2で説明）が必要であり、このドキュメントの範囲を超えている場合、特定の考慮事項が必要です。
Furthermore, the working LSP and the recovery LSP may or may not be routed along the same set of domains in the same order. In this document, we assume that the working LSP and recovery LSP follow the same set of domains in the same order (via configuration, policy or some external mechanism). That is, we assume that the domain mesh topology is reduced to a linear domain topology for each pair of working and recovery LSPs.
さらに、作業LSPおよび回復LSPは、同じ順序で同じドメインのセットに沿ってルーティングされる場合とルーティングされない場合があります。このドキュメントでは、作業LSPおよび回復LSPが同じ順序で同じドメインのセットに従うことを想定しています（構成、ポリシー、または外部メカニズムを介して）。つまり、ドメインメッシュトポロジは、作業および回復LSPの各ペアの線形ドメイントポロジに削減されると仮定します。
In summary,
要約すれば、
- There is no assumption about the multi-domain network topology. For example, there could be more than two domain boundary nodes or inter-domain links (links connecting a pair of domain boundary nodes belonging to different domains).
- マルチドメインネットワークトポロジについての仮定はありません。たとえば、2つ以上のドメイン境界ノードまたはドメイン間リンク（異なるドメインに属するドメイン境界ノードのペアを接続するリンク）がある可能性があります。
- It is assumed that in a multi-domain topology, the sequence of domains that the working LSP and the recovery LSP follow must be the same and is pre-configured.
- マルチドメイントポロジでは、作業LSPと回復LSPが同じでなければならないドメインのシーケンスが同じであり、事前に構成されている必要があると想定されています。
- Domain re-entry is out of scope and is not considered further.
- ドメインの再突入は範囲外であり、それ以上とは見なされません。
As described in Section 1.4, domain diversity means the selection of paths that have only the ingress and egress domains in common. This may provide enhanced resilience against failures, and is a way to ensure path diversity for most of the path of the LSP.
セクション1.4で説明されているように、ドメインの多様性は、共通のドメインと出口ドメインのみを持つパスの選択を意味します。これは、障害に対する回復力の強化を提供する可能性があり、LSPの大部分のパスの多様性を確保する方法です。
In Section 2.1, we assumed that the working LSP and the recovery LSP follow the same set of domains in the same order. Under this assumption, domain diversity cannot be achieved. However, by relaxing this assumption, domain diversity could be achieved, e.g., by either of the following schemes.
セクション2.1では、作業LSPと回復LSPが同じ順序で同じドメインのセットをたどると想定しました。この仮定では、ドメインの多様性を達成することはできません。ただし、この仮定をリラックスさせることで、ドメインの多様性を達成することができます。たとえば、次のスキームのいずれかによって。
- Consider domain diversity as a special case of SRLG diversity (i.e., assign an SRLG ID to each domain).
- ドメインの多様性をSRLG多様性の特別なケースと考えてください（つまり、各ドメインにSRLG IDを割り当てます）。
- Configure domain-level routing to provide domain-diverse paths (e.g., by means of AS_PATH in BGP).
- ドメインレベルのルーティングを構成して、ドメインダイバーパスを提供します（たとえば、BGPのAS_PATHによる）。
Further details of the operation of domain diversity are beyond the scope of this document.
ドメイン多様性の動作の詳細は、このドキュメントの範囲を超えています。
As described in [RFC4726], scalability and optimality are two conflicting objectives. Note that the meaning of optimality differs depending on each network operation. Some examples of optimality in the context of diverse LSPs are:
[RFC4726]で説明されているように、スケーラビリティと最適性は2つの矛盾する目的です。最適性の意味は、各ネットワーク操作によって異なることに注意してください。多様なLSPのコンテキストでの最適性のいくつかの例は次のとおりです。
- Minimizing the sum of their cost while maintaining diversity.
- 多様性を維持しながら、コストの合計を最小限に抑えます。
- Restricting the difference of their costs (for example, so as to minimize the delay difference after switch-over) while maintaining diversity.
- 多様性を維持しながら、コストの差を制限します（たとえば、スイッチオーバー後の遅延差を最小限に抑えるために）。
By restricting TE information distribution to only within each domain (and not across domain boundaries) as required by [RFC4105] and [RFC4216], it may not be possible to compute an optimal path. As such, it might not be possible to compute diverse paths, even if they exist. However, if we assume domain-level routing is given (as discussed in Section 2), it would be possible to compute diverse paths using specific computation schemes, if such paths exist. This is discussed further in Section 4.
[RFC4105]および[RFC4216]で要求されるように、各ドメイン内（ドメイン境界を越えてではない）内のみにTE情報の分布を制限することにより、最適なパスを計算することはできない場合があります。そのため、たとえ存在しても、多様なパスを計算することはできないかもしれません。ただし、ドメインレベルのルーティングが与えられていると仮定すると（セクション2で説明したように）、そのようなパスが存在する場合、特定の計算スキームを使用して多様なパスを計算することが可能です。これについては、セクション4でさらに説明します。
Three key concepts to classify various diverse LSP computation and setup schemes are presented below.
さまざまな多様なLSP計算およびセットアップスキームを分類するための3つの重要な概念を以下に示します。
o With or without confidentiality
o 機密性の有無にかかわらず
- Without confidentiality
- 機密性なし
It is possible to specify a path across multiple domains in signaling (by means of the Resource Reservation Protocol-TE (RSVP-TE) Explicit Route Object (ERO)), and to obtain record of the inter-domain path used (by means of the RSVP-TE Record Route Object (RRO)). In this case, it is clear that one domain has control over the path followed in another domain, and that the path actually used in one domain is visible from within another domain.
シグナル伝達の複数のドメイン間のパスを指定することができます（リソース予約プロトコル-TE（RSVP-TE）明示的ルートオブジェクト（ERO））、および使用されるドメイン間パスの記録を取得することができます（RSVP-TEレコードルートオブジェクト（RRO））。この場合、1つのドメインが別のドメインで続くパスを制御し、1つのドメインで実際に使用されるパスが別のドメイン内から表示されることは明らかです。
Examples of this configuration are multi-area networks, and some forms of multi-AS networks (especially within the same provider). In these cases, there is no requirement for confidentiality.
この構成の例は、マルチエリアネットワークと、いくつかの形式のマルチASネットワーク（特に同じプロバイダー内）です。これらの場合、機密性の要件はありません。
- With confidentiality
- 機密性を備えています
Where confidentiality of domain topology and operational policy is required, it is not possible to specify or obtain a full path across other domains. Partial paths may be specified and reported using domain identifiers or the addresses of domain border routers in the EROs and RROs.
ドメイントポロジと運用ポリシーの機密性が必要な場合、他のドメイン間のフルパスを指定または取得することはできません。部分的なパスを指定し、ドメイン識別子またはEROSおよびRROSのドメイン境界ルーターのアドレスを使用して報告できます。
Examples of this configuration are some forms of multi-AS networks (especially inter-provider networks), GMPLS-UNI networks, and L1VPNs.
この構成の例は、いくつかの形式のマルチASネットワーク（特にプロバイダー間ネットワーク）、GMPLS-UNIネットワーク、およびL1VPNです。
o Multi-domain path computation, per-domain path computation, and inter-domain collaborative path computation
o マルチドメインパス計算、ドメインごとのパス計算、およびドメイン間コラボレーションパス計算
- Multi-domain path computation
- マルチドメインパス計算
If a single network element can see the topology of all domains along the path, it is able to compute a full end-to-end path. Clearly, this is only possible where confidentiality is not required.
単一のネットワーク要素がパスに沿ったすべてのドメインのトポロジーを確認できる場合、完全なエンドツーエンドパスを計算できます。明らかに、これは機密性が不要な場合にのみ可能です。
Such a network element might be the head-end Label Switching Router (LSR), a Path Computation Element (PCE) [RFC4655], or a Network Management System (NMS). This mode of path computation is discussed in Sections 4 and 5.
このようなネットワーク要素は、ヘッドエンドラベルスイッチングルーター（LSR）、パス計算要素（PCE）[RFC4655]、またはネットワーク管理システム（NMS）です。このパス計算モードについては、セクション4および5で説明します。
- Per-domain path computation
- ドメインごとのパス計算
The path of an LSP may be computed domain-by-domain as LSP signaling progresses through the network. This scheme requires ERO expansion in each domain to construct the next segment of the path toward the destination. The establishment of unprotected LSPs in this way is covered in [RFC5152].
LSPのパスは、LSPシグナル伝達がネットワークを介して進行するため、ドメインごとに計算されます。このスキームでは、各ドメインでのERO拡張が必要であり、宛先に向かうパスの次のセグメントを構築します。このように保護されていないLSPの確立は、[RFC5152]でカバーされています。
- Inter-domain collaborative path computation
- ドメイン間共同パス計算
In this scheme, path computation is typically done before signaling and uses communication between cooperating PCEs. An example of such a scheme is Backward Recursive Path Computation (BRPC) [BRPC].
このスキームでは、通常、パス計算はシグナリングの前に行われ、協力PCE間の通信を使用します。このようなスキームの例は、後方再帰パス計算（BRPC）[BRPC]です。
It is possible to combine multiple path computation techniques (including using a different technique for the working and recovery LSPs), but details are beyond the scope of this document.
複数のパス計算手法を組み合わせることができます（作業および回復LSPに異なる手法を使用することを含む）が、詳細はこのドキュメントの範囲を超えています。
o Sequential path computation or simultaneous path computation
o シーケンシャルパス計算または同時パス計算
- Sequential path computation
- シーケンシャルパス計算
The path of the working LSP is computed without considering the recovery LSP, and then the path of the recovery LSP is computed. This scheme is applicable when the recovery LSP is added later as a change to the service grade, but may also be used when both the working and recovery LSPs are established from the start.
作業LSPの経路は、回復LSPを考慮せずに計算され、リカバリLSPの経路が計算されます。このスキームは、リカバリLSPがサービスグレードの変更として後で追加される場合に適用されますが、作業LSPと回復LSPの両方が最初から確立された場合にも使用できます。
Using this approach, it may not be possible to find diverse paths for the LSPs in "trap" topologies. Furthermore, such sequential path computation approaches reduce the likelihood of selecting an "optimal" solution with regards to a specific objective function.
このアプローチを使用して、「トラップ」トポロジーでLSPの多様なパスを見つけることができない場合があります。さらに、このようなシーケンシャルパス計算アプローチは、特定の目的関数に関して「最適な」ソリューションを選択する可能性を減らします。
- Simultaneous path computation
- 同時パス計算
The path of the working LSP and the path of the recovery LSP are computed simultaneously. In this scheme, it is possible to avoid trap conditions and it may be more possible to achieve an optimal result.
動作するLSPの経路と回復LSPのパスは、同時に計算されます。このスキームでは、トラップ条件を回避することが可能であり、最適な結果を達成することがより可能かもしれません。
Note that LSP setup, with or without confidentiality, depends on per-domain configuration. The choice of per-domain path computation or inter-domain collaborative path computation, and the choice between sequential path computation or simultaneous path computation can be determined for each individual pair of working/recovery LSPs.
機密性の有無にかかわらず、LSPセットアップはドメインごとの構成に依存することに注意してください。ドメインごとのパス計算またはドメイン間コラボレーションパス計算の選択、およびシーケンシャルパス計算または同時パス計算の選択は、作業/回復LSPの個々のペアごとに決定できます。
The analysis of various diverse LSP setup schemes is described in Sections 4 and 5, based on the concepts set out above.
さまざまな多様なLSPセットアップスキームの分析は、上記の概念に基づいて、セクション4および5で説明されています。
Some other considerations, such as network topology-specific considerations, addressing considerations, and SRLG diversity are described in Sections 6, 7, and 8.
ネットワークトポロジ固有の考慮事項、考慮事項への対処、SRLGの多様性など、他のいくつかの考慮事項については、セクション6、7、および8で説明します。
This section examines schemes for diverse LSP setup based on different path computation techniques assuming that there is no requirement for domain confidentiality. Section 5 makes a similar examination of schemes where domain confidentiality is required.
このセクションでは、ドメインの機密性には要件がないと仮定して、さまざまなパス計算手法に基づいて、多様なLSPセットアップのスキームを調べます。セクション5では、ドメインの機密性が必要なスキームの同様の調査を行います。
[RFC4726] describes this path computation technique where the full explicit paths for the working and recovery LSPs are specified by a management application at the head-end, and no further computation or signaling considerations are needed.
[RFC4726]は、作業および回復の完全な明示的なパスがヘッドエンドの管理アプリケーションによって指定され、それ以上の計算またはシグナル伝達の考慮事項が必要ないこのパス計算手法について説明します。
Section 3.2.1 [RFC4726] describes this path computation technique. The full explicit paths for the working and recovery LSPs are computed at the head-end either by the head-end itself or by a PCE. In either case, the computing entity has full TE visibility across multiple domains and no further computation or signaling considerations are needed.
セクション3.2.1 [RFC4726]については、このパス計算手法について説明します。作業および回復LSPの完全な明示的なパスは、ヘッドエンド自体またはPCEによってヘッドエンドで計算されます。どちらの場合でも、コンピューティングエンティティは複数のドメインにわたって完全な可視性を持ち、それ以上の計算またはシグナル伝達の考慮事項は必要ありません。
Sections 3.2.2, 3.2.3, and 3.3 of [RFC4726] describe this path computation technique. More detailed procedures are described in [RFC5152].
[RFC4726]のセクション3.2.2、3.2.3、および3.3は、このパス計算手法について説明します。より詳細な手順は[RFC5152]で説明されています。
In this scheme, the explicit paths of the working and recovery LSPs are specified as the complete strict paths through the source domain followed by either of the following:
このスキームでは、作業および回復の明示的なパスが、ソースドメインを通る完全な厳格なパスとして指定され、次のいずれかが次のいずれかを指定します。
- The complete list of boundary LSRs or domain identifiers (e.g., AS numbers) along the paths.
- パスに沿った境界LSRまたはドメイン識別子の完全なリスト（例：数字として）。
- The LSP destination.
- LSPの宛先。
Thus, in order to navigate each domain, the path must be expanded at each domain boundary, i.e., per-domain. This path computation is performed by the boundary LSR or by a PCE on its behalf.
したがって、各ドメインをナビゲートするには、各ドメイン境界、つまりドメインごとにパスを拡張する必要があります。このパス計算は、境界LSRまたはPCEによって実行されます。
There are two schemes for establishing diverse LSPs using per-domain computation. These are described Sections 4.3.1 and 4.3.2.
ドメインごとの計算を使用して、多様なLSPを確立するための2つのスキームがあります。これらは、セクション4.3.1および4.3.2に記載されています。
As previously noted, the main issue with sequential path computation is that diverse paths cannot be guaranteed. Where a per-domain path computation scheme is applied, the computation of second path needs to be aware of the path used by the first path in order that path diversity can be attempted.
前述のように、シーケンシャルパス計算の主な問題は、多様なパスを保証できないことです。ドメインごとのパス計算スキームが適用されている場合、2番目のパスの計算は、パスの多様性を試みるために、最初のパスで使用されるパスを認識する必要があります。
The RSVP-TE EXCLUDE_ROUTE Object (XRO) [RFC4874] can be used when the second path is signaled to report the details of the first path. It should be noted that the PRIMARY_PATH_ROUTE Object defined in [RFC4872] for end-to-end protection is not intended as a path exclusion mechanism and should not be used for this purpose.
RSVP-TE exclude_Routeオブジェクト（XRO）[RFC4874]を使用して、2番目のパスが信号を送信して最初のパスの詳細を報告するときに使用できます。エンドツーエンドの保護のために[RFC4872]で定義されているPrimary_Path_Routeオブジェクトは、パス除外メカニズムとして意図されておらず、この目的に使用するべきではないことに注意する必要があります。
The process for sequential path computation is as follows:
シーケンシャルパス計算のプロセスは次のとおりです。
- The working LSP is established using per-domain path computation as described in [RFC5152]. The path of the working LSP is available at the head-end through the RSVP-TE RRO since domain confidentiality is not required.
- 作業LSPは、[RFC5152]に記載されているように、ドメインごとのパス計算を使用して確立されます。ドメインの機密性は必要ないため、作業LSPのパスはRSVP-TERROを介してヘッドエンドで利用できます。
- The path of the recovery LSP across the first domain is computed excluding the resources used by the working LSP within that domain. If a PCE is used, the resources to be avoided can be passed to the PCE using the Exclude Route Object (XRO) extensions to the PCE Protocol [PCEP-XRO], [PCEP].
- 最初のドメインを横切る回復LSPのパスは、そのドメイン内の作業LSPが使用するリソースを除く計算されます。PCEを使用すると、PCEプロトコル[PCEP-XRO]、[PCEP]への除外ルートオブジェクト（XRO）拡張機能を使用して、避けるべきリソースをPCEに渡すことができます。
- The recovery LSP is now signaled across the first domain as usual, but the path of the working LSP is also conveyed in an RSVP-TE XRO. The XRO lists nodes, links and SRLGs that must be avoided by the LSP being signaled, and its contents are copied from the RRO of the working LSP.
- 回復LSPは通常どおり最初のドメインでシグナルにされますが、作業LSPの経路もRSVP-TE XROで伝達されます。XROには、シグナルがあるLSPが回避する必要があるノード、リンク、およびSRLGをリストし、その内容は動作LSPのRROからコピーされます。
- At each subsequent domain boundary, a segment of the path of the recovery LSP can be computed across the new domain excluding the resources indicated in the RSVP-TE XRO.
- 後続の各ドメイン境界で、RSVP-TE XROに示されているリソースを除く新しいドメイン全体で、リカバリLSPのパスのセグメントを計算できます。
This scheme cannot guarantee to establish diverse LSPs (even if they could exist) because the first (working) LSP is established without consideration of the need for a diverse recovery LSP. It is possible to modify the path of the working LSP using the crankback techniques [RFC4920] if the setup of the recovery LSP is blocked or if some resources are shared.
このスキームは、多様な（作業）LSPが多様な回復LSPの必要性を考慮せずに確立されるため、多様なLSPを確立することを保証することはできません（存在する可能性がある場合でも）。回復LSPのセットアップがブロックされている場合、または一部のリソースが共有されている場合、クランクバック技術[RFC4920]を使用して、作業LSPのパスを変更することができます。
Note that, even if a solution is found, the degree of optimality of the solution (i.e., of the set of diverse TE LSPs) might not be maximal.
ソリューションが見つかったとしても、溶液の最適性（つまり、多様なLSPのセット）は最大ではない可能性があることに注意してください。
Simultaneous path computation gives a better likelihood of finding a pair of diverse paths as the diversity requirement forms part of the computation process. In per-domain path computation mechanisms, there are several aspects to consider.
同時パス計算により、多様性要件が計算プロセスの一部を形成するため、多様なパスのペアを見つける可能性が高くなります。ドメインごとのパス計算メカニズムには、考慮すべきいくつかの側面があります。
Simultaneous path computation means that the paths of the working and recovery LSPs are computed at the same time. Since we are considering per-domain path computation, these two paths must be computed at the boundary of each domain.
同時パス計算とは、作業と回復のパスLSPが同時に計算されることを意味します。ドメインごとのパス計算を検討しているため、これらの2つのパスは各ドメインの境界で計算する必要があります。
The process for simultaneous path computation is as follows:
同時パス計算のプロセスは次のとおりです。
- The ingress LSR (or a PCE) computes a pair of diverse paths across the first domain. If a PCE is used, PCEP offers the ability to request disjoint paths.
- Ingress LSR（またはPCE）は、最初のドメイン全体で多様なパスのペアを計算します。PCEが使用されている場合、PCEPは分離パスを要求する機能を提供します。
- The working LSP is signaled across the first domain as usual, but must carry with it the requirement for a disjoint recovery LSP and the information about the path already computed for the recovery LSP across the first domain. In particular, the domain boundary node used by the recovery LSP must be reported.
- 作業LSPは、通常のように最初のドメインでシグナンスされますが、それと、否認回収LSPの要件と、最初のドメイン全体で回復LSPのために既に計算されたパスに関する情報を伝える必要があります。特に、リカバリLSPで使用されるドメイン境界ノードを報告する必要があります。
- Each domain boundary router, in turn, computes a pair of disjoint paths across the next domain. The working LSP is signaled as usual, and the computed path of the recovery LSP is collected in the signaling messages.
- 各ドメインの境界ルーターは、次のドメイン全体に一対の分離パスを計算します。作業LSPは通常どおり信号され、回復LSPの計算されたパスはシグナリングメッセージに収集されます。
- When the working LSP has been set up, the full path of the recovery LSP is returned to the head-end LSR in the signaling messages for the working LSP. This allows the head-end LSR to signal the recovery LSP using a full path without the need for further path computation.
- 作業LSPがセットアップされると、回復LSPのフルパスが、動作LSPのシグナリングメッセージのヘッドエンドLSRに戻ります。これにより、ヘッドエンドLSRは、さらなるパス計算を必要とせずにフルパスを使用してリカバリLSPを信号することができます。
Note that the signaling protocol mechanisms do not currently exist to collect the path of the recovery LSP during the signaling of the working LSP. Definition of protocol mechanisms are beyond the scope of this document, but it is believed that such mechanisms would be simple to define and implement.
作業LSPのシグナル伝達中に、回復LSPの経路を収集するために、シグナル伝達プロトコルメカニズムは現在存在しないことに注意してください。プロトコルメカニズムの定義はこのドキュメントの範囲を超えていますが、そのようなメカニズムは定義と実装が簡単であると考えられています。
Note also that the mechanism described is still not able to guarantee the selection of diverse paths even where they exist since, when domains are multiply interconnected, the determination of diverse end-to-end paths may depend on the correct selection of inter-domain links. Crankback [RFC4920] may also be used in combination with this scheme to improve the chances of success.
また、説明されているメカニズムは、ドメインが相互接続されている場合、多様なエンドツーエンドパスの決定は、ドメイン間リンクの正しい選択に依存する可能性があるため、それらが存在する場所であっても、多様なパスの選択を保証できないことに注意してください。。Crankback [RFC4920]は、このスキームと組み合わせて使用して、成功の可能性を改善することもできます。
Note that even if a solution is found, the degree of optimality of the solution (i.e., set of diverse TE LSPs) might not be maximal.
ソリューションが見つかったとしても、ソリューションの最適性（つまり、多様なLSPのセット）は最大ではない可能性があることに注意してください。
Collaborative path computation requires the cooperation between PCEs that are responsible for different domains. This approach is described in Section 3.4 of [RFC4726]. Backward recursive path computation (BRPC) [BRPC] provides a collaborative path computation technique where the paths of LSPs are fully determined by communication between PCEs before the LSPs are established. Two ways to use BRPC for diverse LSPs are described in the following sections.
共同パス計算には、異なるドメインに責任があるPCE間の協力が必要です。このアプローチは、[RFC4726]のセクション3.4で説明されています。Backward Recursive Path Computation（BRPC）[BRPC]は、LSPのパスがLSPが確立される前にPCE間の通信によって完全に決定される共同パス計算手法を提供します。多様なLSPにBRPCを使用する2つの方法については、次のセクションで説明します。
In sequential path computation, the path of the working LSP is computed using BRPC as described in [BRPC]. The path of the recovery LSP is then computed also using BRPC with the addition that the path of the working LSP is explicitly excluded using the XRO route exclusion techniques described in [PCEP-XRO].
順次パス計算では、[BRPC]で説明されているように、動作LSPのパスがBRPCを使用して計算されます。回復LSPの経路は、[PCEP-XRO]で説明されているXROルート除外技術を使用して、動作LSPの経路が明示的に除外されるという追加とともにBRPCを使用して計算されます。
In this case, the working LSP could be set up before or after the path of the recovery LSP is computed. In the latter case, the actual path of the working LSP as reported in the RSVP-TE RRO should be used when computing the path of the recovery LSP.
この場合、回復LSPの経路の前または後に作業LSPをセットアップできます。後者の場合、RSVP-TERROで報告されている作業LSPの実際のパスを使用する必要があります。
This scheme cannot guarantee to establish diverse LSPs (even if they exist) because the working LSP may block the recovery LSP. In such a scenario, re-optimization of the working and recovery LSPs may be used to achieve fully diverse paths.
このスキームは、作業LSPが回復LSPをブロックする可能性があるため、多様なLSPを確立することを保証することはできません（たとえ存在していても）。このようなシナリオでは、動作および回復の再最適化LSPを使用して、完全に多様なパスを達成することができます。
In simultaneous path computation, the PCEs collaborate to compute the paths of both the working and the recovery LSPs at the same time. Since both LSPs are computed in a single pass, the LSPs can be signaled simultaneously of sequentially according to the preference of the head-end LSR.
同時パス計算では、PCESは協力して、動作LSPと回復LSPの両方のパスを同時に計算します。両方のLSPは単一のパスで計算されるため、LSPはヘッドエンドLSRの好みに応じて連続的に同時にシグナルを受信できます。
Collaborative simultaneous path computation is achieved using the Synchronization Vector (SVEC) object in the PCE Protocol [PCEP]. This object allows two computation requests to be associated and made dependent. The coordination of multiple computation requests within the BRPC mechanism is not described in [BRPC]. It is believed that it is possible to specify procedures for such coordination, but the development of new procedures is outside the scope of this document.
PCEプロトコル[PCEP]の同期ベクトル（SVEC）オブジェクトを使用して、共同の同時パス計算が達成されます。このオブジェクトにより、2つの計算要求を関連付けて依存するようにします。BRPCメカニズム内の複数の計算要求の調整は、[BRPC]では説明されていません。このような調整の手順を指定することは可能であると考えられていますが、新しい手順の開発はこのドキュメントの範囲外です。
This scheme can guarantee to establish diverse LSPs where they are possible, assuming that domain-level routing is pre-determined as described in Section 2. Furthermore, the computed set of TE LSPs can be guaranteed to be optimal with respect to some objective functions.
このスキームは、セクション2で説明されているように、ドメインレベルのルーティングが事前に決定されていると仮定して、可能な場合に多様なLSPを確立することを保証できます。さらに、TE LSPの計算されたセットは、いくつかの目的関数に関して最適であることが保証できます。
In the context of this section, the term confidentiality applies to the protection of information about the topology and resources present within one domain from visibility by people or applications outside that domain. This includes, but is not limited to, recording of LSP routes, and the advertisements of TE information. The confidentiality does not apply to the protection of user traffic.
このセクションのコンテキストでは、機密性という用語は、そのドメインの外部の人々またはアプリケーションによる可視性から1つのドメイン内に存在するトポロジとリソースに関する情報の保護に適用されます。これには、LSPルートの記録とTE情報の広告が含まれますが、これらに限定されません。機密性は、ユーザートラフィックの保護には適用されません。
Diverse LSP setup schemes with confidentiality are similar to ones without confidentiality. However, several additional mechanisms are needed to preserve confidentiality. Examples of such mechanisms are:
機密性を備えた多様なLSPセットアップスキームは、機密性のないものに似ています。ただし、機密性を維持するには、いくつかの追加のメカニズムが必要です。そのようなメカニズムの例は次のとおりです。
- Path key: A path key is used in place of a segment of the path of an LSP when the LSP is signaled, when the path of the LSP is reported by signaling, or when the LSP's path is generated by a PCE. This allows the exact path of the LSP to remain confidential through the substitution of "confidential path segments" (CPSs) by these path keys.
- パスキー：LSPのパスのセグメントの代わりにパスキーは、LSPが信号を送られたとき、LSPの経路がシグナリングによって報告されるとき、またはLSPの経路がPCEによって生成されるときに使用されます。これにより、LSPの正確なパスは、これらのパスキーによる「機密パスセグメント」（CPSS）の置換を通じて機密を維持できます。
[PCE-PATH-KEY] describes how path keys can be used by PCEs to preserve path confidentiality, and [RSVP-PATH-KEY] explains how path keys are used in signaling. Note that if path keys are signaled in RSVP-TE EROs they must be expanded so that the signaling can proceed. This expansion normally takes place when the first node in the CPS is reached. The expansion of the path key would normally be carried out by the PCE that generated the key, and for that reason, the path key contains an identifier of the PCE (the PCE-ID).
[PCE-Path-Key]は、PSCEがパスの機密性を維持するためにPSCEがパスキーを使用する方法を説明し、[RSVP-Path-Key]は、シグナリングでパスキーがどのように使用されるかを説明します。RSVP-TE EROSでパスキーが信号を送られている場合、シグナリングが進むように拡張する必要があることに注意してください。この拡張は通常、CPSの最初のノードに到達したときに行われます。パスキーの拡張は通常、キーを生成したPCEによって実行されます。そのため、PATHキーにはPCE（PCE-ID）の識別子が含まれます。
- LSP segment: LSP segments can be pre-established across domains according to some management policy. The LSP segments can be used to support end-to-end LSPs as hierarchical LSPs [RFC4206] or as LSP stitching segments [RFC5150].
- LSPセグメント：LSPセグメントは、一部の管理ポリシーに従ってドメイン全体で事前に確立できます。LSPセグメントは、エンドツーエンドのLSPを階層LSP [RFC4206]またはLSPステッチセグメント[RFC5150]としてサポートするために使用できます。
The end-to-end LSPs are signaled indicating just the series of domains or domain border routers. Upon entry to each domain, an existing trans-domain LSP is selected and used to carry the end-to-end LSP across the domain.
エンドツーエンドのLSPは、一連のドメインまたはドメインボーダールーターのみを示すことを示すシグナル伝達されます。各ドメインに入力すると、既存のトランスドメインLSPが選択され、ドメイン全体にエンドツーエンドLSPを運ぶために使用されます。
Note that although the LSP segments are described as being pre-established, they could be set up on demand on receipt of the request for the end-to-end LSP at the domain border.
LSPセグメントは事前に確立されていると説明されていますが、ドメイン境界でエンドツーエンドLSPのリクエストを受け取ったときにオンデマンドでセットアップできることに注意してください。
It is also worth noting that in schemes that result in a single contiguous end-to-end LSP (without LSP tunneling or stitching), the same concept of LSP segments may apply provided that ERO expansion is applied at domain boundaries and that the path of the LSP is not reported in the RSVP-TE RRO.
また、単一の連続したエンドツーエンドLSP（LSPトンネルまたはステッチなし）をもたらすスキームでは、ERO拡張がドメイン境界で適用され、その経路が適用されると同じLSPセグメントの概念が適用される可能性があることも注目に値します。LSPはRSVP-TERROで報告されていません。
These techniques may be applied directly or may require protocol extensions depending on the specific diverse LSP setup schemes described below. Note that in the schemes below, the paths of the working and recovery LSPs are not impacted by the confidentiality requirements.
これらの手法は直接適用される場合があります。または、以下に説明する特定の多様なLSPセットアップスキームに応じて、プロトコル拡張を必要とする場合があります。以下のスキームでは、作業および回復のパスLSPが機密性の要件の影響を受けないことに注意してください。
Although management systems may exist that can determine end-to-end paths even in the presence of domain confidentiality, the full paths cannot be provided to the head-end LSR for LSP signaling as this would break the confidentiality requirements.
ドメインの機密性が存在する場合でもエンドツーエンドのパスを決定できる管理システムが存在する可能性がありますが、LSPシグナリングのヘッドエンドLSRにフルパスを提供することはできません。
Thus, for LSPs that are configured through management applications, the end-to-end path must either be constructed using LSP segments that cross the domains, or communicated to the head-end LSR with the use of path keys.
したがって、管理アプリケーションを介して構成されているLSPの場合、エンドツーエンドパスは、ドメインを横断するLSPセグメントを使用して構築するか、パスキーを使用してヘッドエンドLSRに通信する必要があります。
It is not possible for the head-end LSR to compute the full end-to-end path of an inter-domain LSP when domain confidentiality is in use because the LSR will not have any TE information about the other domains.
LSRが他のドメインに関するTE情報を持っていないため、ドメインの機密性が使用されている場合、ヘッドエンドLSRがドメイン間LSPの完全なエンドツーエンドパスを計算することはできません。
Per-domain path computation for working and recovery LSPs is practical with domain confidentiality. As when there are no confidentiality restrictions, we can separate the cases of sequential and simultaneous path computation.
作業および回復のためのドメインごとのパス計算LSPは、ドメインの機密性を備えた実用的です。機密保持制限がない場合、順次および同時パス計算のケースを分離できます。
In sequential path computation, we can assume that the working LSP has its path computed and is set up using the normal per-domain technique as described in [RFC5152]. However, because of confidentiality issues, the full path of the working LSP is not returned in the signaling messages and is not available to the head-end LSR.
順次パス計算では、動作LSPには[RFC5152]に記載されているように、通常のドメインごとの手法を使用して設定されていると仮定できます。ただし、機密性の問題のため、作業LSPのフルパスはシグナリングメッセージで返されず、ヘッドエンドLSRが利用できません。
To compute a disjoint path for the recovery LSP, each domain border node needs to know the path of the working LSP within the domain to which it provides entry. This is easy for the ingress LSR as it has access to the RSVP-TE RRO within first domain. In subsequent domains, the process requires that the path of the working LSP is somehow made available to the domain border router as the recovery LSP is signaled. Note that the working and recovery LSPs do not use the same border routers if the LSPs are node or SRLG diverse.
リカバリLSPの分離パスを計算するには、各ドメイン境界ノードがエントリを提供するドメイン内の動作LSPのパスを知る必要があります。これは、最初のドメイン内のRSVP-TERROにアクセスできるため、Ingress LSRにとって簡単です。後続のドメインでは、プロセスでは、回復LSPがシグナルになると、作業LSPのパスが何らかの形でドメインボーダールーターが利用できるようにする必要があります。LSPがノードまたはSRLG多様である場合、作業および回復LSPは同じ境界ルーターを使用しないことに注意してください。
There are several possible mechanisms to achieve this.
これを達成するためのいくつかの可能なメカニズムがあります。
- Path keys could be used in the RRO for the working LSP. As the signaling messages are propagated back towards the head-end LSR, each domain border router substitutes a path key for the segment of the working LSP's path within its domain. Thus, the RRO received at the head-end LSR consists of the path within the initial domain followed by a series of path keys.
- PATHキーは、作業LSPにRROで使用できます。シグナリングメッセージがヘッドエンドLSRに向かって伝播されると、各ドメインの境界ルーターは、ドメイン内の動作LSPのパスのセグメントのパスキーを置き換えます。したがって、ヘッドエンドLSRで受信したRROは、初期ドメイン内のパスに続いて一連のパスキーが続きます。
When the recovery LSP is signaled, the path keys can be included in the ERO as exclusions. Each domain border router in turn can expand the path key for its domain and know which resources must be avoided. PCEP provides a protocol that can be used to request the expansion of the path key from the domain border router used by the working LSP, or from some third party such as a PCE.
Recovery LSPが信号を送信すると、パスキーをEROに除外として含めることができます。各ドメインの境界ルーターは、ドメインのパスキーを拡張し、どのリソースを避けなければならないかを知ることができます。PCEPは、作業LSPが使用するドメインボーダールーター、またはPCEなどの一部の第三者からパスキーの拡張を要求するために使用できるプロトコルを提供します。
- Instead of using path keys, each confidential path segment in the RRO of the working LSP could be encrypted by the domain border routers. These encrypted segments would appear as exclusions in the ERO for the recovery LSP and could be decrypted by the domain border routers.
- パスキーを使用する代わりに、作業LSPのRROにある各機密パスセグメントは、ドメインボーダールーターによって暗号化される可能性があります。これらの暗号化されたセグメントは、回復LSPのEROの除外として表示され、ドメインの境界ルーターによって復号化される可能性があります。
No mechanism currently exists in RSVP-TE for this function, which would probably assume a domain-wide encryption key.
この関数のRSVP-TEには現在、メカニズムは存在しません。これは、おそらくドメイン全体の暗号化キーを想定しています。
- The identity of the working LSP could be included in the XRO of the recovery LSP to indicate that a disjoint path must be found.
- 作業LSPのアイデンティティを回復LSPのXROに含めて、ばらばらのパスを見つける必要があることを示すことができます。
This option could require a simple extension to the current XRO specification [RFC4874] to allow LSP identifiers to be included.
このオプションは、LSP識別子を含めるようにして、現在のXRO仕様[RFC4874]の単純な拡張機能を必要とする場合があります。
It could also use the Association Object [RFC4872] to identify the working LSP.
また、Associationオブジェクト[RFC4872]を使用して、作業LSPを識別することもできます。
This scheme would also need a way for a domain border router to find the path of an LSP within its domain. An efficient way to achieve this would be to also include the domain border router used by the working LSP in the signaling for the recovery LSP, but other schemes based on management applications or stateful PCEs might also be developed.
このスキームには、ドメインボーダールーターがドメイン内のLSPのパスを見つける方法も必要です。これを達成するための効率的な方法は、回復LSPのシグナリングで作業LSPが使用するドメイン境界ルーターを含めることですが、管理アプリケーションまたはステートフルなPCESに基づく他のスキームも開発される可能性があります。
Clearly, the details of this alternative have not been specified.
明らかに、この代替の詳細は指定されていません。
In per-domain simultaneous path computation the path of the recovery LSP is computed at the same time as the working LSP (i.e., as the working LSP is signaled). The computed path of the recovery LSP is propagated to the head-end LSR as part of the signaling process for the working LSP, but confidentiality must be maintained, so the full path cannot be returned. There are two options as follows.
ドメインごとの同時パス計算では、回復LSPの経路は、動作LSPと同時に計算されます（つまり、作業LSPがシグナルにされると）。回復LSPの計算されたパスは、作業LSPのシグナリングプロセスの一部としてヘッドエンドLSRに伝播されますが、機密性を維持する必要があるため、フルパスを返すことはできません。次の2つのオプションがあります。
- LSP segment: As the signaling of the working LSP progresses and the path of the recovery LSP is computed domain-by-domain, trans-domain LSPs can be set up for use by the recovery LSP. When the recovery LSP is signaled, it will pick up these LSP segments and use them for tunneling or stitching.
- LSPセグメント：作業LSPのシグナル伝達が進行し、回復LSPの経路がドメインごとに計算されると、ドメイントランスLSPを回復LSPで使用するために設定できます。リカバリLSPがシグナルになると、これらのLSPセグメントをピックアップし、トンネリングまたはステッチに使用します。
This mechanism needs coordination through the management plane between domain border routers so that a router on the working path can request the establishment of an LSP segment for use by the protection path. This could be achieved through the TE MIB modules [RFC3812], [RFC4802].
このメカニズムは、ドメインボーダールーター間の管理プレーンを介して調整を必要とするため、作業パス上のルーターが保護パスで使用するLSPセグメントの確立を要求できます。これは、Te MIBモジュール[RFC3812]、[RFC4802]を通じて達成できます。
Furthermore, when the recovery LSP is signaled it needs to be sure to pick up the correct LSP segment. Therefore, some form of LSP segment identifier needs to be reported in the signaling of the working LSP and propagated in the signaling of the recovery LSP. Mechanisms for this do not currently exist, but would be relatively simple to construct.
さらに、回復LSPがシグナルになった場合、正しいLSPセグメントを必ずピックアップする必要があります。したがって、何らかの形のLSPセグメント識別子を動作LSPのシグナル伝達に報告し、回復LSPのシグナルに伝播する必要があります。これのメカニズムは現在存在しませんが、構築するのは比較的簡単です。
Alternatively, the LSP segments could be marked as providing protection for the working LSP. In this case, the recovery LSP can be signaled with the identifier of the working LSP using the Association Object [RFC4872] enabling the correct LSP segments to be selected.
あるいは、LSPセグメントには、作業LSPの保護を提供するものとしてマークできます。この場合、回復LSPは、関連するLSP [RFC4872]を使用して、動作LSPの識別子を使用して、正しいLSPセグメントを選択できるようにすることができます。
- Path key: The path of the recovery LSP can be determined and returned to the head-end LSR just described in Section 4.4.2, but each CPS is replaced by a path key. As the recovery path is signaled each path key is expanded, domain-by-domain to achieve the correct path. This requires that the entity that computes the path of the recovery LSP (domain border LSR or PCE) is stateful.
- パスキー：回復LSPのパスを決定し、セクション4.4.2で説明したヘッドエンドLSRに戻すことができますが、各CPSはパスキーに置き換えられます。回復パスが合図されると、各パスキーが展開され、ドメインごとにdomainが展開され、正しいパスが実現されます。これには、リカバリLSP（ドメイン境界LSRまたはPCE）の経路を計算するエンティティがステートフルであることが必要です。
Cooperative collaboration between PCEs is also applicable when domain confidentiality is required.
PCES間の協力的なコラボレーションは、ドメインの機密性が必要な場合にも適用できます。
In sequential cooperative path computation, the path of the working LSP is determined first using a mechanism such as BRPC. Since domain confidentiality is in use, the path returned may contain path keys.
連続的な協調パス計算では、動作するLSPの経路は、BRPCなどのメカニズムを使用して最初に決定されます。ドメインの機密性が使用されているため、返されるパスにはパスキーが含まれている場合があります。
When the path of the recovery LSP is computed (which may be before or after the working LSP is signaled) the path exclusions supplied to the PCE and exchanged between PCEs must use path keys as described in [PCEP-XRO].
回復LSPの経路が計算される場合（動作するLSPの前後になる可能性があります）、PCEに供給され、PCE間で交換されるパス除外は、[PCEP-XRO]に記載されているようにパスキーを使用する必要があります。
As described in Section 4.4.2, diverse path computation can be requested using the PCEP SVEC Object [PCEP], and BRPC could be extended for inter-domain diverse path computation. However, to conform to domain confidentiality requirements, path keys must be used in the paths returned by the PCEs and signaled by RSVP-TE.
セクション4.4.2で説明したように、PCEP SVECオブジェクト[PCEP]を使用して多様なパス計算を要求でき、BRPCはドメイン間の多様なパス計算のために拡張できます。ただし、ドメインの機密性の要件に準拠するには、PCESによって返され、RSVP-TEによって信号を送信するパスでパスキーを使用する必要があります。
Note that the LSP segment approach may not be applicable here because a path cannot be determined until BRPC procedures are completed.
BRPC手順が完了するまでパスを決定できないため、LSPセグメントアプローチはここで適用できない場合があることに注意してください。
In some specific network topologies the schemes for setting up diverse LSPs could be significantly simplified.
一部の特定のネットワークトポロジでは、多様なLSPを設定するためのスキームが大幅に簡素化される可能性があります。
For example, consider the L1VPN or GMPLS UNI case. This may be viewed as a linear sequence of three domains where the first and last domains contain only a single node each. In such a scenario, no BRPC procedures are needed, because there is no need for path computation in the first and last domains even if the source and destination nodes are multi-homed.
たとえば、L1VPNまたはGMPLS UNIケースを検討してください。これは、最初と最後のドメインにそれぞれ単一のノードのみが含まれる3つのドメインの線形シーケンスと見なされる場合があります。このようなシナリオでは、ソースと宛先ノードがマルチホームであっても、最初と最後のドメインでパス計算が必要ないため、BRPC手順は必要ありません。
All of the schemes described in this document are applicable when a single address space is used across all domains.
このドキュメントで説明されているすべてのスキームは、すべてのドメインで単一のアドレススペースが使用されている場合に適用されます。
There may also be cases where private address spaces are used within some of the domains. This problem is similar to the use of domain confidentiality since the ERO and RRO are meaningless outside a domain even if they are available, and the problem can be solved using the same techniques.
一部のドメイン内でプライベートアドレススペースが使用される場合もあります。この問題は、EROとRROが利用可能であってもドメインの外側では無意味であり、同じ手法を使用して問題を解決できるため、ドメインの機密性の使用に似ています。
The schemes described in this document are applicable when the nodes and links in different domains belong to different SRLGs, which is normally the case.
このドキュメントで説明されているスキームは、異なるドメインのノードとリンクが異なるSRLGに属している場合に適用されます。これは通常そうです。
However, it is possible that nodes or links in different domains belong to the same SRLG. That is, an SRLG may span domain boundaries. In such cases, in order to establish SRLG diverse LSPs, several considerations are needed:
ただし、異なるドメインのノードまたはリンクが同じSRLGに属している可能性があります。つまり、SRLGはドメイン境界にまたがる場合があります。そのような場合、SRLG多様なLSPを確立するために、いくつかの考慮事項が必要です。
- Record of the SRLGs used by the working LSP.
- 作業LSPが使用するSRLGの記録。
- Indication of a set of SRLGs to exclude in the computation of the recovery LSP's path.
- 回復LSPの経路の計算で除外するSRLGのセットの兆候。
In this case, there is a conflict between any requirement for domain confidentiality, and the requirement for SRLG diversity. One of the requirements must be compromised.
この場合、ドメインの機密性の要件とSRLGの多様性の要件との間には矛盾があります。要件の1つを侵害する必要があります。
Furthermore, SRLG IDs may be assigned independently in each domain, and might not have global meaning. In such a scenario, some mapping functions are necessary, similar to the mapping of other TE parameters mentioned in Section 1.2.
さらに、SRLG IDは各ドメインで個別に割り当てられ、グローバルな意味がない場合があります。このようなシナリオでは、セクション1.2に記載されている他のTEパラメーターのマッピングと同様に、一部のマッピング関数が必要です。
The core protocols used to achieve the procedures described in this document are RSVP-TE and PCEP. These protocols include policy and authentication capabilities as described in [RFC3209] and [PCEP]. Furthermore, these protocols may be operated using more advanced security features such as IPsec [RFC4301] and TLS [RFC4346].
このドキュメントで説明されている手順を達成するために使用されるコアプロトコルは、RSVP-TEおよびPCEPです。これらのプロトコルには、[RFC3209]および[PCEP]で説明されているポリシーと認証機能が含まれます。さらに、これらのプロトコルは、IPSEC [RFC4301]やTLS [RFC4346]などのより高度なセキュリティ機能を使用して動作する場合があります。
Security may be regarded as particularly important in inter-domain deployments and serious consideration should be given to applying the available security techniques, as described in the documents referenced above and as set out in [RFC4726].
セキュリティは、ドメイン間の展開において特に重要であると見なされる場合があり、上記の文書に記載されているように、[RFC4726]に記載されているように、利用可能なセキュリティ手法を適用するために深刻な考慮を払う必要があります。
Additional discussion of security considerations for MPLG/GMPLS networks can be found in [SECURITY-FW].
MPLG/GMPLSネットワークのセキュリティに関する考慮事項に関する追加の議論は、[Security-FW]にあります。
This document does not of itself require additional security measures and does not modify the trust model implicit in the protocols used. Note, however, that domain confidentiality (that is the confidentiality of the topology and path information from within any one domain) is an important consideration in this document, and a significant number of the mechanisms described in this document are designed to preserve domain confidentiality.
このドキュメントは、それ自体が追加のセキュリティ対策を必要とするものではなく、使用されるプロトコルに暗黙のモデルを変更しません。ただし、ドメインの機密性（つまり、任意のドメイン内からのトポロジー情報とパス情報の機密性）は、このドキュメントで重要な考慮事項であり、このドキュメントで説明されているメカニズムのかなりの数がドメインの機密性を維持するように設計されていることに注意してください。
[RFC3209] 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.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、12月2001年。
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216] Zhang、R.、ed。、およびJ.-P。Vasseur、ed。、「MPLS Inter-autonomous System（AS）Traffic Engineering（TE）要件」、RFC 4216、2005年11月。
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4427] Mannie、E.、ed。、およびD. Papadimitriou、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）の回復（保護および回復）用語」、RFC 4427、2006年3月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726] Farrel、A.、Vasseur、J.-P。、およびA. Ayyangar、「ドメイン間マルチプロトコルラベルスイッチングトラフィックエンジニアリングのフレームワーク」、RFC 4726、2006年11月。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）管理情報ベース（MIB）」、RFC 3812、2004年6月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090] Pan、P.、Ed。、Ed。、Swallow、G.、Ed。、およびA. Atlas、ed。、「LSP TunnelsのRSVP-TEへの拡張速度」、RFC 4090、2005年5月。
[RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle, Ed., "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105] Le Roux、J.-L.、ed。、vasseur、J.-P.、ed。、およびJ. Boyle、ed。、「A-A-Area MPLS Traffic Engineeringの要件」、RFC 4105、2005年6月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K。およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチ付きパス（LSP）階層」、2005年10月。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC4208] Swallow、G.、Drake、J.、Ishimatsu、H。、およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）ユーザーネットワークインターフェイス（UNI）：リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）オーバーレイモデルのサポート」、RFC 4208、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[RFC4428] Papadimitriou, D., Ed., and E. Mannie, Ed., "Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)", RFC 4428, March 2006.
[RFC4428] Papadimitriou、D.、ed。、およびE. Mannie、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）ベースの回復メカニズム（保護と修復を含む）の分析」、RFC 4428、2006年3月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007.
[RFC4802] Nadeau、T.、ed。、およびA. Farrel、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング管理情報ベース」、RFC 4802、2007年2月。
[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007.
[RFC4847] Takeda、T.、ed。、「レイヤー1仮想プライベートネットワークのフレームワークと要件」、RFC 4847、2007年4月。
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872] Lang、J.、ed。、Rekhter、Y.、ed。、およびD. Papadimitriou、ed。、「RSVP-TE拡張機能エンドツーエンド一般化マルチプロトコルラベルスイッチング（GMPLS）回復をサポートする"、RFC 4872、2007年5月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「Gmplsセグメントリカバリー」、RFC 4873、2007年5月。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4874] Lee、Cy。、Farrel、A。、およびS. de Cnodder、「除外ルート - リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）への拡張」、2007年4月、RFC 4874。
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC4920] Farrel、A.、ed。、Satyanarayana、A.、Iwata、A.、Fujita、N.、およびG. Ash、「MPLSおよびGMPLS RSVP-TEのクランクバックシグナル伝達拡張」、2007年7月。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC5150] Ayyangar、A.、Kompella、K.、Vasseur、Jp。、およびA. Farrel、「一般化されたマルチプロトコルラベルスイッチングトラフィックエンジニアリング（GMPLS TE）を使用したラベルスイッチパスステッチ」、RFC 5150、2008年2月。
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008.
[RFC5151] Farrel、A.、ed。、Ayyangar、A。、およびJp。Vasseur、「ドメイン間MPLSおよびGMPLSトラフィックエンジニアリング - リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 5151、2008年2月。
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008.
[RFC5152] Vasseur、JP。、ed。、Ayyangar、A.、ed。、およびR. Zhang、「ドメイン間トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）を確立するためのドメインごとのパス計算方法」、RFC 5152、2008年2月。
[BRPC] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Inter-Domain Traffic Engineering Label Switched Paths", Work in Progress, April 2008.
[BRPC] Vasseur、Jp。、ed。、Zhang、R.、Bitar、N。、およびJl。Le Roux、「最短のドメイン間トラフィックエンジニアリングラベルの切り替えパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、2008年4月の作業。
[PCE-PATH-KEY] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism", Work in Progress, May 2008.
[PCE-Path-Key] Bradford、R.、Vasseur、JP。、およびA. Farrel、「主要なメカニズムを使用したドメイン間パス計算のトポロジの機密性の保存」、2008年5月の進行中。
[PCEP] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", Work in Progress, March 2008.
[PCEP] Vasseur、Jp。、ed。、およびJl。Le Roux、ed。、「Path Computation Element（PCE）通信プロトコル（PCEP）」、2008年3月、Work in Progress。
[PCEP-XRO] Oki, E., Takeda, T., and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", Work in Progress, July 2008.
[PCEP-XRO] Oki、E.、Takeda、T。、およびA. Farrel、「ルート除外のパス計算要素通信プロトコル（PCEP）への拡張」、2008年7月の作業。
[RSVP-PATH-KEY] Bradford, R., Vasseur, JP., and A. Farrel, "RSVP Extensions for Path Key Support", Work in Progress, May 2008.
[RSVP-Path-Key] Bradford、R.、Vasseur、JP。、およびA. Farrel、「Path Key Support for Path Key Support for Path Key SupportのRSVP拡張」、2008年5月の作業。
[SECURITY-FW] Fang, L., Ed., " Security Framework for MPLS and GMPLS Networks", Work in Progress, July 2008.
[Security-FW] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、2008年7月、進行中の作業。
The authors would like to thank Eiji Oki, Ichiro Inoue, Kazuhiro Fujihara, Dimitri Papadimitriou, and Meral Shirazipour for valuable comments. Deborah Brungard provided useful advice about the text.
著者は、貴重なコメントをいただいてくれたEiji Oki、Ichiro、Kazuhiro Fujihara、Dimitri Papadimitriou、およびMeral Shirazipourに感謝したいと思います。デボラ・ブランガードは、テキストについて有用なアドバイスを提供しました。
Authors' Addresses
著者のアドレス
Tomonori Takeda NTT Network Service Systems Laboratories, NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan EMail : takeda.tomonori@lab.ntt.co.jp
Tomonori Takeda NTT Network Service Systems Laboratories、NTT Corporation 3-9-11、Midori-Cho Musashino-Shi、Tokyo 180-8585日本メール：takeda.tomonori@lab.ntt.co.jp
Yuichi Ikejiri NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan EMail: y.ikejiri@ntt.com
Yuichi ikejiri ntt Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku、Shinjuku-Ku Tokyo 163-1421、日本メール：Y.ikejiri@ntt.com
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel Old Dog Consultingメール：adrian@olddog.co.uk
Jean-Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: jpv@cisco.com
Jean-Philippe Vasseur Cisco Systems、Inc。300 Beaver Brook Road Boxborough、MA 01719 USAメール：jpv@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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への情報をお問い合わせください。