[要約] RFC 4726は、異なるドメイン間でのMultiprotocol Label Switching（MPLS）トラフィックエンジニアリングのフレームワークを提供しています。このRFCの目的は、異なるドメイン間でのMPLSネットワークのトラフィック制御と最適化を支援することです。
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).
Copyright（c）The IETF Trust（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）領域と自律システム（ASES）が含まれます。
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）およびインテリアゲートウェイプロトコル（IGPS）（つまり、中間システムから中間システム（IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-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.
これらの手法の機能的成分は、到達可能性とTE情報を発見するためのメカニズムに分けられ、LSPの経路を計算し、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）トラフィックに適用するために等しく使用されていることに注意してください。ドメイン間環境でのGMPLの使用に関する特定の問題（たとえば、ドメイン間リンクでのリンク管理プロトコル[RFC4204]の使用のポリシーへの影響）は、[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領域と自律システムが含まれます。完全または部分的に重複するドメイン（たとえば、エリアまたはASEのパス計算サブドメインなど）は、このドキュメントの範囲内ではありません。
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がドメインBに完全に含まれている場合、ドメインAはドメイン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.
複数のドメインで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.
1つのTE LSPを別のTELSP内に運ぶ手法は、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のシグナリング要求の受領である可能性があります。ドメインを横断する必要があるトラフィックによって階層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とセッションオブジェクトは、エンドツーエンドの重要性を持つ他のすべてのオブジェクトと同様に、ネストされた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は、そのパス全体（つまり、各LSRで）全体に沿って同じセッション/LSP IDを使用します。異なる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ステッチモデルでは、個別のLSP（TE 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.
前のセクションにもかかわらず、Ingress LSRは、ネットワーク全体のドメイン境界で特定のLSPに適用される信号方法を制限したい場合があります。そのようなコントロールは、必要な場合、セッションアトリブオブジェクトの適切な新しいフラグの定義またはlsp_attributesオブジェクト[RFC4420]の属性フラグTLVの定義によって達成される場合があります。このレベルの制御を提供するメカニズムを定義する前に、ネットワークがサービスを提供する方法を制御するための機能的要件を確立する必要があります。また、新しいメカニズムは後方互換性がなければならないため、相互運用性への影響を考慮する必要があり、それぞれがそれぞれを確立できないように異なる機能サブセットをサポートする標準コンフォーマントの実装を許可することを避けるために注意する必要があります。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またはサービス要求の一部としてIngress LSRに供給され、送信されるパスメッセージの明示的なルートオブジェクト（ERO）としてIngress 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.
これらの2つの明示的なパス形式は、利用可能な情報に従って混合して、ルーズホップと抽象ノードのさまざまな組み合わせをもたらします。
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.
Ingressベースの計算の最終的な可能性は、Ingress 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は、少なくとも次のドメインにそれを運ぶためにパスメッセージに十分なパス情報が追加されていることを保証する責任があります境界（つまり、新しいドメインの外）。
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が出口を完全に可視化する場合、明示的なパス全体を供給できます。ただし、[RFC3209]のERO処理ルールは、次の指定されたホップ（つまり、元の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の定義を使用）しかない場合、次のドメイン境界までパスを埋め、存在していない場合はさらにドメイン/ドメインの境界情報を提供します。エロ。
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が直接的なドメインに局所的に可視される場合、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は、異なる計算機能を持ち、異なるパス計算アルゴリズムを実行し、さまざまな制約と最適化基準のセットを適用するなど、Ingress 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がパスメッセージで使用できない場合でも使用できません。除外を提供するために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は、パス計算（およびセクション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または複数の共同PCESは、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.
PCESを使用する3番目の方法は、単にドメインごとに1つ（またはそれ以上）を持つことです。ドメインを介してパスを導き出したいドメイン内の各LSRは、ローカルPCEを参照する場合があります。
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.
パス計算に適用される制約に応じて、最適なパスには多くの定義があります。マルチドメイン環境では、定義は乗算され、最適なルートがドメインの境界がない場合に計算されるルートとして定義されるようになります。あるいは、PATH計算に別の制約を適用して、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.
トラフィックエンジニアリング情報は、PATH計算アルゴリズムが直接または最初にネットワークグラフの構築によって動作する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情報は、IGPS [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情報のフィルタリングがドメイン境界で適用される場合があります。このフィルタリングは、1つまたは2つの方法である場合があります。
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).
パス計算（たとえば、Ingress LSR）を実行するLSRは、独自のドメインだけでなく、他のドメインのトポロジとTE情報を取得する可能性があります。この情報は、広告ドメインによって適用されるフィルタリングの対象となる場合があります（たとえば、情報は、他のドメインに隣接する隣接（FA）に限定される場合があります。または、情報が集約または抽象化される場合があります）。
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拡張機能と、宣伝された情報がIGPSにどのように供給されるかを考慮する必要があります。ドメイン境界での処理量（集約計算など）の大幅な増加を引き起こす拡張機能、または浸水した情報の量（詳細な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関数に配置された制約に関するいくつかの非定義コメントを提供します。ドメイン間技術を使用することの意味を述べようとはしません。このような資料は、リストされている機能を提供するための既存または将来のシグナル、ルーティング、および計算技術の機能に関するステートメントを作成する必要がある適切な適用可能性ステートメントに延期されます。
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 Explicit style is usually used to avoid double booking of network resources.
再最適化は、TE LSPをあるパスから別のパスに移動するプロセスであり、より好ましいパス（「最適」を定義する試みが行われなかったため、「好ましい」を定義する試みが行われません）。通常、ブレイク前の手法が適用され、トラフィックが可能な限り破壊されないようにします。共有された明示的なスタイルは、通常、ネットワークリソースの二重予約を避けるために使用されます。
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、侵入、またはドメインのエントリポイントであるかどうか）1つのパスの再最適化を試みる前に、そのようなすべてのパスを知る必要があります。ここでの相互の多様性は、計算されたパスのセットに共通性がないことを意味します。このような多様性は、リンク、ノード、共有リスクリンクグループ（SRLG）、または状況と提供されるサービスに応じてドメインのばらばらでさえあります。
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.
障害が発生したドメイン内で障害をバイパスできない場合（おそらく適切な代替ルートがない場合、おそらくドメインポリシーによって再ルーティングが許可されていない場合、またはパスメッセージがそのようなアクションを特別に禁止する可能性があります）。前またはヘッドエンドドメイン。
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.
その後の修理の試みは、ドメインによってさらに上流に行われる場合がありますが、障害やその他の失敗した修復試行に関する十分な情報が上流に渡された場合にのみ適切に効果的です[Crankback]。クランクバック集約はドメイン境界で適用できる場合でも、この要件とトポロジーの機密性の要件との間に緊張があることに注意してください。
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を信号するさらなる試みは、障害に関する情報をパス計算に制約として適用するか、特定のパス除外としてそれらを信号する場合があります[除外]。
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は、再ルーティングによって動的に修復される場合があります。この場合の動作は、再最適化の場合、またはセットアップの障害を処理するためのものです（前の2つのセクションを参照）。Fast Rerouteも使用できます（以下を参照）。
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トラフィックエンジニアリングファストReroute（[RFC4090]）は、Link/SRLG/ノード障害時に高速に再登録可能なパケットベースのTE LSPの迅速な回復（10S）を提供することを目的としたローカル保護スキームを定義します。バックアップTE LSPは、各ホップで構成および信号を設定し、ネットワーク要素の障害を検出または通知されたときにアクティブ化されます。障害のすぐ上流（PLRまたはローカル修理のポイント）のノードは、保護された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]が「1対1モード」と「施設バックアップモード」と呼ばれる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:
- 両方のドメインに存在するドメインエッジノードの障害。2つのサブケースがあります。
- 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.
- ドメインの1つにのみ存在するドメインエッジノードの障害。
- 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を参照）。再最適化のポイント（たとえば、Ingress 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
- すべて1つのドメイン内に含まれるリソースを示すもの
- 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管理（たとえば、領域や数字）を活用することができますが、後者には新しい管理ポリシーが必要です。
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-aware 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.
ドメインの境界は、政策制御の自然なポイントです。ドメインの境界に適用されるポリシーが適用されるため、1つのドメインを通るパスで確立できないTE LSPが、境界線を回避するパスを使用して十分に確立できることを除いて、この主題に追加することはほとんどありません。いずれにせよ、何らかのポリシーの制約に違反していないため、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全体に及ぶ必要があります。トポロジの機密性の問題が強い場合、エンドツーエンドのOAMを提供するためにPCESまたはドメイン境界ノード間のコラボレーションが必要になる場合があります。解決する重要な問題は、エンドポイントがさまざまな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テクノロジー上に構築されたコントロールプレーンを利用する場合がありますが、非パケットネットワークはGMPLに限定されます。
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-SEG]のGMPLS技術によって処理される場合があります。
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.
ドメイン間のトラフィックエンジニアリングの制御と情報が管理境界を越えて渡される可能性があるため、ドメイン間のセキュリティは、ドメイン内のセキュリティよりも重要で敏感な問題と見なされる場合があります。最も明白で最も敏感なケースは、間隔です。
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.
1つの新しいセキュリティコンセプトは、ドメイン間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.
Dimitri Papadimitriou、Tomohiro otani、およびIgor Bryskinに感謝します。テキストに関するレビューと提案に感謝します。
Thanks to Jari Arkko, Gonzalo Camarillo, Brian Carpenter, Lisa Dusseault, Sam Hartman, Russ Housley, and Dan Romascanu for final review of the text.
Jari Arkko、Gonzalo Camarillo、Brian Carpenter、Lisa Dusseault、Sam Hartman、Russ Housley、Dan Romascanuに感謝します。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「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] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（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] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to 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] Smit、H。およびT. Li、「トラフィックエンジニアリングの中間システム（IS-IS）拡張（TE）」、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] Aggarwal、R.、Kompella、K.、Nadeau、T。、およびG. Swallow、「MPLS LSPSのBFD」、2006年6月、進行中の作業。
[CRANKBACK] Farrel, A., et al., "Crankback Signaling Extensions for MPLS Signaling", Work in Progress, May 2005.
[Crankback] Farrel、A.、et al。、「MPLS SignalingのCrankbackシグナル伝達拡張」、2005年5月の作業。
[EXCLUDE] Lee, CY., Farrel, A., and DeCnodder, "Exclude Routes - Extension to RSVP-TE", Work in Progress, August 2005.
[除外] Lee、Cy。、Farrel、A。、およびDeCnodder、「除外ルート - RSVP -TEへの拡張」、2005年8月、進行中の作業。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090] Pan、P.、Swallow、G。、およびA. Atlas、「LSPトンネルのRSVP-TEへの高速拡張式」、RFC 4090、2005年5月。
[GMPLS-AS] Otani, T., Kumaki, K., Okamoto, S., and W. Imajuku, "GMPLS Inter-domain Traffic Engineering Requirements", Work in Progress, August 2006.
[GMPLS-AS] Otani、T.、Kumaki、K.、Okamoto、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] Lang、J.P.、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] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「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、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチ付きパス（LSP）階層」、2005年10月。
[RFC4105] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105] Le Roux、J.-L.、Vasseur、J.-P.、およびJ. Boyle、「エリア間MPLSトラフィックエンジニアリングの要件」、RFC 4105、2005年6月。
[RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204] Lang、J。、「Link Management Protocol（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] Zhang、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. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[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] Farrel、A.、Papadimitriou、D.、Vasseur、J.P.、およびA. Ayyangar、「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチ型パス（LSP）の属性のエンコーディングリソース予約プロトコルトラフィックを使用した確立Engineering（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] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（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] Ash、J。およびJ. Le Roux、「パス計算要素（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 Farrel Old Dog Consultingメール：adrian@olddog.co.uk
Jean-Philippe Vasseur Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA EMail: jpv@cisco.com
Jean-Philippe Vasseur Cisco Systems、Inc 1414 Massachusetts Avenue Boxborough、MA 01719 USAメール：jpv@cisco.com
Arthi Ayyangar Nuova Systems EMail: arthi@nuovasystems.com
Arthi Ayyangar Nuova Systems Email：arthi@nuovasystems.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースは免責明示的または暗示されたすべての保証。ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。