Network Working Group A. Farrel
Request for Comments: 4726 Old Dog Consulting
Category: Informational J.-P. Vasseur
Cisco Systems, Inc.
A. Ayyangar
Nuova Systems
November 2006
A Framework for Inter-Domain Multiprotocol Label Switching
Traffic Engineering
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
Abstract
抽象
This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks.
この文書では、マルチプロトコルラベルスイッチング（MPLS）を確立し、制御するためのフレームワークを提供し、一般化MPLS（GMPLS）交通エンジニア（TE）ラベルは、マルチドメインネットワークに（LSPを）パスを交換しました。
For the purposes of this document, 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).
このドキュメントの目的のために、ドメインはアドレス管理またはパス計算責任の共通の球内のネットワーク要素の任意の集合であると考えられています。そのようなドメインの例は、内部ゲートウェイプロトコル（IGP）領域及び自律システム（のAS）が挙げられます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Nested Domains .............................................3
2. Signaling Options ...............................................4
2.1. LSP Nesting ................................................4
2.2. Contiguous LSP .............................................5
2.3. LSP Stitching ..............................................5
2.4. Hybrid Methods .............................................6
2.5. Control of Downstream Choice of Signaling Method ...........6
3. Path Computation Techniques .....................................6
3.1. Management Configuration ...................................7
3.2. Head-End Computation .......................................7
3.2.1. Multi-Domain Visibility Computation .................7
3.2.2. Partial Visibility Computation ......................7
3.2.3. Local Domain Visibility Computation .................8
3.3. Domain Boundary Computation ................................8
3.4. Path Computation Element ...................................9
3.4.1. Multi-Domain Visibility Computation ................10
3.4.2. Path Computation Use of PCE When Preserving
Confidentiality ....................................10
3.4.3. Per-Domain Computation Elements ....................10
3.5. Optimal Path Computation ..................................11
4. Distributing Reachability and TE Information ...................11
5. Comments on Advanced Functions .................................12
5.1. LSP Re-Optimization .......................................12
5.2. LSP Setup Failure .........................................13
5.3. LSP Repair ................................................14
5.4. Fast Reroute ..............................................14
5.5. Comments on Path Diversity ................................15
5.6. Domain-Specific Constraints ...............................16
5.7. Policy Control ............................................17
5.8. Inter-Domain Operations and Management (OAM) ..............17
5.9. Point-to-Multipoint .......................................17
5.10. Applicability to Non-Packet Technologies .................17
6. Security Considerations ........................................18
7. Acknowledgements ...............................................19
8. Normative References ...........................................19
9. Informative References .........................................20
The Traffic Engineering Working Group has developed requirements for inter-area and inter-AS Multiprotocol Label Switching (MPLS) Traffic Engineering in [RFC4105] and [RFC4216].
トラフィックエンジニアリング作業部会は、[RFC4105]と[RFC4216]でエリア間および相互ASマルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリングの要件を開発しました。
Various proposals have subsequently been made to address some or all of these requirements through extensions to the Resource Reservation Protocol Traffic Engineering extensions (RSVP-TE) and to the Interior Gateway Protocols (IGPs) (i.e., Intermediate System to Intermediate System (IS-IS) and OSPF).
様々な提案が、その後リソース予約プロトコルトラフィックエンジニアリングの拡張（RSVP-TE）をし、内部ゲートウェイプロトコルへ（のIGP）の拡張機能によって、これらの要件の一部またはすべてに対処するために行われている（すなわち、中間システム中間システムへ（IS-IS ）とOSPF）。
This document introduces the techniques for establishing Traffic Engineered (TE) Label Switched Paths (LSPs) across multiple domains. In this context and within the remainder of this document, we consider all source-based and constraint-based routed LSPs and refer to them interchangeably as "TE LSPs" or "LSPs".
この文書は、交通エンジニアを確立するためのテクニックを紹介します（TE）ラベルは、複数のドメインにまたがってスイッチパス（LSP）。この文脈では、このドキュメントの残りの部分の中に、我々はすべてのソースをベースと制約ベースのルーティングされたLSPを考慮し、「TEのLSP」または「のLSP」と同義的にそれらを参照してください。
The functional components of these techniques are separated into the mechanisms for discovering reachability and TE information, for computing the paths of LSPs, and for signaling the LSPs. Note that the aim of this document is not to detail each of those techniques, which are covered in separate documents referenced from the sections of this document that introduce the techniques, but rather to propose a framework for inter-domain MPLS Traffic Engineering.
これらの技術の機能的な構成要素は、LSPの経路を計算するため、到達可能性及びTEの情報を発見すると、LSPをシグナリングするための機構に分離されます。このドキュメントの目的は、細部に技術を導入し、このドキュメントのセクションから参照別の文書でカバーされているこれらの技術のそれぞれにはないことに注意してくださいではなく、ドメイン間MPLSトラフィックエンジニアリングのための枠組みを提案します。
Note that in the remainder of this document, the term "MPLS Traffic Engineering" is used equally to apply to MPLS and Generalized MPLS (GMPLS) traffic. Specific issues pertaining to the use of GMPLS in inter-domain environments (for example, policy implications of the use of the Link Management Protocol [RFC4204] on inter-domain links) are covered in separate documents such as [GMPLS-AS].
この文書の残りの部分では、用語「MPLSトラフィックエンジニアリングは、」MPLSおよび一般化MPLS（GMPLS）トラフィックに適用することも同様に使用されていることに注意してください。 （例えば、ドメイン間のリンク上のリンク管理プロトコル[RFC4204]の使用の政策的含意）ドメイン間環境でのGMPLSの使用に関する具体的な問題は、このような[GMPLS-AS]など、別の文書で覆われています。
For the purposes of this document, 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. Wholly or partially overlapping domains (e.g., path computation sub-domains of areas or ASes) are not within the scope of this document.
このドキュメントの目的のために、ドメインはアドレス管理またはパス計算責任の共通の球内のネットワーク要素の任意の集合であると考えられています。そのようなドメインの例はIGP領域と自律システムを含みます。完全にまたは部分的に重複する領域（例えば、領域またはのASの経路計算サブドメイン）は、この文書の範囲外です。
Nested domains are outside the scope of this document. It may be that some domains that are nested administratively or for the purposes of address space management can be considered as adjacent domains for the purposes of this document; however, the fact that the domains are nested is then immaterial. In the context of MPLS TE, domain A is considered to be nested within domain B if domain A is wholly contained in domain B, and domain B is fully or partially aware of the TE characteristics and topology of domain A.
ネストされたドメインは、この文書の範囲外です。これは、管理上またはアドレス空間管理のためにネストされているいくつかのドメインが、この文書の目的のために、隣接するドメインとして考えることができるということであってもよく、ただし、ドメインがネストされているという事実は、重要ではありません。 MPLS TEの文脈では、ドメインAにドメインAは完全にドメインBに含まれている場合、ドメインB内にネストされると考えられ、ドメインBは、完全にまたは部分的にドメインAのTEの特性とトポロジを認識しています
Three distinct options for signaling TE LSPs across multiple domains are identified. The choice of which options to use may be influenced by the path computation technique used (see section 3), although some path computation techniques may apply to multiple signaling options. The choice may further depend on the application to which the TE LSPs are put and the nature, topology, and switching capabilities of the network.
複数のドメイン間のTE LSPをシグナリングのための3つの異なるオプションが識別されます。いくつかの経路計算技術は、複数のシグナリングオプションに適用することができるものの、オプションを使用するかの選択は、使用される経路計算技術（セクション3を参照）によって影響され得ます。選択肢はさらにTEのLSPのが置かれているために、アプリケーションや自然、トポロジ、およびネットワークのスイッチング機能に依存してもよいです。
A comparison of the usages of the different signaling options is beyond the scope of this document and should be the subject of a separate applicability statement.
異なるシグナリングオプションの使用法の比較は、このドキュメントの範囲を超えて、別の適用に関する声明の対象とすべきです。
Hierarchical LSPs form a fundamental part of MPLS [RFC3031] and are discussed in further detail in [RFC4206]. Hierarchical LSPs may optionally be advertised as TE links. Note that a hierarchical LSP that spans multiple domains cannot be advertised in this way because there is no concept of TE information that spans domains.
階層LSPは、MPLS [RFC3031]の基本的な部分を形成し、[RFC4206]にさらに詳細に記載されています。階層のLSPは、必要に応じてTEリンクとして広告することができます。ドメインにまたがるTE情報の概念がないため、複数のドメインにまたがる階層的なLSPがこのように宣伝することができないことに注意してください。
Hierarchical LSPs can be used in support of inter-domain TE LSPs. In particular, a hierarchical LSP may be used to achieve connectivity between any pair of Label Switching Routers (LSRs) within a domain. The ingress and egress of the hierarchical LSP could be the edge nodes of the domain in which case connectivity is achieved across the entire domain, or they could be any other pair of LSRs in the domain.
階層のLSPは、ドメイン間TE LSPのサポートに使用することができます。具体的には、階層的なLSPはドメイン内ラベルスイッチングルータの任意の対（LSRの）間の接続を達成するために使用されてもよいです。階層LSPの入口および出口は、その場合、接続中のドメインのエッジノードとすることができるドメイン全体を横切って達成されるか、またはそれらは、ドメイン内のLSRの他のペアであってもよいです。
The technique of carrying one TE LSP within another is termed LSP nesting. A hierarchical LSP may provide a TE LSP tunnel to transport (i.e., nest) multiple TE LSPs along a common part of their paths. Alternatively, a TE LSP may carry (i.e., nest) a single LSP in a one-to-one mapping.
別の内の一つTE LSPを搬送する技術がLSPのネストと呼ばれます。階層LSPは、その経路の共通部分に沿って搬送する（即ち、ネスト）複数のTE LSPをTE LSPトンネルを提供することができます。あるいは、TE LSPは（即ち、ネスト）1対1のマッピングにおける単一のLSPを搬送することができます。
The signaling trigger for the establishment of a hierarchical LSP may be the receipt of a signaling request for the TE LSP that it will carry, or may be a management action to "pre-engineer" a domain to be crossed by TE LSPs that would be used as hierarchical LSPs by the traffic that has to traverse the domain. Furthermore, the mapping (inheritance rules) between attributes of the nested and the hierarchical LSPs (including bandwidth) may be statically pre-configured or, for on-demand hierarchical LSPs, may be dynamic according to the properties of the nested LSPs. Even in the dynamic case, inheritance from the properties of the nested LSP(s) can be complemented by local or domain-wide policy rules.
階層LSPの確立のためのシグナリング・トリガは、それが運ぶことTE LSPのためのシグナリング要求を受信することができる、またはあろうTE用のLSPによって交差される「プレエンジニア」ドメインへの管理アクションであってもよいですドメインを通過しなければならないトラフィックによって階層のLSPとして使用します。また、ネストされたの属性と（帯域幅など）階層のLSPとの間のマッピング（継承ルール）は、静的事前構成することができる、または、オンデマンド階層のLSPのために、ネストされたLSPの特性に応じて、動的であってもよいです。でも動的場合には、ネストされたLSP（単数または複数）の特性から継承は、ローカルまたはドメイン全体のポリシールールによって補完することができます。
Note that a hierarchical LSP may be constructed to span multiple domains or parts of domains. However, such an LSP cannot be advertised as a TE link that spans domains. The end points of a hierarchical LSP are not necessarily on domain boundaries, so nesting is not limited to domain boundaries.
階層LSPが複数のドメイン又はドメインの部分に及ぶように構成されてもよいことに留意されたいです。しかしながら、そのようなLSPはドメインにまたがるTEリンクとしてアドバタイズすることができません。階層LSPの端点は、ドメインの境界上にある必要はないので、ネスティングは、ドメイン境界に限定されるものではありません。
Note also that the Interior/Exterior Gateway Protocol (IGP/EGP) routing topology is maintained unaffected by the LSP connectivity and TE links introduced by hierarchical LSPs even if they are advertised as TE links. That is, the routing protocols do not exchange messages over the hierarchical LSPs, and LSPs are not used to create routing adjacencies between routers.
注また、外部/内部ゲートウェイプロトコル（IGP / EGP）ルーティングトポロジは、それらは、TEリンクとして宣伝されている場合でも、階層のLSPによって導入されたLSPの接続性とTEリンクによって影響を受けずに維持されます。つまり、ルーティングプロトコルは、階層のLSPを介してメッセージを交換しませんし、LSPはルータ間のルーティング隣接関係を作成するために使用されていません。
During the operation of establishing a nested LSP that uses a hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain unchanged along the entire length of the nested LSP, as do all other objects that have end-to-end significance.
エンド・ツー・エンドの重要性を持っている他のすべてのオブジェクトがそうであるように階層的なLSPを使用して、ネストされたLSPを確立する動作中、SENDER_TEMPLATEとSESSIONオブジェクトは、ネストされたLSPの全長に沿って変更されません。
A single contiguous LSP is established from ingress to egress in a single signaling exchange. No further LSPs are required to be established to support this LSP so that hierarchical or stitched LSPs are not needed.
単一の連続したLSPは、単一のシグナリング交換に出口に入口から確立されます。これ以上のLSPは、階層やステッチのLSPが必要とされないように、このLSPをサポートするために確立する必要はありません。
A contiguous LSP uses the same Session/LSP ID along the whole of its path (that is, at each LSR). The notions of "splicing" together different LSPs or of "shuffling" Session or LSP identifiers are not considered.
連続したLSPは、その経路の全体に沿って同じセッション/ LSP IDを（つまり、各LSRである）を使用します。一緒に別のLSPを「スプライシング」のか、「シャッフル」のセッションやLSP識別子の概念は考慮されません。
LSP Stitching is described in [STITCH]. In the LSP stitching model, separate LSPs (referred to as a TE LSP segments) are established and are "stitched" together in the data plane so that a single end-to-end Label Switched Path is achieved. The distinction is that the component LSP segments are signaled as distinct TE LSPs in the control plane. Each signaled TE LSP segment has a different source and destination.
LSPステッチは、[ステッチ]に記載されています。 LSPステッチモデルでは、（TE LSPセグメントとも呼ばれる）別のLSPが確立されており、シングルエンド・ツー・エンドのラベルスイッチパスが達成されるように、データプレーン内で一緒に「縫合」されています。区別コンポーネントのLSPセグメントが制御プレーンにおいて異なるTEのLSPとしてシグナリングされることです。各シグナリングTE LSPセグメントは、異なる送信元と宛先を有しています。
LSP stitching can be used in support of inter-domain TE LSPs. In particular, an LSP segment may be used to achieve connectivity between any pair of LSRs within a domain. The ingress and egress of the LSP segment could be the edge nodes of the domain in which case connectivity is achieved across the entire domain, or they could be any other pair of LSRs in the domain.
LSPステッチは、ドメイン間TE LSPのサポートに使用することができます。具体的には、LSPセグメントは、ドメイン内のLSRの任意のペア間の接続を達成するために使用されてもよいです。 LSPセグメントの入口および出口は、ケース接続がドメイン全体を横切って達成されたドメインのエッジノードとすることができる、またはそれらは、ドメイン内のLSRの他のペアであってもよいです。
The signaling trigger for the establishment of a TE LSP segment may be the establishment of the previous TE LSP segment, the receipt of a setup request for TE LSP that it plans to stitch to a local TE LSP segment, or a management action.
TE LSPセグメントの確立のためのシグナリングをトリガ前TE LSPセグメントを確立することができ、それはローカルTE LSPセグメント、または管理アクションにステッチする予定TE LSPの設定要求を受信。
LSP segments may be managed and advertised as TE links.
LSPセグメントは、管理対象とTEリンクとして広告することができます。
There is nothing to prevent the mixture of signaling methods described above when establishing a single, end-to-end, inter-domain TE LSP. It may be desirable in this case for the choice of the various methods to be reported along the path, perhaps through the Record Route Object (RRO).
単一のエンドツーエンドのドメイン間のTE LSPを確立する際に上述の方法のシグナリングの混合を防止するためには何もありません。様々な方法の選択は、おそらくレコードルートオブジェクト（RRO）を介して、経路に沿って報告されることは、この場合に望ましいかもしれません。
If there is a desire to restrict which methods are used, this must be signaled as described in the next section.
使用される方法を制限したいという要望がある場合は、次のセクションで説明したように、これはシグナリングされなければなりません。
Notwithstanding the previous section, an ingress LSR may wish to restrict the signaling methods applied to a particular LSP at domain boundaries across the network. Such control, where it is required, may be achieved by the definition of appropriate new flags in the SESSION-ATTRIBUTE object or the Attributes Flags TLV of the LSP_ATTRIBUTES object [RFC4420]. Before defining a mechanism to provide this level of control, the functional requirement to control the way in which the network delivers a service must be established. Also, due consideration must be given to the impact on interoperability since new mechanisms must be backwards compatible, and care must be taken to avoid allowing standards-conformant implementations that each supports a different functional subset in such a way that they are not capable of establishing LSPs.
前節にもかかわらず、入口LSRは、ネットワークを介してドメイン境界において特定のLSPに適用されるシグナリング方法を制限することを望むかもしれません。それが必要とされるような制御は、適切な新しいセッション属性オブジェクト内のフラグまたは属性フラグLSP_ATTRIBUTESオブジェクトのTLV [RFC4420]の定義によって達成することができます。このレベルの制御を提供するためのメカニズムを定義する前に、ネットワークサービスを配信する方法を制御する機能要件が確立されなければなりません。また、新たなメカニズムは下位互換性がなければならないので、考慮は、相互運用性に影響を与えなければならない、およびケアは、それぞれ、それらが確立することができないような方法で異なる機能のサブセットをサポートする標準準拠の実装を可能にすることを避けるために注意しなければなりませんLSP。
The discussion of path computation techniques within this document is limited significantly to the determination of where computation may take place and what components of the full path may be determined.
このドキュメント内の経路計算技術の議論は、計算が行われてもよいし、完全なパスのどの成分が決定されることができるところの決意に大きく制限されます。
The techniques used are closely tied to the signaling methodologies described in the previous section in that certain computation techniques may require the use of particular signaling approaches and vice versa.
使用される技術は、密接に特定のシグナリング・アプローチとその逆の使用を必要とするかもしれない特定の演算手法に前のセクションで説明したシグナリング方法論に縛られます。
Any discussion of the appropriateness of a particular path computation technique in any given circumstance is beyond the scope of this document and should be described in a separate applicability statement.
任意の所与の状況で特定の経路計算手法の妥当性のいずれかの説明は、この文書の範囲外であり、別の適用書に記載されるべきです。
Path computation algorithms are firmly out of the scope of this document.
経路計算アルゴリズムはしっかりとこの文書の範囲外です。
Path computation may be performed by offline tools or by a network planner. The resultant path may be supplied to the ingress LSR as part of the TE LSP or service request, and encoded by the ingress LSR as an Explicit Route Object (ERO) on the Path message that is sent out.
経路計算は、オフラインツールによって、またはネットワーク計画担当者によって行われてもよいです。得られたパスは、TE LSPの一部またはサービス要求として入口LSRに供給され、送出されたPathメッセージに明示的ルート・オブジェクト（ERO）として入口LSRによってコードされてもよいです。
There is no reason why the path provided by the operator should not span multiple domains if the relevant information is available to the planner or the offline tool. The definition of what information is needed to perform this operation and how that information is gathered, is outside the scope of this document.
関連情報は、プランナーまたはオフラインツールに利用可能である場合にオペレータが提供するパスが複数のドメインにまたがるない理由はありません。この操作方法と、その情報が収集されたを実行するために必要なものの情報の定義は、この文書の範囲外です。
The head-end, or ingress, LSR may assume responsibility for path computation when the operator supplies part or none of the explicit path. The operator must, in any case, supply at least the destination address (egress) of the LSP.
ヘッドエンド、または入力オペレータが一部または明示的な経路のいずれを供給する場合、LSRは、経路計算の責任をとることができます。 LSPのオペレータなければならず、いずれの場合において、供給少なくとも宛先アドレス（出力）。
If the ingress has sufficient visibility of the topology and TE information for all of the domains across which it will route the LSP to its destination, then it may compute and provide the entire path. The quality of this path (that is, its optimality as discussed in section 3.5) can be better if the ingress has full visibility into all relevant domains rather than just sufficient visibility to provide some path to the destination.
入口は、その目的地までの経路LSPれる横切るドメインのすべてのトポロジとTE情報の十分な視認性を有している場合、それは全体の経路を計算し、提供することができます。入力は、関連するすべてのドメインではなく、先にいくつかの経路を提供するだけの十分な視認性に完全な可視性を持っている場合、このパスの品質が（セクション3.5で説明したようにそれは、その最適である）より良好であることができます。
Extreme caution must be exercised in consideration of the distribution of the requisite TE information. See section 4.
細心の注意が必要なTE情報の分布を考慮して行使されなければなりません。セクション4を参照してください。
It may be that the ingress does not have full visibility of the topology of all domains, but does have information about the connectedness of the domains and the TE resource availability across the domains. In this case, the ingress is not able to provide a fully specified strict explicit path from ingress to egress. However, for example, the ingress might supply an explicit path that comprises:
それは侵入がすべてのドメインのトポロジーの完全な可視性を持っていませんが、ドメインのつながりやドメイン間のTEリソースの可用性に関する情報を持っていないことかもしれません。この場合、入口は、入口から出口まで完全に指定された厳密な明示的なパスを提供することができません。しかし、例えば、入口は、前記明示的なパスを供給することがあります。
- explicit hops from ingress to the local domain boundary - loose hops representing the domain entry points across the network - a loose hop identifying the egress.
- ローカル・ドメインの境界に進入からの明示的なホップ - 出口を識別ルーズホップ - ネットワーク全体のドメインエントリポイントを表すルーズホップ。
Alternatively, the explicit path might be expressed as:
代替的に、明示的なパスは次のように表現されるかもしれません。
- explicit hops from ingress to the local domain boundary - strict hops giving abstract nodes representing each domain in turn - a loose hop identifying the egress.
- ローカル・ドメインの境界に進入からの明示的なホップ - 出口を識別ルーズホップ - 順番に各ドメインを表す抽象ノードを与える厳密ホップ。
These two explicit path formats could be mixed according to the information available resulting in different combinations of loose hops and abstract nodes.
これら二つの明示的なパスフォーマットはルーズホップと抽象ノードの異なる組み合わせで得られた利用可能な情報に基づいて混合することができます。
This form of explicit path relies on some further computation technique being applied at the domain boundaries. See section 3.3.
明示的なパスのこの形式は、ドメイン境界で適用されているいくつかの更なる計算手法に依存しています。セクション3.3を参照してください。
As with the multi-domain visibility option, extreme caution must be exercised in consideration of the distribution of the requisite TE information. See section 4.
マルチドメイン可視オプションと同様に、細心の注意が必要なTE情報の分布を考慮して行使されなければなりません。セクション4を参照してください。
A final possibility for ingress-based computation is that the ingress LSR has visibility only within its own domain, and connectivity information only as far as determining one or more domain exit points that may be suitable for carrying the LSP to its egress.
入口ベースの計算のための最終的な可能性は、入口LSRのみ限り、その出口にLSPを搬送するために適切であり得る1つ以上のドメインの出口点を決定するようのみ、自身のドメイン内の可視性、および接続情報を有することです。
In this case, the ingress builds an explicit path that comprises just:
この場合、侵入はちょうど含み、明示的なパスを構築します。
- explicit hops from ingress to the local domain boundary - a loose hop identifying the egress.
- ローカル・ドメインの境界に進入からの明示的なホップ - 出口を識別ルーズホップ。
If the partial explicit path methods described in sections 3.2.2 or 3.2.3 are applied, then the LSR at each domain boundary is responsible for ensuring that there is sufficient path information added to the Path message to carry it at least to the next domain boundary (that is, out of the new domain).
セクション3.2.2または3.2.3で説明した部分明示的なパス方法が適用される場合、各ドメインの境界におけるLSRは、少なくとも次のドメインにそれを運ぶためにPathメッセージに追加し、十分なパス情報があることを保証する責任を負います境界（つまり、新しいドメインの外に、です）。
If the LSR at the domain boundary has full visibility to the egress then it can supply the entire explicit path. Note, however, that the ERO processing rules of [RFC3209] state that it should only update the ERO as far as the next specified hop (that is, the next domain boundary if one was supplied in the original ERO) and, of course, must not insert ERO subobjects immediately before a strict hop.
ドメインの境界にあるLSRが出口への完全な可視性を持っている場合、それは全体の明示的なパスを供給することができます。ただし、のERO処理規則[RFC3209]状態それだけ限り、次の指定されたホップとしてEROを更新する必要があること（つまり、一方が元のEROで供給された場合、次ドメイン境界）もちろん、そして、厳格なホップの直前にEROサブオブジェクトを挿入してはいけません。
If the LSR at the domain boundary has only partial visibility (using the definitions of section 3.2.2), it will fill in the path as far as the next domain boundary, and will supply further domain/domain boundary information if not already present in the ERO.
ドメイン境界でのLSRが（セクション3.2.2の定義を用いて）部分的にしか視認性を有する場合、それは限り次ドメイン境界としてパスを記入し、中に既に存在しない場合は、さらにドメイン/ドメイン境界情報を供給するERO。
If the LSR at the domain boundary has only local visibility into the immediate domain, it will simply add information to the ERO to carry the Path message as far as the next domain boundary.
ドメインの境界にあるLSRが即時ドメインにのみ局所的な可視性を持っている場合、それは単に限り、次のドメイン境界として、Pathメッセージを運ぶためにEROに情報を追加します。
Domain boundary path computations are performed independently from each other. Domain boundary LSRs may have different computation capabilities, run different path computation algorithms, apply different sets of constraints and optimization criteria, and so forth, which might result in path segment quality that is unpredictable to and out of the control of the ingress LSR. A solution to this issue lies in enhancing the information signaled during LSP setup to include a larger set of constraints and to include the paths of related LSPs (such as diverse protected LSPs) as described in [GMPLS-E2E].
ドメイン境界経路の計算は、互いに独立して行われます。ドメイン境界のLSRは、異なる計算能力を持っている別の経路計算アルゴリズムを実行し、へと進入LSRの制御のうち、予測不可能であるパスセグメントの品質につながる可能性があるなどの制約および最適化基準、およびの異なるセットを、適用される場合があります。この問題に対する解決策は、制約の大きいセットを含むようにして[GMPLS-E2E]に記載されているように（このような多様な保護のLSPなど）に関連するLSPの経路を含むようにLSPセットアップ中にシグナリング情報を向上させることにあります。
It is also the case that paths generated on domain boundaries may produce loops. Specifically, the paths computed may loop back into a domain that has already been crossed by the LSP. This may or may not be a problem, and might even be desirable, but could also give rise to real loops. This can be avoided by using the recorded route (RRO) to provide exclusions within the path computation algorithm, but in the case of lack of trust between domains it may be necessary for the RRO to indicate the previously visited domains. Even this solution is not available where the RRO is not available on a Path message. Note that when an RRO is used to provide exclusions, and a loop-free path is found to be not available by the computation at a downstream border node, crankback [CRANKBACK] may enable an upstream border node to select an alternate path.
また、ドメインの境界に発生する経路がループを生成することができる場合です。具体的には、パスはバック既にLSPが交差されたドメインへ月ループを計算しました。これは、または問題であってもなくてもよい、とさえ望ましいかもしれないが、また、実際のループを生じさせることができました。これは、経路計算アルゴリズム内の除外を提供する記録経路（RRO）を使用することによって回避することができるが、RROが以前に訪問したドメインを指示するためのドメイン間の信頼性の欠如の場合にそれが必要であってもよいです。 RROをPathメッセージには利用できない場合でも、この解決策は使用できません。 RROは除外を提供するために使用され、ループのないパスを下流境界ノードで計算することにより利用できないことが判明した場合、クランクバック【クランクバック]代替パスを選択するために、上流の境界ノードを可能にすることができることに留意されたいです。
The computation techniques in sections 3.2 and 3.3 rely on topology and TE information being distributed to the ingress LSR and those LSRs at domain boundaries. These LSRs are responsible for computing paths. Note that there may be scaling concerns with distributing the required information; see section 4.
セクション3.2および3.3での計算手法は、トポロジと入口LSRとドメイン境界におけるそれらのLSRに配布されるTE情報に依存しています。これらのLSRは、パスを計算するための責任があります。必要な情報を配布するとの懸念をスケーリングがあるかもしれないことに注意してください。セクション4を参照してください。
An alternative technique places the responsibility for path computation with a Path Computation Element (PCE) [RFC4655]. There may be either a centralized PCE, or multiple PCEs (each having local visibility and collaborating in a distributed fashion to compute an end-to-end path) across the entire network and even within any one domain. The PCE may collect topology and TE information from the same sources as would be used by LSRs in the previous paragraph, or though other means.
別の技術は、経路計算エレメント（PCE）[RFC4655]を用いて経路計算の責任を置きます。ネットワーク全体ともいずれかのドメイン内（各ローカル可視性を有するエンドツーエンドパスを計算するために、分散方式で協力）集中PCE、または複数のPCEのいずれかが存在してもよいです。 PCEは、前の段落で、又は他の手段ものLSRによって使用されるのと同じソースからのトポロジとTEの情報を収集することができます。
Each LSR called upon to perform path computation (and even the offline management tools described in section 3.1) may abdicate the task to a PCE of its choice. The selection of PCE(s) may be driven by static configuration or the dynamic discovery.
各LSRは、その選択肢のPCEにタスクを放棄する経路計算（および3.1節で説明しても、オフライン管理ツール）を実行するように呼びかけ。 PCE（単数または複数）の選択は、静的構成または動的検出によって駆動されてもよいです。
A PCE may have full visibility, perhaps through connectivity to multiple domains. In this case, it is able to supply a full explicit path as in section 3.2.1.
PCEは、おそらく複数のドメインへの接続を介して、完全な可視性を有することができます。この場合には、セクション3.2.1のように完全な明示的なパスを供給することができます。
Note that although a centralized PCE or multiple collaborative PCEs may have full visibility into one or more domains, it may be desirable (e.g., to preserve topology confidentiality) that the full path not be provided to the ingress LSR. Instead, a partial path is supplied (as in section 3.2.2 or 3.2.3), and the LSRs at each domain boundary are required to make further requests for each successive segment of the path.
集中PCE又は複数の共同のPCEが1つまたは複数のドメインに完全な可視性を有することができるが、それは完全なパスは、入口LSRに提供されないこと（例えば、トポロジーの機密性を維持するために）ことが望ましい場合があることに留意されたいです。代わりに、部分的なパスは（セクション3.2.2または3.2.3のように）供給され、各ドメイン境界でのLSRは、パスの各連続セグメントのためのさらなる要求を行うために必要とされます。
In this way, an end-to-end path may be computed using the full network capabilities, but confidentiality between domains may be preserved. Optionally, the PCE(s) may compute the entire path at the first request and hold it in storage for subsequent requests, or it may recompute each leg of the path on each request or at regular intervals until requested by the LSRs establishing the LSP.
このように、エンド・ツー・エンドのパスは、完全なネットワーク機能を使用して計算することができるが、ドメイン間の機密性を維持することができます。必要に応じて、PCE（単数または複数）は、最初の要求で全体の経路を計算し、後続の要求のためにストレージに保持、またはLSPを確立するのLSRによって要求されるまでは、各リクエストに応じて、または定期的な間隔で経路の各脚を再計算してもよいです。
It may be the case that the centralized PCE or the collaboration between PCEs may define a trust relationship greater than that normally operational between domains.
それは、集中PCEまたはのPCE間のコラボレーションがドメイン間の通常動作よりも大きな信頼関係を定義することができる場合であってもよいです。
A third way that PCEs may be used is simply to have one (or more) per domain. Each LSR within a domain that wishes to derive a path across the domain may consult its local PCE.
PCEを使用することができる第三の方法は、ドメインごとに1つ（またはそれ以上）を有することが単にあります。そのローカルPCEに相談して、ドメイン間でパスを導出することを希望するドメイン内の各LSR。
This mechanism could be used for all path computations within the domain, or specifically limited to computations for LSPs that will leave the domain where external connectivity information can then be restricted to just the PCE.
このメカニズムは、ドメイン内のすべてのパスの計算に使用、または特に外部接続情報は、その後、ちょうどPCEに制限することができるドメインを残すのLSPのための計算に限定することができます。
There are many definitions of an optimal path depending on the constraints applied to the path computation. In a multi-domain environment, the definitions are multiplied so that an optimal route might be defined as the route that would be computed in the absence of domain boundaries. Alternatively, another constraint might be applied to the path computation to reduce or limit the number of domains crossed by the LSP.
経路計算に適用される制約に応じて最適な経路の多くの定義があります。最適なルートは、ドメイン境界の不在下で計算される経路として定義されるかもしれないようにマルチドメイン環境では、定義が乗算されます。あるいは、別の制約は、LSPが横断ドメインの数を減らすか、または制限するために、経路計算に適用されるかもしれません。
It is easy to construct examples that show that partitioning a network into domains, and the resulting loss or aggregation of routing information may lead to the computation of routes that are other than optimal. It is impossible to guarantee optimal routing in the presence of aggregation / abstraction / summarization of routing information.
ドメインにネットワークを分割することを示す例を構築することが容易であり、ルーティング情報の結果として生じる損失や凝集が最適以外のルートの計算につながる可能性があります。ルーティング情報の集約/抽象化/要約の存在下での最適なルーティングを保証することは不可能です。
It is beyond the scope of this document to define what is an optimum path for an inter-domain TE LSP. This debate is abdicated in favor of requirements documents and applicability statements for specific deployment scenarios. Note, however, that the meaning of certain computation metrics may differ between domains (see section 5.6).
これは、ドメイン間TE LSPのための最適な経路が何であるかを定義するには、この文書の範囲外です。この議論は、要件文書と特定の展開シナリオに適用可能文の賛成で退位されます。特定の計算指標の意味はドメイン（セクション5.6を参照）との間で異なる可能性があること、しかし、注意してください。
Traffic Engineering information is collected into a TE Database (TED) on which path computation algorithms operate either directly or by first constructing a network graph.
トラフィックエンジニアリング情報は、経路計算アルゴリズムは、直接、または第一のネットワーク・グラフを構築することによって動作する上TEデータベース（TED）に回収されます。
The path computation techniques described in the previous section make certain demands upon the distribution of reachability information and the TE capabilities of nodes and links within domains as well as the TE connectivity across domains.
前のセクションで説明した経路計算技術は、到達可能性情報及びドメイン内のノードとリンクのTE能力ならびにドメイン間のTE接続の分布に特定の要求を行います。
Currently, TE information is distributed within domains by additions to IGPs [RFC3630], [RFC3784].
現在、TE情報のIGP [RFC3630]、[RFC3784]に追加することによって、ドメイン内に分布されています。
In cases where two domains are interconnected by one or more links (that is, the domain boundary falls on a link rather than on a node), there should be a mechanism to distribute the TE information associated with the inter-domain links to the corresponding domains. This would facilitate better path computation and reduce TE-related crankbacks on these links.
2つのドメインが1つまたは複数のリンク（すなわち、ドメイン境界は、リンク上ではなくノード上に落下する）によって相互接続されている場合には、対応するドメイン間リンクに関連TE情報を配布するためのメカニズムが存在すべきですドメイン。これは、より良い経路計算を容易にし、これらのリンクをTE関連のクランクバックを低減するであろう。
Where a domain is a subset of an IGP area, filtering of TE information may be applied at the domain boundary. This filtering may be one way or two way.
ドメインは、IGP領域のサブセットである場合、TE情報のフィルタリングは、ドメイン境界に適用することができます。このフィルタリングは、一方向または双方向かもしれません。
Where information needs to reach a PCE that spans multiple domains, the PCE may snoop on the IGP traffic in each domain, or play an active part as an IGP-capable node in each domain. The PCE might also receive TED updates from a proxy within the domain.
情報が複数のドメインにまたがるPCEに到達する必要がある場合、PCEは、各ドメイン内のIGPトラフィックをスヌープ、又は各ドメインにおけるIGP対応ノードとして活躍することができます。 PCEは、ドメイン内のプロキシからTEDの更新を受け取ることがあります。
It is possible that an LSR that performs path computation (for example, an ingress LSR) obtains the topology and TE information of not just its own domain, but other domains as well. This information may be subject to filtering applied by the advertising domain (for example, the information may be limited to Forwarding Adjacencies (FAs) across other domains, or the information may be aggregated or abstracted).
（例えば、入口LSR）経路計算を実行するLSRは、同様のトポロジだけでなく、独自のドメインのTE情報と、他のドメインを取得することが可能です。この情報は、（例えば、情報が他のドメイン間転送隣接関係（FAS）に限定してもよいし、又は情報が集約又は抽象化されてもよい）広告ドメインによって適用されるフィルタリングの対象とすることができます。
Before starting work on any protocols or protocol extensions to enable cross-domain reachability and TE advertisement in support of inter-domain TE, the requirements and benefits must be clearly established. This has not been done to date. Where any cross-domain reachability and TE information needs to be advertised, consideration must be given to TE extensions to existing protocols such as BGP, and how the information advertised may be fed to the IGPs. It must be noted that any extensions that cause a significant increase in the amount of processing (such as aggregation computation) at domain boundaries, or a significant increase in the amount of information flooded (such as detailed TE information) need to be treated with extreme caution and compared carefully with the scaling requirements expressed in [RFC4105] and [RFC4216].
ドメイン間TEのサポートで、クロスドメインの到達可能性とTE広告を有効にするには、任意のプロトコルまたはプロトコル拡張に関する作業を開始する前に、要件と利点が明確に確立されなければなりません。これは、現在までに行われていません。任意のクロスドメインの到達可能性及びTE情報をアドバタイズする必要がある場合、考慮事項は、BGPなどの既存のプロトコルにTE拡張に与えられなければならない、そしてどのようにアドバタイズ情報は、のIGPに供給することができます。ドメイン境界で（例えば、集計計算など）の処理量が大幅に増加、または（例えば、詳細なTE情報など）浸水情報の量が大幅に増加を引き起こす任意の拡張子が極端で処理する必要があることに留意しなければなりません[RFC4105]及び[RFC4216]で表さスケーリング要件を慎重に注意して比較。
This section provides some non-definitive comments on the constraints placed on advanced MPLS TE functions by inter-domain MPLS. It does not attempt to state the implications of using one inter-domain technique or another. Such material is deferred to appropriate applicability statements where statements about the capabilities of existing or future signaling, routing, and computation techniques to deliver the functions listed should be made.
このセクションでは、ドメイン間のMPLSにより、高度なMPLS TE機能の上に置かれた制約のいくつかの非決定的なコメントを提供します。これは、1つのドメイン間の技術や他を使用する意味を述べるしようとしません。そのような材料は、既存のまたは将来のシグナリング、ルーティング、および計算技術の能力に関する記述がなされるべきで列挙された機能を提供する適切な適用文に延期されます。
Re-optimization is the process of moving a TE LSP from one path to another, more preferable path (where no attempt is made in this document to define "preferable" as no attempt was made to define "optimal"). Make-before-break techniques are usually applied to ensure that traffic is disrupted as little as possible. The Shared
再最適化、より好ましい経路（試みが「最適」を定義するためになされなかったとして試みは本書では行われない「好ましい」を定義するために）別の経路からTE LSPを移動させる処理です。メイク・ビフォア・ブレイク技法は、通常のトラフィックができるだけ破壊されることを保証するために適用されます。共有
Explicit style is usually used to avoid double booking of network resources.
明示的なスタイルは、通常、ネットワークリソースのダブルブッキングを避けるために使用されます。
Re-optimization may be available within a single domain. Alternatively, re-optimization may involve a change in route across several domains or might involve a choice of different transit domains.
再最適化は、単一のドメイン内で利用できます。また、再最適化には、いくつかのドメイン間でルートの変更を伴うことが、異なるトランジットドメインの選択を必要とするかもしれません。
Re-optimization requires that all or part of the path of the LSP be re-computed. The techniques used may be selected as described in section 3, and this will influence whether the whole or part of the path is re-optimized.
再最適化LSPの経路の全部又は一部が再計算されることを必要とします。セクション3に記載されているように使用される技術を選択することができ、これはパスの全部または一部を再最適化されているかどうかに影響します。
The trigger for path computation and re-optimization may be an operator request, a timer, information about a change in availability of network resources, or a change in operational parameters (for example, bandwidth) of an LSP. This trigger must be applied to the point in the network that requests re-computation and controls re-optimization and may require additional signaling.
経路計算及び再最適化のためのトリガは、オペレータ要求、タイマー、ネットワーク資源の利用可能性の変化、またはLSPの動作パラメータの変化（例えば、帯域幅）に関する情報であってもよいです。このトリガは再計算と制御の再最適化を要求し、追加のシグナリングを必要とするかもしれないネットワーク内のポイントに適用されなければなりません。
Note also that where multiple mutually-diverse paths are applied end-to-end (i.e., not simply within protection domains; see section 5.5) the point of calculation for re-optimization (whether it is PCE, ingress, or domain entry point) needs to know all such paths before attempting re-optimization of any one path. Mutual diversity here means that a set of computed paths has no commonality. Such diversity might be link, node, Shared Risk Link Group (SRLG), or even domain disjointedness according to circumstances and the service being delivered.
注また、複数の相互に多様な経路が適用されていることをエンド・ツー・エンド（すなわち、単なる保護ドメイン内で、セクション5.5を参照）を再最適化の計算の点（それはPCE、入口、またはドメインエントリポイントであるかどうか）いずれかのパスの再最適化を試みる前に、すべてのそのようなパスを知る必要があります。相互の多様性は、ここで計算されたパスのセットが何の共通性を持っていないことを意味します。このような多様性は、状況や配信されるサービスに応じてリンク、ノード、共有リスクリンクグループ（SRLG）、あるいはドメインdisjointednessかもしれません。
It may be the case that re-optimization is best achieved by recomputing the paths of multiple LSPs at once. Indeed, this can be shown to be most efficient when the paths of all LSPs are known, not simply those LSPs that originate at a particular ingress. While this problem is inherited from single domain re-optimization and is out of scope within this document, it should be noted that the problem grows in complexity when LSPs wholly within one domain affect the re-optimization path calculations performed in another domain.
これは、再最適化が最良一度に複数のLSPの経路を再計算することによって達成される場合であってもよいです。実際、これはすべてのLSPの経路が既知である場合、特定の入力に属していない、単にそれらのLSP、最も効率的であることを示すことができます。この問題は、単一のドメインの再最適化から継承され、この文書内の対象範囲外ですが、完全に一つのドメイン内のLSPが別のドメインで実行再最適化パスの計算に影響を与えたときに、問題が複雑に成長することに留意すべきです。
When an inter-domain LSP setup fails in some domain other than the first, various options are available for reporting and retrying the LSP.
ドメイン間LSPのセットアップが最初以外のいくつかのドメインに失敗した場合、さまざまなオプションがLSPを報告し、再試行のために用意されています。
In the first instance, a retry may be attempted within the domain that contains the failure. That retry may be attempted by nodes wholly within the domain, or the failure may be referred back to the LSR at the domain boundary.
最初のインスタンスでは、再試行が失敗したことを含むドメイン内で試行されてもよいです。その再試行が完全ドメイン内のノードによって試みてもよいし、故障がドメイン境界に戻っLSRと呼ぶことができます。
If the failure cannot be bypassed within the domain where the failure occurred (perhaps there is no suitable alternate route, perhaps rerouting is not allowed by domain policy, or perhaps the Path message specifically bans such action), the error must be reported back to the previous or head-end domain.
障害が、障害が発生したドメイン内にバイパスすることができない場合、エラーがに戻って報告しなければならない（おそらく、いかなる適切な代替経路が存在しない、おそらくドメインポリシーによって許可されていない再ルーティング、または多分Pathメッセージは、具体的には、そのようなアクションを禁止）以前またはヘッドエンドドメイン。
Subsequent repair attempts may be made by domains further upstream, but will only be properly effective if sufficient information about the failure and other failed repair attempts is also passed back upstream [CRANKBACK]. Note that there is a tension between this requirement and that of topology confidentiality although crankback aggregation may be applicable at domain boundaries.
その後の修復の試みはさらに上流ドメインによって製造することができるが、障害及び他の障害が発生した修復の試行に関する十分な情報も上流[クランクバック】戻された場合にのみ正常に有効であろう。この要件とクランクバック凝集がドメイン境界でも適用できるが、そのトポロジーの機密性との間に緊張があることに注意してください。
Further attempts to signal the failed LSP may apply the information about the failures as constraints to path computation, or may signal them as specific path exclusions [EXCLUDE].
さらなる試みは失敗したLSPは、経路計算に制約として失敗についての情報を適用することができる信号に、または特定のパスの除外[EXCLUDE]としてそれらをシグナリングすることができます。
When requested by signaling, the failure may also be systematically reported to the head-end LSR.
シグナリングによって要求されたとき、故障も系統的ヘッドエンドLSRに通知することができます。
An LSP that fails after it has been established may be repaired dynamically by re-routing. The behavior in this case is either like that for re-optimization, or for handling setup failures (see previous two sections). Fast Reroute may also be used (see below).
それが確立された後に障害が発生したLSPを再ルーティングによって動的に修復することができます。この場合、動作は、（前の二つのセクションを参照してください）そのような再最適化のために、またはセットアップの失敗を処理するためのいずれかです。高速リルートは、（下記参照）を使用することができます。
MPLS Traffic Engineering Fast Reroute ([RFC4090]) defines local protection schemes intended to provide fast recovery (in 10s of msecs) of fast-reroutable packet-based TE LSPs upon link/SRLG/Node failure. A backup TE LSP is configured and signaled at each hop, and activated upon detecting or being informed of a network element failure. The node immediately upstream of the failure (called the PLR, or Point of Local Repair) reroutes the set of protected TE LSPs onto the appropriate backup tunnel(s) and around the failed resource.
MPLSトラフィックエンジニアリング高速リルート（[RFC4090]）は、リンク/ SRLG /ノードの障害時に高速reroutableパケットベースのTE LSPの（ミリ秒の10秒で）高速リカバリを提供することを目的と地元の保護スキームを定義します。バックアップTE LSPが設定され、各ホップでシグナリング、および検出またはネットワーク要素の障害を通知されると活性化されます。 （PLR、またはローカル修復のポイントと呼ばれる）故障の直ぐ上流のノードは、適切なバックアップトンネル（S）に失敗したリソースの周り保護のTE LSPのセットを再ルーティング。
In the context of inter-domain TE, there are several different failure scenarios that must be analyzed. Provision of suitable solutions may be further complicated by the fact that [RFC4090] specifies two distinct modes of operation referred to as the "one to one mode" and the "facility back-up mode".
ドメイン間TEとの関連では、分析されなければならないいくつかの異なる障害シナリオがあります。適切なソリューションの提供は、さらに[RFC4090]は「一から一モード」と「施設バックアップモード」と呼ばれる操作2つの異なるモードを指定しているという事実によって複雑にされてもよいです。
The failure scenarios specific to inter-domain TE are as follows:
次のようにドメイン間TEに固有の障害シナリオは以下のとおりです。
- Failure of a domain edge node that is present in both domains. There are two sub-cases:
- 両方のドメインに存在するドメインのエッジノードの障害。二つのサブケースがあります。
- The Point of Local Repair (PLR) and the Merge Point (MP) are in the same domain.
- ローカル修理（PLR）と合流点（MP）のポイントは、同じドメイン内にあります。
- The PLR and the MP are in different domains.
- PLR及びMPは異なるドメインにあります。
- Failure of a domain edge node that is only present in one of the domains.
- ドメインの一方にのみ存在するドメインのエッジノードの障害。
- Failure of an inter-domain link.
- ドメイン間リンクの失敗。
Although it may be possible to apply the same techniques for Fast Reroute (FRR) to the different methods of signaling inter-domain LSPs described in section 2, the results of protection may be different when it is the boundary nodes that need to be protected, and when they are the ingress and egress of a hierarchical LSP or stitched LSP segment. In particular, the choice of PLR and MP may be different, and the length of the protection path may be greater. These uses of FRR techniques should be explained further in applicability statements or, in the case of a change in base behavior, in implementation guidelines specific to the signaling techniques.
セクション2で説明したドメイン間LSPをシグナリングする異なる方法に高速リルート（FRR）のために同じ手法を適用することが可能かもしれないが、それが保護する必要が境界ノードである場合、保護の結果は、異なっていてもよいですそれらが階層LSPまたはステッチLSPセグメントの入口および出口である場合。特に、PLRとMPの選択は異なっていてもよく、保護パスの長さが大きくてもよいです。 FRR技術のこれらの使用は、シグナリング技術に固有の実装ガイドラインでは、ベース動作の変更の場合には、適用文でさらに説明又はされるべきです。
Note that after local repair has been performed, it may be desirable to re-optimize the LSP (see section 5.1). If the point of re-optimization (for example, the ingress LSR) lies in a different domain to the failure, it may rely on the delivery of a PathErr or Notify message to inform it of the local repair event.
ローカル修復が行われた後、それは再最適化LSP（セクション5.1を参照）することが望ましい場合があることに留意されたいです。再最適化（例えば、イングレスLSR）のポイントは失敗とは異なるドメインにある場合、それはのPathErrの配信に依存しているか、ローカルの修理イベントのことを通知するメッセージを通知することができます。
It is important to note that Fast Reroute techniques are only applicable to packet switching networks because other network technologies cannot apply label stacking within the same switching type. Segment protection [GMPLS-SEG] provides a suitable alternative that is applicable to packet and non-packet networks.
他のネットワーク技術は、同じスイッチングタイプ内スタッキングラベルを適用できないため、高速リルート技術は、パケット交換ネットワークにのみ適用可能であることに注意することが重要です。セグメント保護[GMPLS-SEG]はパケット及び非パケットネットワークに適用可能である適切な代替物を提供します。
Diverse paths may be required in support of load sharing and/or protection. Such diverse paths may be required to be node diverse, link diverse, fully path diverse (that is, link and node diverse), or SRLG diverse.
多様なパスは、負荷分散および/または保護のサポートに必要な場合があります。そのような多様な経路がノード多様であることが必要となる場合があり、多様な、十分に多様な経路（すなわち、リンク及びノードの多様な）、またはSRLG多様をリンクします。
Diverse path computation is a classic problem familiar to all graph theory majors. The problem is compounded when there are areas of "private knowledge" such as when domains do not share topology information. The problem can be resolved more efficiently (e.g., avoiding the "trap problem") when mutually resource disjoint paths can be computed "simultaneously" on the fullest set of information.
多様な経路計算は、すべてのグラフ理論専攻に馴染みの古典的な問題です。そのようなドメインは、トポロジ情報を共有していない場合など、「民間の知識」の領域が存在する場合に問題が配合されます。問題をより効率的に解決することができる（例えば、「トラップの問題」を回避する）互いに素パス情報の最大限のセットに「同時に」計算することができるリソース場合。
That being said, various techniques (out of the scope of this document) exist to ensure end-to-end path diversity across multiple domains.
それは言われ、（この文書の範囲外）種々の技術は、複数のドメインにわたるエンドツーエンドパスの多様性を確保するために存在します。
Many network technologies utilize "protection domains" because they fit well with the capabilities of the technology. As a result, many domains are operated as protection domains. In this model, protection paths converge at domain boundaries.
彼らは技術の能力とよく合うので、多くのネットワーク技術は、「保護ドメイン」を利用します。その結果、多くのドメインは、保護ドメインとして運用されています。このモデルでは、保護パスは、ドメイン境界に収束します。
Note that the question of SRLG identification is not yet fully answered. There are two classes of SRLG:
SRLG識別の問題はまだ完全には答えていないことに注意してください。 SRLGの2つのクラスがあります。
- those that indicate resources that are all contained within one domain
- すべてのドメイン内に含まれるリソースを示すもの
- those that span domains.
- ドメインにまたがるもの。
The former might be identified using a combination of a globally scoped domain ID, and an SRLG ID that is administered by the domain. The latter requires a global scope to the SRLG ID. Both schemes, therefore, require external administration. The former is able to leverage existing domain ID administration (for example, area and AS numbers), but the latter would require a new administrative policy.
前者は、グローバルスコープドメインIDの組み合わせ、およびドメインによって管理されたSRLGのIDを使用して識別される可能性があります。後者は、SRLG IDにグローバルスコープを必要とします。どちらの方式では、そのため、外部の投与を必要とします。前者は既存のドメインIDの管理（例えば、面積およびAS番号）を活用することが可能であるが、後者は新しい管理政策が必要となります。
While the meaning of certain constraints, like bandwidth, can be assumed to be constant across different domains, other TE constraints (such as resource affinity, color, metric, priority, etc.) may have different meanings in different domains and this may impact the ability to support Diffserv-aware MPLS, or to manage preemption.
特定の制約の意味は、帯域幅のような、異なるドメイン間で一定であると仮定することができるが、（例えばリソースの親和性、色、メトリック、優先度、等のような）他のTE制約は異なるドメインに異なる意味を有していてもよく、これは影響を与える可能性Diffservの対応のMPLSをサポートするため、またはプリエンプションを管理する能力。
In order to achieve consistent meaning and LSP establishment, this fact must be considered when performing constraint-based path computation or when signaling across domain boundaries.
ドメインの境界を越えて、シグナリング時に制約ベースの経路計算を実行するとき、または一貫性の意味とLSPの確立を達成するために、この事実を考慮しなければなりません。
A mapping function can be derived for most constraints based on policy agreements between the domain administrators. The details of such a mapping function are outside the scope of this document, but it is important to note that the default behavior must either be that a constant mapping is applied or that any requirement to apply these constraints across a domain boundary must fail in the absence of explicit mapping rules.
マッピング機能は、ドメイン管理者の間で政策協定に基づいて、最も制約のために導くことができます。このようなマッピング機能の詳細は、このドキュメントの範囲外であるが、デフォルトの動作では、いずれかの一定のマッピングが適用されていることでなければならないことや、ドメイン境界を越えて、これらの制約を適用するどのような要件がで失敗しなければならないことに注意することが重要です明示的なマッピングルールの不在。
Domain boundaries are natural points for policy control. There is little to add on this subject except to note that a TE LSP that cannot be established on a path through one domain because of a policy applied at the domain boundary may be satisfactorily established using a path that avoids the demurring domain. In any case, when a TE LSP signaling attempt is rejected due to non-compliance with some policy constraint, this should be reflected to the ingress LSR.
ドメイン境界は、ポリシー制御のための自然なポイントです。なぜなら、ドメイン境界で適用されるポリシーの一つのドメインを通過する経路上に確立することができないTE LSPが十分demurringドメインを回避し、パスを使用して確立することができることに注意することを除いて、このテーマに追加することはほとんどないです。 TE LSPシグナリング試みが何らかのポリシー制約の不遵守に拒否されたときにどのような場合に、これは、入口LSRに反映されるべきです。
Some elements of OAM may be intentionally confined within a domain. Others (such as end-to-end liveness and connectivity testing) clearly need to span the entire multi-domain TE LSP. Where issues of topology confidentiality are strong, collaboration between PCEs or domain boundary nodes might be required in order to provide end-to-end OAM, and a significant issue to be resolved is to ensure that the end-points support the various OAM capabilities.
OAMのいくつかの要素は、意図的にドメイン内に閉じ込められてもよいです。 （例えば、エンド・ツー・エンドの生存性と接続性テストなど）、他のものは、明らかに全体のマルチドメインTE LSPに及ぶ必要があります。トポロジーの機密性の問題は、のPCEまたはドメイン境界ノード間のコラボレーションは、エンドツーエンドOAMを提供するために強い必要になることがありますされており、重要な問題が解決される場合は、エンドポイントは、様々なOAM機能をサポートすることを確認することです。
The different signaling mechanisms described above may need refinements to [RFC4379], [BFD-MPLS], etc., to gain full end-to-end visibility. These protocols should, however, be considered in the light of topology confidentiality requirements.
上述の異なるシグナル伝達機構は、完全なエンドツーエンドの可視性を得るために、等[RFC4379]、[BFD-MPLS]に改良を必要とするかもしれません。これらのプロトコルは、しかし、トポロジの機密性の要件に照らして検討すべきです。
Route recording is a commonly used feature of signaling that provides OAM information about the path of an established LSP. When an LSP traverses a domain boundary, the border node may remove or aggregate some of the recorded information for topology confidentiality or other policy reasons.
経路記録が確立されたLSPの経路についてのOAM情報を提供するシグナリングの一般的に使用される機能です。 LSPはドメイン境界を横切るときに、ボーダー・ノードは、トポロジ機密またはその他のポリシー上の理由で記録された情報の一部を削除するか、集約することができます。
Inter-domain point-to-multipoint (P2MP) requirements are explicitly out of the scope of this document. They may be covered by other documents dependent on the details of MPLS TE P2MP solutions.
ドメイン間のポイント・ツー・マルチポイント（P2MP）の要件は、この文書の範囲の外に明示されています。彼らは、MPLS TE P2MPソリューションの詳細に依存して他の文書によって覆われていてもよいです。
Non-packet switching technologies may present particular issues for inter-domain LSPs. While packet switching networks may utilize control planes built on MPLS or GMPLS technology, non-packet networks are limited to GMPLS.
非パケットスイッチング技術は、ドメイン間のLSPのための特定の問題を提示することができます。パケット交換ネットワークは、MPLSやGMPLS技術の上に構築された制御プレーンを利用することができる一方で、非パケット・ネットワークは、GMPLSに限定されています。
On the other hand, some problems such as Fast Reroute on domain boundaries (see section 5.4) may be handled by the GMPLS technique of segment protection [GMPLS-SEG] that is applicable to both packet and non-packet switching technologies.
一方、このようなドメインの境界上の高速リルート（セクション5.4を参照）のようないくつかの問題がセグメント保護のGMPLS技術によって処理することができる[GMPLS-SEG]パケットと非パケット交換双方の技術にも適用可能です。
The specific architectural considerations and requirements for inter-domain LSP setup in non-packet networks are covered in a separate document [GMPLS-AS].
非パケットネットワークにおけるドメイン間LSPのセットアップのための具体的なアーキテクチャの考慮事項および要件は、別の文書[GMPLS-AS]で覆われています。
Requirements for security within domains are unchanged from [RFC3209] and [RFC3473], and from [RFC3630] and [RFC3784]. That is, all security procedures for existing protocols in the MPLS context continue to apply for the intra-domain cases.
ドメイン内のセキュリティの要件は[RFC3209]及び[RFC3473]から変化していない、および[RFC3630]及び[RFC3784]から。これは、MPLSの文脈における既存のプロトコルのためのすべてのセキュリティ手順は、ドメイン内のケースに適用していき、あります。
Inter-domain security may be considered as a more important and more sensitive issue than intra-domain security since in inter-domain traffic engineering control and information may be passed across administrative boundaries. The most obvious and most sensitive case is inter-AS TE.
インタードメイントラフィックエンジニアリング管理と情報で管理境界を通過することができるので、ドメイン間のセキュリティは、ドメイン内のセキュリティよりも重要と多くの微妙な問題として考えることができます。最も明らかと最も敏感な場合には、相互AS TEです。
All of the intra-domain security measures for the signaling and routing protocols are equally applicable in the inter-domain case. There is, however, a greater likelihood of them being applied in the inter-domain case.
シグナリングおよびルーティングプロトコルのためのドメイン内のセキュリティ対策のすべては、ドメイン間のケースでも同様に適用可能です。ドメイン間の場合に適用されているそれらのより大きな可能性は、しかし、があります。
Security for inter-domain MPLS TE is the subject of a separate document that analyzes the security deployment models and risks. This separate document must be completed before inter-domain MPLS TE solution documents can be advanced.
ドメイン間MPLS TEのセキュリティは、セキュリティの配置モデルとリスクを分析し、別の文書の主題です。ドメイン間MPLS TEソリューション文書を進めることができる前に、この別の文書を完了する必要があります。
Similarly, the PCE procedures [RFC4655] are subject to security measures for the exchange computation information between PCEs and for LSRs that request path computations from a PCE. The requirements for this security (set out in [RFC4657]) apply whether the LSR and PCE (or the cooperating PCEs) are in the same domain or lie across domain boundaries.
同様に、PCE手順[RFC4655]はのPCE間PCEの経路計算を要求するLSRのための為替計算情報のセキュリティ対策の対象となっています。 （[RFC4657]に記載された）、このセキュリティの要件は、LSR及びPCE（または協力のPCE）は、ドメインの境界を越えて、同じドメインまたは嘘であるかどうかを適用します。
It should be noted, however, that techniques used for (for example) authentication require coordination of secrets, keys, or passwords between sender and receiver. Where sender and receiver lie within a single administrative domain, this process may be simple. But where sender and receiver lie in different administrative domains, cross-domain coordination between network administrators will be required in order to provide adequate security. At this stage, it is not proposed that this coordination be provided through an automatic process or through the use of a protocol. Human-to-human coordination is more likely to provide the required level of confidence in the inter-domain security.
（例えば）認証に使用される技術は、送信側と受信側との間の秘密、キー、またはパスワードの調整を必要とすることに留意すべきです。どこに単一の管理ドメイン内の送信者と受信者の嘘、このプロセスは簡単です。しかし、ここでネットワーク管理者の間で、送信者と受信者の嘘異なる管理ドメインでは、クロスドメインの調整は十分なセキュリティを提供するために必要となります。この段階で、この調整は、自動プロセスを介して、またはプロトコルの使用を介して提供することが提案されていません。ヒトからヒトへの調整は、ドメイン間のセキュリティへの信頼の必要なレベルを提供する可能性が高いです。
One new security concept is introduced by inter-domain MPLS TE. This is the preservation of confidentiality of topology information. That is, one domain may wish to keep secret the way that its network is constructed and the availability (or otherwise) of end-to-end network resources. This issue is discussed in sections 3.4.2, 5.2, and 5.8 of this document. When there is a requirement to preserve inter-domain topology confidentiality, policy filters must be applied at the domain boundaries to avoid distributing such information. This is the responsibility of the domain that distributes information, and it may be adequately addressed by aggregation of information as described in the referenced sections.
一つの新しいセキュリティー概念は、ドメイン間MPLS TEによって導入されます。これは、トポロジ情報の機密性の維持です。つまり、1個のドメインが、そのネットワークが構築されている方法とエンドツーエンドのネットワーク・リソースの可用性（またはその他）を秘密にしておきたいことがあります。この問題は、セクション3.4.2、5.2で説明し、本書の5.8されます。ドメイン間トポロジの機密性を維持する必要がある場合は、ポリシーフィルタには、このような情報の配信を避けるために、ドメイン境界で適用する必要があります。これは、情報を配信するドメインの責任であり、参照の項で説明するように、それは、適切な情報の集合によって対処することができます。
Applicability statements for particular combinations of signaling, routing, and path computation techniques to provide inter-domain MPLS TE solutions are expected to contain detailed security sections.
ドメイン間MPLS TEソリューションを提供するために、シグナリング、ルーティング、および経路計算技術の特定の組み合わせのための適用性ステートメントは詳細なセキュリティセクションを含むことが期待されます。
The authors would like to extend their warmest thanks to Kireeti Kompella for convincing them to expend effort on this document.
著者は、この文書に労力を費やすためにそれらを納得させるためにKireeti Kompellaへの暖かい感謝を拡張したいと思います。
Grateful thanks to Dimitri Papadimitriou, Tomohiro Otani, and Igor Bryskin for their review and suggestions on the text.
テキスト上でのレビューと提案のためのディミトリPapadimitriou、智博大谷、およびイゴールBryskinに感謝感謝。
Thanks to Jari Arkko, Gonzalo Camarillo, Brian Carpenter, Lisa Dusseault, Sam Hartman, Russ Housley, and Dan Romascanu for final review of the text.
テキストの最終審査のためのヤリArkko、ゴンサロ・カマリロ、ブライアン・カーペンター、リサDusseault、サム・ハートマン、ラスHousley、およびダンRomascanuに感謝します。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年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.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）OSPFバージョン2への拡張"、RFC 3630、2003年9月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784]スミット、H.、およびT.李、 "中間システムトラフィックエンジニアリング（TE）のための中間システム（IS-IS）への拡張"、RFC 3784、2004年6月。
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", Work in Progress, June 2006.
[BFD-MPLS]アガルワル、R.、Kompella、K.、ナドー、T.、およびG.ツバメ、 "MPLS LSPのためにBFD"、進歩、2006年6月での作業。
[CRANKBACK] Farrel, A., et al., "Crankback Signaling Extensions for MPLS Signaling", Work in Progress, May 2005.
[クランクバック]ファレル、A.、ら、「MPLSシグナリングのためのクランクバックシグナリング拡張」、進歩、2005年5月での作業。
[EXCLUDE] Lee, CY., Farrel, A., and DeCnodder, "Exclude Routes - Extension to RSVP-TE", Work in Progress, August 2005.
。[除外]リー、CY、ファレル、A.、およびDeCnodderは、 "ルートの除外 - 拡張を-TE RSVPに"、進歩、2005年8月の作業を。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]パン、P.、ツバメ、G.、およびA.アトラスは、RFC 4090、2005年5月 "高速リルート機能拡張は、LSPトンネルの-TEをRSVPに"。
[GMPLS-AS] Otani, T., Kumaki, K., Okamoto, S., and W. Imajuku, "GMPLS Inter-domain Traffic Engineering Requirements", Work in Progress, August 2006.
[GMPLS-AS]大谷、T.、熊木、K.、岡本、S.、およびW. Imajuku、 "GMPLSドメイン間トラフィックエンジニアリングの要件"、進歩、2006年8月に作業。
[GMPLS-E2E] Lang, J.P., Rekhter, Y., and D. Papadimitriou, Editors, "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)- based Recovery", Work in Progress, April 2005.
[GMPLS-E2E]ラング、JP、Rekhter、Y.、およびD. Papadimitriou、編集者、 "RSVP-TE拡張エンドツーエンド一般化マルチプロトコルラベルスイッチング（GMPLS）を支持する - 回復ベース"、仕事で進歩、2005年4月。
[GMPLS-SEG] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Based Segment Recovery", Work in Progress, May 2005.
[GMPLS-SEG]バーガー、L.、Bryskin、I.、Papadimitriou、D.、およびA.ファレル、 "GMPLSに基づくセグメントの回復"、進捗状況、2005年5月での作業。
[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）との交換しました"。
[RFC4105] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105]ル・ルー、J.-L.、Vasseur、J.-P.、およびJ.ボイル、 "エリア間MPLSトラフィックエンジニアリングのための要件"、RFC 4105、2005年6月。
[RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]ラング、J.、 "リンク管理プロトコル（LMP）"、RFC 4204、2005年10月。
[RFC4216] Zhang, R. and J.-P. Vasseur, "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月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K.とG.ツバメ、2006年2月、RFC 4379 "を検出マルチプロトコルラベルは（MPLS）データプレーン障害をスイッチ"。
[RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J.-P., and A. Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006.
[RFC4420]ファレル、A.、Papadimitriou、D.、Vasseur、J.-P.、およびA. Ayyangar、「リソース予約プロトコル・トラフィックを使用して（MPLS）ラベルスイッチパス（LSP）の確立をマルチプロトコルラベルスイッチングのための属性のエンコーディングエンジニアリング（RSVP-TE）」、RFC 4420、2006年2月。
[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月。
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657]アッシュ、J.とJ.ル・ルー、 "パス計算要素（PCE）通信プロトコルジェネリック要件"、RFC 4657、2006年9月。
[STITCH] Ayyangar, A. and J.-P. Vasseur, "LSP Stitching with Generalized MPLS TE", Work in Progress, September 2005.
[ステッチ] Ayyangar、A.及びJ.-P. Vasseur、 "一般化MPLS TEでLSPステッチ"、進歩、2005年9月での作業。
Authors' Addresses
著者のアドレス
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
エードリアンファレル老犬のコンサルティングメール：adrian@olddog.co.uk
Jean-Philippe Vasseur Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA EMail: jpv@cisco.com
ジャン=フィリップVasseurシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719 USA電子メール：jpv@cisco.com
Arthi Ayyangar Nuova Systems EMail: arthi@nuovasystems.com
Aartiアイアンガーは、システムの電子メールをnuvuva：ఆర్తి@నువువసిస్టమ్స్.కం
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
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彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、IETFトラスト、インターネットエンジニアリングタスクフォース放棄情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されないすべての保証、明示または黙示、。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。