RFC5298 日本語訳
5298 Analysis of Inter-Domain Label Switched Path (LSP) Recovery. T.Takeda, Ed., A. Farrel, Ed., Y. Ikejiri, JP. Vasseur. August 2008. (Format: TXT=59894 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
ワーキンググループT.竹田、エドをネットワークでつないでください。コメントのために以下を要求してください。 5298年のNTTカテゴリ: エド情報のA.ファレル、古い犬のコンサルティングY.Ikejiri NTTコミュニケーションJP。 VasseurシスコシステムズInc.2008年8月
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.
保護と回復はMultiprotocol Label Switching(MPLS)とGeneralized 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".
様々な体系とプロセスは、Label Switched Paths(LSPs)をマルチドメイン環境に証明するために開発されました。 RFC4726でこれらについて議論します: 「相互ドメインMultiprotocolラベル切り換え交通工学のためのフレームワーク。」
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.
このドキュメントは保護へのこれらのテクニックとマルチドメインネットワークでの回復のアプリケーションを分析します。 このドキュメントのための主な焦点が終わりから終わりへのさまざまのTraffic Engineering(TE)LSPsをマルチドメインネットワークに設立するところにあります。
Takeda, et al. Informational [Page 1] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[1ページ]のRFC5298分析
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
1. 序論…3 1.1. 用語…3 1.2. ドメイン…4 1.3. 範囲を記録してください…5 1.4. 他の回復でテクニックに注意してください…6 1.5. シグナリングオプション…6 2. マルチドメインネットワークにおける多様性…6 2.1. マルチドメインネットワーク形態…7 2.2. ドメインで多様性に注意してください…8 3. 考える要素…9 3.1. スケーラビリティ対最適…9 3.2. 重要概念…10 4. さまざまのLSPセットアップは秘密性なしで計画されます…12 4.1. 管理構成…12 4.2. ギヤエンドの経路計算(マルチドメイン目に見えることがある)。12 4.3. 1ドメインあたりの経路計算…12 4.3.1. 連続した経路計算…13 4.3.2. 同時の経路計算…14 4.4. 相互ドメインの協力的な経路計算…15 4.4.1. 連続した経路計算…15 4.4.2. 同時の経路計算…15 5. さまざまのLSPセットアップは秘密性で計画されます…16 5.1. 管理構成…17 5.2. ギヤエンドの経路計算(マルチドメイン目に見えることがある)。17 5.3. 1ドメインあたりの経路計算…17 5.3.1. 連続した経路計算…18 5.3.2. 同時の経路計算…19 5.4. 相互ドメインの協力的な経路計算…20 5.4.1. 連続した経路計算…20 5.4.2. 同時の経路計算…20 6. ネットワーク形態の特定の問題…20 7. 問題を扱います…21 8. SRLGで多様性に注意してください…21 9. セキュリティ問題…21 10. 参照…22 10.1. 標準の参照…22 10.2. 有益な参照…22 11. 承認…25
Takeda, et al. Informational [Page 2] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[2ページ]のRFC5298分析
1. Introduction
1. 序論
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.
Multiprotocol Label Switching(MPLS)とGeneralized 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ネットワーク(ドメインはアドレス管理か経路のコンピュータの責任の一般的な球の中のネットワーク要素のどんな収集であるとも考えられる)は考えられています。 そのようなドメインに関する例はInteriorゲートウェイプロトコル(IGP)部門とAutonomous Systems(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交通工学にフレームワークを供給します。 それは、Label Switched Paths(LSPs)をマルチドメイン環境に証明するために様々な体系とプロセスを導入して、議論します。
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設立に追加複雑さを紹介します。 一般に、保護LSPsが彼らが保護する働くLSPsからさまざまの経路であることが必要です。 ただ一つの経路計算かどんな計画ポイントも端から端まで経路の多様性を両方の経路に決定できないので、これを達成するのはマルチドメイン環境で特にやりがいがあります。
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回復がわかるために様々な体系を分析します。 このドキュメントのための主な焦点が終わりから終わりへのさまざまのTraffic Engineering(TE)LSPsをマルチドメインネットワークに設立するところにあります。
1.1. Terminology
1.1. 用語
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回復のための用語、および相互ドメインLabel Switched Path(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は追加詳細を明らかにします。
Takeda, et al. Informational [Page 3] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[3ページ]のRFC5298分析
- 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がユーザトラフィック(例えば、1+1保護)を通常、操作して、輸送してさえいるとき、回復LSPはユーザトラフィックを運ぶかもしれません。 回復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]を見てください。 多様性は複数のLSPsの関係を意味します。(そこで、それらのLSPsは特定のタイプのリソース(例えば、リンク、ノード、または共有されたリスクリンク群(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.
さまざまのLSPsは負荷バランスをとることや回復などの様々な目的に使用されるかもしれません。 本書では、多様性の回復局面(明確に2交通工学(TE)LSPsの終わりから終わりへの多様性)は焦点です。 2さまざまのLSPsが働く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つのドメインのトポロジーとリソースに関する情報の保護について言及します。
1.2. Domain
1.2. ドメイン
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領域とAutonomous Systemsを含んでいます。ネットワークはGMPLS UserからネットワークへのInterface(UNI)の上で[RFC4208]にアクセスしました、そして、Layer One Virtual兵士のNetworks(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.
1つ以上のドメインを使用することに関する例の動機は保護を提供する目的のためのドメインの管理分離、スケーラビリティ、および工事を含んでいます。 これらの後者の「保護ドメイン」は終わりから終わりへのLSPsの長さかセグメントのために縁から縁への保護施設を提供します。
Takeda, et al. Informational [Page 4] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[4ページ]のRFC5298分析
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パラメタ(色や優先権などの)があるかもしれません。 そのようなシナリオでは、相互ドメインLSPsをセットアップするために、マッピング機能がドメイン管理者の間の政策協定に基づくTEパラメタを変えるのに必要であるかもしれません。
1.3. Document Scope
1.3. ドキュメント範囲
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).
LSPsに、様々なリカバリ技術があります。 TE LSPsに関しては、主要なテクニックは、終わりから終わりへの回復[RFC4872]と、Fast Reroute(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]はさまざまのLSPsのための要件について説明します。 多様性の様々なタイプがあります、そして、このドキュメントはノード、リンク、および共有されたリスクリンク群(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.
回復LSPsは1+1保護、1:1保護、または共有されたメッシュ回復に使用されるかもしれません。 しかしながら、経路の多様性のための要件、さまざまの経路を計算する方法、およびこれらのTE LSPsのシグナリングはすべての用途の向こう側に一般的です。 これらの話題はこのドキュメントのメイン範囲です。
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.
さまざまのLSPsが回復に加えた様々な目的に使用されるかもしれないことに注意してください。 例は負荷分散のためのものです、単独のノード障害の場合にトラフィック分裂を交通の流れの部分に制限するために。 このドキュメントはさまざまの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のさまざまのLSPs(セクション1.4を見る)の使用以外のリカバリ技術の分析。
Takeda, et al. Informational [Page 5] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[5ページ]のRFC5298分析
- Details of maintenance of diverse LSPs, such as re-optimization and
Operations and Maintenance (OAM).
- 再最適化や、OperationsやMaintenanceなどのさまざまのLSPs(OAM)のメインテナンスの詳細。
- Comparative evaluation of LSP setup schemes.
- LSPセットアップの比較評価は計画されます。
1.4. Note on Other Recovery Techniques
1.4. 他の回復でテクニックに注意してください。
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でマルチドメインネットワークでの速いRerouteとセグメント回復について説明します、そして、[RFC5151]のセクション5により詳細な分析を提供します。 このドキュメントはFast Rerouteのためのどんな追加分析とマルチドメインネットワークでのセグメント回復も含んでいません。
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を見てください)。
1.5. Signaling Options
1.5. シグナリングオプション
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.
相互ドメインTE LSPsを設立するための3つのシグナリングオプションがあります: 巣篭もり、隣接のLSPs、およびステッチ[RFC4726]。 さまざまのLSPセットアップのこのドキュメントにおける記述はオプションが使用したシグナリングと関連して不可知論者です、別の方法で指定されない場合。
Note that signaling option considerations for Fast Reroute and segment recovery are described in [RFC5151].
Fast Rerouteのためのシグナリングオプション問題とセグメント回復が[RFC5151]で説明されることに注意してください。
2. Diversity in Multi-Domain Networks
2. マルチドメインネットワークにおける多様性
This section describes some assumptions about achieving path diversity in multi-domain networks.
このセクションはマルチドメインネットワークで経路の多様性を達成することに関するいくつかの仮定について説明します。
Takeda, et al. Informational [Page 6] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[6ページ]のRFC5298分析
2.1. Multi-Domain Network Topology
2.1. マルチドメインネットワーク形態
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はマルチドメインネットワークtopologiesに関する例を示しています。 図1では、ドメインは直線的なトポロジーでつなげられます。 ノードAとLの間には、複数の経路がありますが、それらは皆、そのオーダーにおけるドメイン#1ドメイン#の2ドメインの#3、に交差しています。
+--Domain#1--+ +--Domain#2--+ +--Domain#3--+ | | | | | | | B------+---+---D-----E--+---+------J | | / | | \ / | | \ | | / | | \ / | | \ | | A | | H | | L | | \ | | / \ | | / | | \ | | / \ | | / | | C------+---+---F-----G--+---+------K | | | | | | | +------------+ +------------+ +------------+
+--ドメイン#1--+ +--ドメイン#2--+ +--ドメイン#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-----+
+-----ドメイン#2-----+ | | | E--------------F| | | | | | | | | +-+--------------+-+ | | | | +--ドメイン#1+--+ +-------+------+ | | | | | | | | | | | | | A----B--+---+--C----D| | | | | | | | | | | | | +------+-------+ +--+ドメイン#4--+| | +-+--------------+-+ | | | | | | | | | G--------------H| | | +-----ドメイン#3-----+
Figure 2: Meshed Domain Connectivity
図2: メシェドドメインの接続性
Takeda, et al. Informational [Page 7] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[7ページ]のRFC5298分析
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.
また、ドメインレベルルーティングは経路がそれが以前に出たドメイン(例えば、ドメイン#Xドメイン#Yドメイン#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が同次(構成、方針または何らかの外部のメカニズムを通した)における、同じセットのドメインに続くと思います。 すなわち、私たちは、ドメインメッシュトポロジーが各組の働きと回復LSPsのために直線的なドメイントポロジーに減少すると思います。
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個以上のドメイン境界ノードか相互ドメインリンク(異なったドメインに属す1組のドメイン境界ノードを接続するリンク)があるかもしれません。
- 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.
- ドメイン再突入は、範囲の外にあって、さらに考えられません。
2.2. Note on Domain Diversity
2.2. ドメインの多様性に関する注
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の経路の大部分に経路の多様性を確実にする方法です。
Takeda, et al. Informational [Page 8] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[8ページ]のRFC5298分析
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.
ドメインの多様性の操作の詳細はこのドキュメントの範囲を超えています。
3. Factors to Consider
3. 考える要素
3.1. Scalability versus Optimality
3.1. スケーラビリティ対最適
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つの闘争目的です。 それぞれのネットワーク操作によって、最適の意味が異なることに注意してください。 さまざまのLSPsの文脈の最適に関するいくつかの例は以下の通りです。
- 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で、より詳しくこれについて議論します。
Takeda, et al. Informational [Page 9] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[9ページ]のRFC5298分析
3.2. Key Concepts
3.2. 重要な考え
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.
シグナリング(Resource予約プロトコル-TE(RSVP-TE)の明白なRoute Object(ERO)による)における複数のドメインの向こう側に経路を指定して、使用される(RSVP-TE Record Route Object(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ネットワークと、L1VPNsです。
o Multi-domain path computation, per-domain path computation, and
inter-domain collaborative path computation
o マルチドメイン経路計算、1ドメインあたりの経路計算、および相互ドメインの協力的な経路計算
- 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.
そのようなネットワーク要素は、ギヤエンドLabel Switching Router(LSR)、Path Computation Element(PCE)[RFC4655]、またはNetwork Management Systemであるかもしれません(NMS)。 セクション4と5で経路計算のこの方法について議論します。
Takeda, et al. Informational [Page 10] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[10ページ]のRFC5298分析
- Per-domain path computation
- 1ドメインあたりの経路計算
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拡張を必要とします。 このようへの保護のないLSPsの設立は[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].
この体系では、経路計算は、シグナリングの前に通常して、協力PCEsの間でコミュニケーションを使用します。 そのような体系に関する例はBackward Recursive Path Computation(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.
複数の経路計算のテクニックを結合するのが可能ですが(働きと回復LSPsに異なったテクニックを使用するのを含んでいて)、詳細はこのドキュメントの範囲を超えています。
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が後で職階への変化として加えられるとき、適切ですが、また、働きと回復LSPsの両方が始めから設立されるとき、使用されるかもしれません。
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.
このアプローチを使用して、「罠」topologiesのLSPsに関してさまざまの経路を見つけるのは可能でないかもしれません。 その上、あいさつに従って、そのような連続した経路計算アプローチは「最適」のソリューションを選択するという見込みを明確な目標機能に減少させます。
- 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セットアップが秘密性のあるなしにかかわらずよることに注意してください、-、ドメイン構成。 1ドメインあたりの経路計算か相互ドメインの協力的な経路計算の選択、および連続した経路計算か同時の経路計算の選択はそうであることができます。それぞれの個々の組の働き/回復LSPsにおいて、断固としています。
Takeda, et al. Informational [Page 11] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[11ページ]のRFC5298分析
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で説明されます。
4. Diverse LSP Setup Schemes without Confidentiality
4. 秘密性のないさまざまのLSPセットアップ計画
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はドメイン秘密性が必要であるところで計画の同様の試験をします。
4.1. Management Configuration
4.1. 管理構成
[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]は働きと回復LSPsに、完全な明白な経路がギヤエンドにもかかわらず、どんなさらなる計算のときにも管理アプリケーションで指定されないか、またはシグナリング問題が必要であるこの経路計算のテクニックについて説明します。
4.2. Head-End Path Computation (with Multi-Domain Visibility)
4.2. ギヤエンドの経路計算(マルチドメイン目に見えることがある)
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]はこの経路計算のテクニックについて説明します。 働きと回復LSPsに、完全な明白な経路はギヤエンドにギヤエンド自体かPCEによって計算されます。 どちらの場合ではも、コンピューティング実体が複数のドメインにもかかわらず、どんなさらなる計算の向こう側にも完全なTE目に見えることを持っていないか、またはシグナリング問題が必要です。
4.3. Per-Domain Path Computation
4.3. 1ドメインあたりの経路計算
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、および3.3[RFC4726]が、この経路計算のテクニックについて説明します。 より詳細な手順は[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:
この計画では、ソースドメインを通る完全な厳しい経路が以下のどちらかで続いたので、働きと回復LSPsの明白な経路は指定されます:
- The complete list of boundary LSRs or domain identifiers (e.g.,
AS numbers) along the paths.
- 経路に沿った境界LSRsかドメイン識別子(例えば、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によって実行されます。
Takeda, et al. Informational [Page 12] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[12ページ]のRFC5298分析
There are two schemes for establishing diverse LSPs using per-domain computation. These are described Sections 4.3.1 and 4.3.2.
1ドメインあたりの計算を使用することでさまざまのLSPsを設立することの2つの計画があります。 これらは説明されたセクション4.3.1であり、4.3は.2です。
4.3.1. Sequential Path Computation
4.3.1. 連続した経路計算
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.
上述しているように、連続した経路計算の本題はさまざまの経路を保証できないということです。 1ドメインあたり1つの経路計算計画が適用されているところでは、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.
2番目の経路が最初の経路の詳細を報告するように合図されるとき、RSVP-TE EXCLUDE_ROUTE Object(XRO)[RFC4874]を使用できます。 ROUTE Objectが終わりから終わりへの保護のために[RFC4872]で定義したPRIMARY_PATH_が経路除外メカニズムとして意図しないで、このために使用されるべきでないことに注意されるべきです。
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]で説明されるように1ドメインあたりの経路計算を使用することで設立されます。 ドメイン秘密性は必要でないので、働く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が使用されているなら、PCEプロトコル[PCEP-XRO]にExclude Route Object(XRO)拡張子を使用することで避けられるべきリソースはPCEに通過できます、[PCEP。]
- 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で伝えられます。 合図されるLSP、およびそのコンテンツで避けなければならないXROリストノード、リンク、およびSRLGsは働く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の必要性について設立されるので、さまざまのLSPs(彼らが存在できても)を設立するのを保証できません。 働くLSPの経路を変更するのは、回復LSPのセットアップが妨げられるか、またはいくつかのリソースが共有されるならcrankbackのテクニック[RFC4920]を使用することで可能です。
Takeda, et al. Informational [Page 13] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[13ページ]のRFC5298分析
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 LSPsのセットの)の最適の度合いが最大限度でないかもしれないことに注意してください。
4.3.2. Simultaneous Path Computation
4.3.2. 同時の経路計算
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.
同時の経路計算は多様性要件が計算の過程の一部を形成するので1組のさまざまの経路を見つけるというより良い見込みを与えます。 1ドメインあたりの経路計算メカニズムには、考えるいくつかの局面があります。
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.
同時の経路計算は、働きと回復LSPsの経路が同時に計算されることを意味します。 私たちが1ドメインあたりの経路計算を考えているので、それぞれのドメインの境界でこれらの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)は最初のドメインの向こう側に1組のさまざまの経路を計算します。 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.
- aが回復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.
- それぞれのドメイン境界ルータが順番に1組を計算する、次のドメインの向こう側に経路をばらばらにならせてください。 働く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へのシグナリングメッセージのギヤエンドLSRまで回復LSPのフルパスを返します。 これで、さらなる経路計算の必要性なしでフルパスを使用することでギヤエンド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
説明されたメカニズムが、ドメインがいつかが以来存在さえするところで増えるのをまださまざまの経路の品揃えに保証できないというメモも内部連絡されました、さまざまの決断
Takeda, et al. Informational [Page 14] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[14ページ]のRFC5298分析
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.
解決策が見つけられても、解決策(すなわち、さまざまのTE LSPsのセット)の最適の度合いが最大限度でないかもしれないことに注意してください。
4.4. Inter-Domain Collaborative Path Computation
4.4. 相互ドメインの協力的な経路計算
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.
協力的な経路計算は異なったドメインに責任があるPCEsの間の協力を必要とします。 このアプローチは[RFC4726]のセクション3.4で説明されます。 後方の再帰的な経路計算(BRPC)[BRPC]はLSPsが設立される前にLSPsの経路がPCEsのコミュニケーションで完全に決定している協力的な経路計算のテクニックを提供します。 さまざまのLSPsにBRPCを使用する2つの方法が以下のセクションで述べられます。
4.4.1. Sequential Path Computation
4.4.1. 連続した経路計算
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].
連続した経路計算では、働くLSPの経路は、[BRPC]で説明されるように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をセットアップできました。 後者の場合では、回復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を妨げるかもしれないので、さまざまのLSPs(彼らが存在しても)を設立するのを保証できません。 そのようなシナリオでは、働きと回復LSPsの再最適化は、完全に多様な経路を達成するのに使用されるかもしれません。
4.4.2. Simultaneous Path Computation
4.4.2. 同時の経路計算
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は、同時に働きと回復LSPsの両方の経路を計算するために共同します。 両方のLSPsが単一のパスで計算されるので同時にLSPsに合図できる、連続する、ギヤエンドLSRの好みに従って。
Takeda, et al. Informational [Page 15] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[15ページ]のRFC5298分析
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]にSynchronization Vector(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.
この計画は、彼らが可能であるさまざまのLSPsを設立するのを保証できます、ドメインレベルルーティングがセクション2で説明されるように予定されると仮定して。 その上、いくつかの目的関数に関して最適になるようにTE LSPsの計算されたセットを保証できます。
5. Diverse LSP Setup Schemes with Confidentiality
5. 秘密性があるさまざまの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]はPCEsが経路秘密性を保存するのにどう経路キーを使用できるかを説明します、そして、[RSVP-PATH-KEY]で、経路キーがシグナリングにどう使用されるかがわかります。 経路キーがRSVP-TE EROsで合図されるならシグナリングが続くことができるように彼らを広げなければならないことに注意してください。 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セグメントをあらかじめ確立できます。 階層的なLSPs[RFC4206]として、または、セグメントをステッチするLSP[RFC5150]として終わりから終わりへのLSPsを支持するのにLSPセグメントを使用できます。
Takeda, et al. Informational [Page 16] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[16ページ]のRFC5298分析
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.
終わりから終わりへのLSPsは、まさしくドメインかドメイン境界ルータのシリーズを示しながら、合図されます。 各ドメインへのエントリーでは、既存の移-ドメイン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.
また、ERO拡大がドメイン境界で適用されれば終わりから終わりへの独身の隣接のLSP(LSPがトンネルを堀るか、またはステッチすることのない)をもたらす計画ではLSPセグメントの同じ概念が適用されるかもしれなくて、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セットアップ計画によるプロトコル拡大を必要とするかもしれません。 以下での計画では、機密保持の要求事項で働きと回復LSPsの経路に影響を与えないことに注意してください。
5.1. Management Configuration
5.1. 管理構成
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.
これは機密保持の要求事項を知らせるでしょう、ドメイン秘密性の面前でさえ終わりから端への経路を決定できるマネージメントシステムが存在するかもしれませんが、したがって、ギヤエンドLSRまでLSPシグナリングにフルパスを提供できません。
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.
したがって、管理アプリケーションで構成されるLSPsに関して、ギヤエンドLSRまで経路キーの使用と終わりから端への経路をドメインに交差するLSPセグメントを使用することで構成されなければならないか、または伝えなければなりません。
5.2. Head-End Path Computation (with Multi-Domain Visibility)
5.2. ギヤエンドの経路計算(マルチドメイン目に見えることがある)
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の経路を計算するのは、可能ではありません。
5.3. Per-Domain Path Computation
5.3. 1ドメインあたりの経路計算
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.
働くための1ドメインあたりの経路計算と回復LSPsはドメイン秘密性で実用的です。 秘密性制限が全くない時として、私たちは連続して同時の経路計算に関するケースを分離できます。
Takeda, et al. Informational [Page 17] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[17ページ]のRFC5298分析
5.3.1. Sequential Path Computation
5.3.1. 連続した経路計算
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]で説明されるように1ドメインあたりの正常なテクニックを使用するのに用意ができていると思うことができます。 しかしながら、秘密性問題のために、働く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.
aを計算するには、回復LSP(境界ノードがそれがエントリーを提供するドメインの中で働くLSPの経路を知る必要がある各ドメイン)のための経路をばらばらにならせてください。 最初のドメインの中でRSVP-TE RROに近づく手段を持っているとき、イングレスLSRに、これは簡単です。 その後のドメインでは、過程は、回復LSPが合図されるときドメイン境界ルータがどうにか働くLSPの経路を入手するのを必要とします。 LSPsがノードかSRLGさまざまであるなら働きと回復LSPsが同じ境界ルータを使用しないことに注意してください。
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の経路のセグメントに、ドメインの中で主要な経路を代入します。 したがって、ギヤエンド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.
回復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のそれぞれの秘密の経路セグメントをコード化できました。 これらのコード化されたセグメントは、除外としてEROに回復LSPに関して現れて、ドメイン境界ルータで解読することができました。
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.
- 回復のXROに働くLSPのアイデンティティを含むことができました。aが経路をばらばらにならせるのを示すLSPを見つけなければなりません。
This option could require a simple extension to the current XRO
specification [RFC4874] to allow LSP identifiers to be included.
このオプションは、LSP識別子が含まれているのを許容するために現在のXRO仕様[RFC4874]に単純拡大を必要とするかもしれません。
Takeda, et al. Informational [Page 18] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[18ページ]のRFC5298分析
It could also use the Association Object [RFC4872] to identify
the working LSP.
また、それは、働くLSPを特定するのに、Association Object[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によって使用されたドメイン境界ルータを含むだろうことですが、また、管理アプリケーションかstateful PCEsに基づく他の計画は開発されるかもしれません。
Clearly, the details of this alternative have not been specified.
明確に、この代替手段の詳細は指定されていません。
5.3.2. Simultaneous Path Computation
5.3.2. 同時の経路計算
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.
1ドメインあたりの同時の経路計算では、働く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の経路がドメインごとに計算されるように、移-ドメインLSPsは回復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セグメントの設立を要求できるように、ドメイン境界ルータの間の管理飛行機を通したコーディネートを必要とします。 [RFC4802]、TE MIBモジュール[RFC3812]でこれを達成できるでしょう。
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に関する識別子がAssociation Object[RFC4872]を使用している状態で、回復LSPに合図できます。
Takeda, et al. Informational [Page 19] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[19ページ]のRFC5298分析
- 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.
- 経路キー: LSRがセクション4.4.2でただ説明したギヤエンドまで回復LSPの経路は決定して、返すことができますが、各CPSを経路キーに取り替えます。 回復経路が合図されるとき、それぞれの経路キーは、広げられるのと、正しい経路を達成するために、ドメインドメインです。 これは、回復LSP(ドメイン境界のLSRかPCE)の経路を計算する実体がstatefulであることを必要とします。
5.4 Inter-Domain Collaborative Path Computation
5.4 相互ドメインの協力的な経路計算
Cooperative collaboration between PCEs is also applicable when domain confidentiality is required.
また、ドメイン秘密性が必要であるときに、PCEsの間の協力的な共同も適切です。
5.4.1. Sequential Path Computation
5.4.1. 連続した経路計算
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に供給されて、PCEsの間で交換された経路除外は[PCEP-XRO]で説明されるように経路キーを使用しなければなりません。
5.4.2. Simultaneous Path Computation
5.4.2. 同時の経路計算
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 Object[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セグメントアプローチがここで適切でないかもしれないことに注意してください。
6. Network Topology Specific Considerations
6. ネットワーク形態の特定の問題
In some specific network topologies the schemes for setting up diverse LSPs could be significantly simplified.
いくらかの特定のネットワークtopologiesでは、さまざまのLSPsをセットアップすることの計画をかなり簡素化できました。
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ケースを考えてください。 これは1番目と最後のドメインがそれぞれただ一つのノードだけを保管している3つのドメインの線形連続として見なされるかもしれません。 どんなBRPC手順もそのようなシナリオでは、経路計算の必要は全く1番目にないので必要であり、ソースと目的地ノードが持続してもドメインを持続しない、マルチ、家へ帰り
Takeda, et al. Informational [Page 20] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[20ページ]のRFC5298分析
7. Addressing Considerations
7. 問題を記述します。
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が無意味であるので、この問題はドメインの外でドメイン秘密性の使用と同様です、そして、同じテクニックを使用することで問題は解決できます。
8. Note on SRLG Diversity
8. SRLGで多様性に注意してください。
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のさまざまのLSPsを設立するために、いくつかの問題が必要です:
- 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.
- 回復LSPの経路の計算で除くSRLGsの1セットのしるし。
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パラメタに関するマッピングと同様です。
9. Security Considerations
9. セキュリティ問題
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]を始められるように説明されるように。
Takeda, et al. Informational [Page 21] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[21ページ]のRFC5298分析
Additional discussion of security considerations for MPLG/GMPLS networks can be found in [SECURITY-FW].
[SECURITY-FW]でMPLG/GMPLSネットワークのためのセキュリティ問題の追加議論を見つけることができます。
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.
このドキュメントはそれ自体について変更しません。追加セキュリティ対策を必要として、使用されるプロトコルで内在している信用モデルを変更しません。 注意、しかしながら、ドメイン秘密性(それはどんなドメインからのトポロジーと経路情報の秘密性ですも)がこのドキュメント、および多くのメカニズムが説明した重要な考慮すべき事柄であることは、ドメイン秘密性を保存するように本書では設計されています。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[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.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[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)要件を設計すること」でのRFC4216、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)を切り換えること」でのRFC4427(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] ファレル、A.、Vasseur、J.-P.、およびA.Ayyangar、「相互ドメインMultiprotocolラベル切り換え交通工学のための枠組み」、RFC4726(2006年11月)。
10.2. Informative References
10.2. 有益な参照
[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.ナドー、「Multiprotocolは交通工学(Te)管理情報ベース(MIB)と切り換え(MPLS)をラベルします」、RFC3812、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.Atlas(エド)は「LSP Tunnelsのために速くRSVP-Teに拡大を別ルートで送ります」、RFC4090、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のための要件は工学を取引します」、RFC4105、2005年6月。
Takeda, et al. Informational [Page 22] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[22ページ]のRFC5298分析
[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)を階層構造とラベルします」、RFC4206、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] ツバメ、G.、ドレイク、J.、Ishimatsu、H.、およびY.Rekhter、「一般化されたMultiprotocolはユーザネットワーク・インターフェース(UNI)と切り換え(GMPLS)をラベルします」。 「オーバレイモデルの資源予約プロトコル交通工学(RSVP-Te)サポート」、RFC4208、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、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.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[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.マニー、「一般化されたマルチプロトコルラベルの分析は(GMPLS)ベースの回収機構を切り換え(保護と王政復古を含んでいて)」でのRFC4428(2006年3月)。
[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)ベースの構造」、RFC4655、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.ファレル(エド))は、「Multiprotocolラベルの切り換え(GMPLS)交通技術管理部会を一般化しました」、RFC4802、2007年2月。
[RFC4847] Takeda, T., Ed., "Framework and Requirements for
Layer 1 Virtual Private Networks", RFC 4847, April
2007.
[RFC4847] 竹田、T.、エド、「仮想の兵士がネットワークでつなぐ層1のための枠組みと要件」、RFC4847、4月2007日
[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)回復を一般化しました」、RFC4872、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セグメント回復」、RFC4873は2007がそうするかもしれません。
Takeda, et al. Informational [Page 23] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[23ページ]のRFC5298分析
[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.De Cnodderは「資源予約プロトコル交通工学(RSVP-Te)までルート--拡大を除きます」、RFC4874、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に合図するCrankback」、RFC4920(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.ファレル)は「一般化されたMultiprotocolラベル切り換え交通工学(GMPLS Te)でステッチされる切り換えられた経路をラベルします」、RFC5150、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] ファレル、A.、エド、Ayyangar、A.、およびJP。 Vasseurに、「相互ドメインMPLSとGMPLSは工学を取引します--資源予約プロトコル交通工学(RSVP-Te)拡大」、RFC5151、2月2008日
[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)ラベルを設立するための1ドメインあたり1つの経路計算方法が経路(LSPs)を切り換えました」、RFC5152、2月2008
[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.、Bitar、N.、およびJL。 ル・ルー、「計算する中で相互ドメイン交通工学ラベル最も脆い後方の再帰的な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経路キー] 「キーベースのメカニズムを使用することで相互ドメイン経路計算におけるトポロジー秘密性を保存し」て、ブラッドフォード、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)」、処理中の作業、3月2008
[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.、竹田、T.、およびA.ファレル、「ルート除外のための経路計算要素通信プロトコル(PCEP)への拡大」は進行中(2008年7月)で働いています。
Takeda, et al. Informational [Page 24] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[24ページ]のRFC5298分析
[RSVP-PATH-KEY] Bradford, R., Vasseur, JP., and A. Farrel, "RSVP
Extensions for Path Key Support", Work in Progress,
May 2008.
[RSVP経路キー]ブラッドフォード、R.、Vasseur、JP、5月2008、A.ファレル、「経路の主要なサポートのためのRSVP拡張子」は進行中で働いています。
[SECURITY-FW] Fang, L., Ed., " Security Framework for MPLS and
GMPLS Networks", Work in Progress, July 2008.
[セキュリティ-FW] 牙、L.、エド、7月2008、「MPLSのためのセキュリティフレームワークとGMPLSネットワーク」は進行中で働いています。
11. Acknowledgments
11. 承認
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、井上一郎、一浩Fujihara、ディミトリ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竹田NTTネットワーク・サービスシステム研究所、3 9-11テロのNTT社の美土里町武蔵野市、東京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コミュニケーションズ株式会社新宿、オペラ市の新宿区東京塔3-20-2西163-1421、日本東京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
ビーバーブルック道路Boxborough、ジャンフィリップVasseurシスコシステムズInc.300MA01719米国はメールされます: jpv@cisco.com
Takeda, et al. Informational [Page 25] RFC 5298 Analysis of Inter-Domain LSP Recovery August 2008
竹田、他 相互ドメインLSP回復2008年8月の情報[25ページ]のRFC5298分析
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Takeda, et al. Informational [Page 26]
竹田、他 情報[26ページ]
一覧
スポンサーリンク
