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
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）と一般化MPLS（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）領域及び自律システム（のAS）が挙げられます。
[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の回復のための用語に、およびドメイン間ラベルスイッチパス（LSP）設定のためのフレームワークを提供する[RFC4726]に導入用語に精通していることを想定しています。主な用語はまた、相互AS 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.
- 回復の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リソースのいくつかの特定のタイプを共有しない複数のLSPの関係を意味する（例えば、リンク、ノード、または共有リスク・リンク・グループ（SRLG））。多様性はまた、互いに素と呼ばれています。
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]を参照してください。守秘義務は、そのドメイン外の人やアプリケーションによって視界からトポロジーと一つのドメインのリソースに関する情報の保護を指します。
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領域と自律システムを含みます。 [RFC4847] GMPLSのユーザネットワークインターフェイス（UNI）[RFC4208]を経由してアクセスし、一つの仮想プライベートネットワーク（L1VPNs）のレイヤネットワークは、マルチドメインネットワークの特殊なケースです。
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]、（GMPLSに）ローカル（パケット交換環境での）そのような高速リルート（FRR）[RFC4090]として保護、およびセグメント回復[RFC4873]です。
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.
1保護、または共有メッシュ回復：回復LSPは、1 + 1保護、1のために使用することができます。しかし、パスダイバーシティ、多様な経路を計算する方法、およびこれらのTE 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).
ドメインの多様性は、（つまり、一般的にのみ出入りドメインを有するパスの選択）は、マルチドメインネットワークにおける多様性の一の形態と見なすことができるが、これはこの文書の範囲外である（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.
ネスティング、連続したLSP、およびステッチ[RFC4726]：3つのシグナリングドメイン間TE LSPを確立するためのオプションがあります。多様な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
図2：メッシュ型ドメイン接続
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では、ドメインは、メッシュトポロジで接続されています。そこノードAとDの間の複数の経路があり、これらのパスは、同じドメインを交差しません。ドメイン間の接続性は、メッシュを形成する場合、ドメインレベルのルーティングは（さえ保護されていない場合のために）必要とされます。これはしっかりIPネットワークで使用される次ホップドメイン解像度/ディスカバリーメカニズムを用いて結合されています。
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.
ドメインレベルのルーティングも可能にすることができる「ドメイン再進入」パスが以前に終了したドメイン（例えば、ドメイン＃1 X-ドメイン＃Y-ドメイン＃1 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).
- マルチドメインネットワークトポロジについての仮定はありません。例えば、二つ以上のドメイン境界ノードまたはドメイン間リンク（異なるドメインに属するドメインの境界ノードの対を接続するリンク）が存在し得ます。
- 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個のドメインで使用されるパスは、別のドメイン内から可視であることは明らかです。
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.
ドメイントポロジと運用ポリシーの機密性が必要とされる場合、他のドメイン間での完全なパスを指定するか、または得ることができません。部分的なパスが指定されたドメイン識別子またはエロスとRROsのドメイン境界ルータのアドレスを使用して報告することができます。
Examples of this configuration are some forms of multi-AS networks (especially inter-provider networks), GMPLS-UNI networks, and L1VPNs.
この構成例は、マルチASのネットワーク（特にインタープロバイダネットワーク）、GMPLS-UNIネットワーク、及びL1VPNsのいくつかの形態です。
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の両方が最初から確立されたときにも使用することができます。
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]は、作業及び回復のLSPの完全な明示的な経路はヘッドエンドで管理アプリケーションによって指定され、そしてさらなる計算またはシグナリングの考慮が必要とされない、この経路計算技術が記載されています。
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のいずれかによってヘッドエンドで計算されます。いずれの場合においても、コンピューティングエンティティは、複数のドメインにわたる完全なTEの可視性となし、さらに計算を有するか、またはシグナルの考慮が必要です。
Sections 3.2.2, 3.2.3, and 3.3 of [RFC4726] describe this path computation technique. More detailed procedures are described in [RFC5152].
セクション3.2.2、3.2.3、および[RFC4726]の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:
この方式では、作業や回復LSPの明示的なパスは、次のいずれかに続いて、ソースドメインを介して完全な厳格なパスとして指定されています。
- The complete list of boundary LSRs or domain identifiers (e.g., AS numbers) along the paths.
- 経路に沿った境界のLSRまたはドメイン識別子（例えば、AS番号）の完全なリスト。
- 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.
先に述べたように、逐次経路計算の主な問題は、多様な経路が保証されないことです。毎ドメイン経路計算方式が適用される場合、第二の経路の計算は、パスダイバーシチを図ることができるようにするために、最初のパスで使用されるパスを認識する必要があります。
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]は使用することができます。エンドツーエンドの保護のために[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.
- [RFC5152]に記載されているように働いてLSPはドメインごとの経路計算を使用して確立されます。ドメインの機密性が必要とされていないので、作業LSPのパスは、RSVP-TE RROによるヘッドエンドで利用可能です。
- 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が使用される場合、回避すべきリソースが[PCEP]、PCEプロトコル[PCEP-XRO]に除外ルートオブジェクト（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のRROからコピーされたLSPで避けなければならないノード、リンクおよびSRLGsを示しています。
- 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.
- 後続の各ドメインの境界で、回復LSPの経路のセグメントは、RSVP-TE XROに示されているリソースを除く新しいドメインを横切って計算することができます。
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.
溶液が発見されたとしても、（すなわち、多様なTE 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.
- 入口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.
説明されたメカニズムは、まだ彼らは以来存在していても、多様な経路の選択を保証することができないことにも注意してください、ドメインが多重相互接続される場合、多様なエンドツーエンドパスの決意は、ドメイン間リンクの正しい選択に依存してもよいです。クランクバック[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.
溶液が発見された場合でも、溶液の最適の程度（すなわち、多様なTE 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に記載されています。後方再帰経路計算（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の経路は、その後、作業LSPの経路を明示的に[PCEP-XRO]に記載XRO経路排除技術を使用して除外されることを添加し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が計算され、回復のパスの前または後に設定することができます。回復LSPの経路を計算するとき、後者の場合には、RSVP-TE RROで報告されているように働いて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.
同時経路計算では、のPCEは、同時に作業と回復の両方の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.
共同同時経路計算は、[PCEP] PCEプロトコルにおける同期ベクター（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.
この方式は、彼らが可能であり、多様なLSPを確立するように保証することができ、またセクション2で説明したように、ドメインレベルのルーティングが予め決定されたと仮定すると、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.
このセクションの文脈において、用語の機密性は、そのドメイン外の人やアプリケーションによって視界から一つのドメイン内に存在するトポロジとリソースに関する情報の保護に適用されます。これには、しかし、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の経路をPCEによって生成されたときと、通知されたときにパスキーがLSPの経路のセグメントの代わりに使用されます。このことは、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]パスキーがパスの機密性を保持するためのPCEによって使用することができる方法を説明し、[RSVP-PATH-KEY]はパスキーはシグナリングに使用される方法について説明します。パスのキーはRSVP-TEエロスに通知された場合にシグナリングを進めることができるように、彼らが展開されなければならないことに注意してください。 CPSの最初のノードに到達したとき、この拡張は、通常行われます。パスキーの膨張は、通常、キーを生成PCEによって行われるであろう、そしてその理由のために、パスキーは、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 [RFC4206]として、またはLSPステッチセグメント[RFC5150]として、エンドツーエンドのLSPをサポートするために使用することができます。
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トンネルまたはステッチなし）を生じる方式で、LSPセグメントの同じ概念がERO拡張がドメイン境界で適用されることを条件とのパスことを適用することができることも注目に値しますLSPは、RSVP-TE RROで報告されていません。
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-TE RROへのアクセス権を持っているとして、入力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.
- パスキーが働くLSPのためにRROに使用することができます。シグナリングメッセージがバックヘッドエンドLSRへの伝播されるように、各ドメインの境界ルータは、そのドメイン内の作動LSPのパスのセグメントのパスのキーを代入します。したがって、RROは、ヘッドエンドで受信されたLSRは、パス・キーの一連続く最初のドメイン内経路から成ります。
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.
回復LSPを通知されたときに、パスキーが除外としてEROに含めることができます。順番に各ドメイン境界ルータは、そのドメインのパスのキーを拡張し、リソースは避けなければならないかを知ることができます。 PCEPは、PCEとして、またはいくつかのサードパーティからワーキングLSPによって使用されるドメイン境界ルータからの経路のキーの拡張を要求するために使用することができるプロトコルを提供します。
- 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.
また、作業LSPを識別するために、関連オブジェクト[RFC4872]を使用することができます。
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で使用されるドメイン境界ルータを含めることが、管理アプリケーションまたはステートフルのPCEに基づいて他のスキームも開発されるかもしれないだろう。
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は、[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の経路が決定され、ヘッドエンドLSRに戻すことができるだけのセクション4.4.2に記載したが、各CPSは、パスキーによって置き換えられます。回復パスが通知されるように、各パスのキーは、正しいパスを達成するために、ドメインごとのドメインに拡張されます。これは、回復LSP（ドメイン境界LSRまたはPCE）のパスを計算エンティティがステートフルであることが必要です。
Cooperative collaboration between PCEs is also applicable when domain confidentiality is required.
ドメインの機密性が必要なときのPCE間の協同組合の協力を適用することも可能です。
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の経路が計算されるとパスの除外は、PCEに供給され、[PCEP-XRO]に記載されているようにパスキーを使用しなければならないのPCEの間で交換（ワーキングLSPがシグナリングされる前または後であってもよいです）。
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は、ドメイン間の多様な経路計算のために拡張することができます。ただし、ドメインの機密性の要件に適合するように、パスのキーは、RSVP-TEでのPCEによって返されたと合図パスで使用する必要があります。
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.
異なるドメインのノードとリンクが通常の場合で異なるSRLGs、に属している場合は、この文書に記載方式が適用可能です。
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で使用されるSRLGsの記録。
- Indication of a set of SRLGs to exclude in the computation of the recovery LSP's path.
- SRLGsのセットの表示が回復LSPの経路の計算で除外します。
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あります。 [PCEP] [RFC3209]に記載されたように、これらのプロトコルは、ポリシー及び認証機能を含みます。さらに、これらのプロトコルは、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "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]張、R.、編、及びJ.-P. Vasseur、エド。、 "MPLSインター自律システム（AS）トラフィックエンジニアリング（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]マニー、E.、エド。、およびD. Papadimitriou、エド。、 "リカバリ（保護と回復）一般化マルチプロトコルラベルスイッチング（GMPLS）のための用語"、RFC 4427、2006月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726]ファレル、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]スリニバサン、C.、Viswanathanの、A.、およびT.ナドー、 "マルチプロトコルラベルスイッチング（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]パン、P.、エド。、ツバメ、G.、エド。、およびA.アトラス編、 "高速リルート機能拡張LSPトンネルのための-TEをRSVPする"、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]ル・ルー、J.-L.、エド。、Vasseur、J.-P.、エド。、およびJ.ボイル、エド。、 "エリア間MPLSトラフィックエンジニアリングのための要件"、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は、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[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]ツバメ、G.、ドレイク、J.、石松、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]ケント、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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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.、エド。、及びE.マニー、エド。、RFC 4428、2006年3月 "一般化マルチプロトコルラベルスイッチング（GMPLS）の分析は、（保護と復旧を含む）の回復メカニズムをベース"。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（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]ナドー、T.、エド。、およびA.ファレル、エド。、 "一般化マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング管理情報ベース"、RFC 4802、2007年2月。
[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007.
[RFC4847]武田、T.、エド。、 "フレームワークおよびレイヤ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]ラング、J.、エド。、Rekhter、Y.、エド。、およびD. Papadimitriou、エド。、「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]バーガー、L.、Bryskin、I.、Papadimitriou、D.、およびA.ファレル、 "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]リー、CY、ファレル、A.、およびS.デCnodderは、 "ルートの除外 - 拡張をリソースへの予約プロトコル - トラフィックエンジニアリング（RSVP-TE）"、RFC 4874、2007年4月。
[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]ファレル、A.編、Satyanarayana、A.、岩田、A.、藤田、N.、およびG.アッシュ、 "MPLSおよびGMPLS RSVP-TEのためのクランクバックシグナリング拡張"、RFC 4920、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.ファレルは、2008年2月、RFC 5150 "ラベルは、トラフィックエンジニアリング（TE GMPLS）をスイッチング汎用マルチプロトコルラベルとステッチスイッチパス"。
[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]ファレル、A.編、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。、エド。、Ayyangar、A.編、およびR.張は、 "ドメイン単位の経路計算方法のために確立するドメイン間トラフィックエンジニアリング（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。、編、張、R.、ビタール、N.、およびJL。ル・ルー、進歩、2008年4月に、仕事を「最短ドメイン間トラフィックエンジニアリングラベルを計算するために、後方再帰PCEベースの計算（BRPC）手順は、パスの交換しました」。
[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]ブラッドフォード、R.、Vasseur、JP。、およびA.ファレル、進歩、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。、編、およびJL。ル・ルー、エド。、 "パス計算要素（PCE）通信プロトコル（PCEP）"、進歩、2008年3月での作業。
[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]沖、E.、武田、T.、およびA.ファレル、進歩、2008年7月に仕事 "ルートの除外のためにパス計算要素通信プロトコル（PCEP）への拡張"。
[RSVP-PATH-KEY] Bradford, R., Vasseur, JP., and A. Farrel, "RSVP Extensions for Path Key Support", Work in Progress, May 2008.
[RSVP-PATH-KEY]ブラッドフォード、R.、Vasseur、JP。、およびA.ファレル、 "パスキーのサポートのためのRSVP拡張機能"、進歩、2008年5月での作業。
[SECURITY-FW] Fang, L., Ed., " Security Framework for MPLS and GMPLS Networks", Work in Progress, July 2008.
[SECURITY-FW]牙、L.、エド。、 "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.
著者は、貴重なコメントのために大木英司、井上一郎、和弘藤原、ディミトリPapadimitriou、およびMeral Shirazipourに感謝したいと思います。デボラBrungardは、テキストに関する有益なアドバイスを提供しました。
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 Japan EMail : 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
ゆいち いけじり んっｔ こっむにかちおんｓ こｒぽらちおん ときょ おぺら しｔｙ とうぇｒ ３ー２０ー２ にし しんじゅく、 しんじゅくーく ときょ １６３ー１４２１、 じゃぱん えまいｌ： ｙ。いけじり＠んっｔ。こｍ
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
エードリアンファレル老犬のコンサルティングメール：adrian@olddog.co.uk
Jean-Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: jpv@cisco.com
ジャン=フィリップVasseurシスコシステムズ社300ビーバーブルック・ロードボックスボロー、MA 01719 USA電子メール：jpv@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。