[要約] RFC 4927は、異なるエリア間のMPLSおよびGMPLSトラフィックエンジニアリングにおけるPath Computation Element Communication Protocol（PCECP）の特定要件を定義しています。このRFCの目的は、エリア間のトラフィックエンジニアリングにおけるPCECPの適用と相互運用性を促進することです。
Network Working Group J.-L. Le Roux, Ed.
Request for Comments: 4927 France Telecom
Category: Informational June 2007
Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering
パス計算要素通信プロトコル（PCECP）エリア間MPLSおよびGMPLSトラフィックエンジニアリングの特定の要件
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 (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
For scalability purposes, a network may comprise multiple Interior Gateway Protocol (IGP) areas. An inter-area Traffic Engineered Label Switched Path (TE-LSP) is an LSP that transits through at least two IGP areas. In a multi-area network, topology visibility remains local to a given area, and a head-end Label Switching Router (LSR) cannot compute an inter-area shortest constrained path. One key application of the Path Computation Element (PCE)-based architecture is the computation of inter-area TE-LSP paths. The PCE Communication Protocol (PCECP) is used to communicate computation requests from Path Computation Clients (PCCs) to PCEs, and to return computed paths in responses. This document lists a detailed set of PCECP-specific requirements for support of inter-area TE-LSP path computation. It complements the generic requirements for a PCE Communication Protocol.
スケーラビリティ目的で、ネットワークは複数のインテリアゲートウェイプロトコル（IGP）領域で構成される場合があります。エリア間交通エンジニアリングラベルスイッチドパス（TE-LSP）は、少なくとも2つのIGPエリアを通過するLSPです。マルチエリアネットワークでは、トポロジの可視性は特定の領域に局所的な存在のままであり、ヘッドエンドラベルスイッチングルーター（LSR）は、エリア間の最短制約パスを計算できません。PATH計算要素（PCE）ベースのアーキテクチャの重要なアプリケーションの1つは、エリア間LSPパスの計算です。PCE通信プロトコル（PCECP）は、Path Computation Clients（PCCS）からPCESへの計算要求を通信し、応答の計算パスを返すために使用されます。このドキュメントには、エリア間TE-LSPパス計算をサポートするためのPCECP固有の要件の詳細なセットがリストされています。PCE通信プロトコルの一般的な要件を補完します。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
2.1. Conventions Used in This Document ..........................4
3. Motivations for PCE-Based Inter-Area Path Computation ...........4
4. Detailed Inter-Area Specific Requirements on PCECP ..............5
4.1. Control and Recording of Area Crossing .....................5
4.2. Area Recording .............................................6
4.3. Strict Explicit Path and Loose Path ........................6
4.4. PCE List Enforcement and Recording in Multiple-PCE
Computation ................................................6
4.5. Inclusion of Area IDs in Request ...........................7
4.6. Area Inclusion/Exclusion ...................................7
4.7. Inter-Area Diverse Path Computation ........................7
4.8. Inter-Area Policies ........................................8
4.9. Loop Avoidance .............................................8
5. Manageability Considerations ....................................9
6. Security Considerations .........................................9
7. Acknowledgments .................................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References ....................................10
9. Contributors ...................................................10
[RFC4105] lists a set of motivations and requirements for setting up TE-LSPs across IGP area boundaries. These LSPs are called inter-area TE-LSPs. These requirements include the computation of inter-area shortest constrained paths with a key guideline being to respect the IGP hierarchy concept, and particularly the containment of topology information. The main challenge with inter-area MPLS-TE lies in path computation. Indeed, the head-end LSR cannot compute an explicit path across areas, as its topology visibility is limited to its own area.
[RFC4105]は、IGP領域の境界全体にTE-LSPを設定するための一連の動機と要件をリストしています。これらのLSPは、インターエアリーLSPと呼ばれます。これらの要件には、IGP階層の概念を尊重することである主要なガイドラインと、特にトポロジー情報の封じ込めである主要なガイドラインで、エリア間で最短の制約パスの計算が含まれます。エリア間MPLS-TEの主な課題は、パス計算にあります。実際、トポロジの可視性は独自の領域に限定されているため、ヘッドエンドLSRは領域間の明示的なパスを計算することはできません。
Inter-area path computation is one of the key applications of the PCE-based architecture [RFC4655]. The computation of optimal inter-area paths may be achieved using the services of one or more PCEs.
エリア間パス計算は、PCEベースのアーキテクチャ[RFC4655]の重要なアプリケーションの1つです。最適なエリア間パスの計算は、1つ以上のPCEのサービスを使用して達成できます。
Such PCE-based inter-area path computation could rely for instance on a single multi-area PCE that has the TE database of all the areas in the IGP domain and can directly compute an end-to-end constrained shortest path. Alternatively, this could rely on the cooperation between PCEs whereby each PCE covers one or more IGP areas and the full set of PCEs covers all areas.
このようなPCEベースのエリア間パス計算は、たとえば、IGPドメイン内のすべての領域のTEデータベースを持つ単一のマルチエリアPCEに依存し、エンドツーエンドの制約最短パスを直接計算できます。あるいは、これは、各PCEが1つ以上のIGP領域をカバーし、PCEの完全なセットがすべての領域をカバーするPCE間の協力に依存する可能性があります。
The generic requirements for a PCE Communication Protocol (PCECP), which allows a PCC to send path computation requests to a PCE and the PCE to send path computation responses to a PCC, are set forth in [RFC4657]. The use of a PCE-based approach for inter-area path computation implies specific requirements on a PCE Communication Protocol, in addition to the generic requirements already listed in [RFC4657]. This document complements these generic requirements by listing a detailed set of PCECP requirements specific to inter-area path computation.
PCCがPCCとPCCにパス計算要求を送信してPCCにパス計算応答を送信できるPCC通信プロトコル（PCECP）の一般的な要件は、[RFC4657]に記載されています。エリア間パス計算にPCEベースのアプローチを使用することは、[RFC4657]に既にリストされている一般的な要件に加えて、PCE通信プロトコルの特定の要件を意味します。このドキュメントは、エリア間パス計算に固有のPCECP要件の詳細なセットをリストすることにより、これらの一般的な要件を補完します。
It is expected that PCECP procedures be defined to satisfy these requirements.
これらの要件を満たすためにPCECP手順を定義することが期待されています。
Note that PCE-based inter-area path computation may require a mechanism for automatic PCE discovery across areas, which is out of the scope of this document. Detailed requirements for such a mechanism are discussed in [RFC4674].
PCEベースのエリア間パス計算には、このドキュメントの範囲外であるエリア全体で自動PCE発見のメカニズムが必要になる場合があることに注意してください。このようなメカニズムの詳細な要件は、[RFC4674]で説明されています。
LSR: Label Switching Router.
LSR：ラベルスイッチングルーター。
LSP: MPLS Label Switched Path.
LSP：MPLSラベルの切り替えパス。
TE-LSP: Traffic Engineered Label Switched Path.
TE-LSP：トラフィックエンジニアリングラベルの切り替えパス。
IGP area: OSPF area or IS-IS level.
IGPエリア：OSPFエリアまたはIS-ISレベル。
ABR: IGP Area Border Router, a router that is attached to more than one IGP area (ABR in OSPF or L1/L2 router in IS-IS).
ABR：IGPエリアボーダールーター、複数のIGPエリアに取り付けられたルーター（OSPFのABRまたはIS-ISのL1/L2ルーター）。
Inter-Area TE-LSP: TE-LSP that traverses more than one IGP area.
エリア間TE-LSP：TE-LSPは、複数のIGP領域を通過します。
CSPF: Constrained Shortest Path First.
CSPF：最初に最短パスを制約します。
SRLG: Shared Risk Link Group.
SRLG：共有リスクリンクグループ。
PCE: Path Computation Element: an entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
PCE：パス計算要素：ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用できるエンティティ（コンポーネント、アプリケーション、またはネットワークノード）。
PCC: Path Computation Client, any application that request path computation to be performed by a PCE.
PCC：Path Computationクライアント、PCEによって実行されるパス計算を要求するアプリケーション。
PCECP: PCE Communication Protocol, a protocol for communication between PCCs and PCEs, and between PCEs.
PCECP：PCCSとPCES間の通信のためのプロトコル、およびPCE間のPCE通信プロトコル。
ERO: Resource Reservation Protocol (RSVP)-TE Explicit Route Object. It encodes the explicit path followed by a TE-LSP.
ERO：リソース予約プロトコル（RSVP）-TE明示的なルートオブジェクト。明示的なパスに続いてTE-LSPがエンコードします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
IGP hierarchy enables improved IGP scalability by dividing the IGP domain into areas and limiting the flooding scope of topology information to within area boundaries. A router in an area has full topology information for its own area, but only information about reachability to destinations in other areas. Thus, a head-end LSR cannot compute an end-to-end path that crosses the boundary of its IGP area(s).
IGP階層により、IGPドメインをエリアに分割し、トポロジー情報の洪水範囲を領域内の境界内に制限することにより、IGPスケーラビリティが向上します。エリアのルーターには、独自のエリアの完全なトポロジー情報がありますが、他のエリアの目的地への到達可能性に関する情報のみがあります。したがって、ヘッドエンドLSRは、IGP領域の境界を横切るエンドツーエンドパスを計算することはできません。
A current solution for computing inter-area TE-LSP path relies on a per-domain path computation [PD-COMP]. It is based on loose hop routing with an ERO expansion on each ABR. This allows an LSP to be set up following a constrained path, but faces two major limitations:
エリア間TE-LSPパスを計算するための現在のソリューションは、ドメインごとのパス計算[PD-COMP]に依存しています。それは、各ABRにERO拡張を伴うルースホップルーティングに基づいています。これにより、制約付きパスに従ってLSPをセットアップできますが、2つの主要な制限に直面しています。
- This does guarantee the use of an optimal constrained path.
- これにより、最適な制約パスの使用が保証されます。
- This may lead to several crankback signaling messages and hence delay the LSP setup, and may also invoke possible alternate routing activities.
- これにより、いくつかのクランクバックシグナリングメッセージが発生する可能性があるため、LSPのセットアップが遅れ、可能な代替ルーティングアクティビティを呼び出す可能性もあります。
Note that, here, by optimal constrained path we mean the shortest constrained path across multiple areas, taking into account either the IGP or TE metric [RFC3785]. In other words, such a path is the path that would have been computed by making use of some CSPF algorithm in the absence of multiple IGP areas.
ここでは、最適な制約パスにより、IGPまたはTEメトリック[RFC3785]のいずれかを考慮して、複数の領域にわたって最短の制約パスを意味することに注意してください。言い換えれば、そのようなパスは、複数のIGP領域がない場合にCSPFアルゴリズムを使用することで計算されるパスです。
The PCE-based architecture [RFC4655] is well suited to inter-area path computation. It allows the path computation limitations resulting from the limited topology visibility to be overcome by introducing path computation entities with more topology visibility, or by allowing cooperation between path computation entities in each area.
PCEベースのアーキテクチャ[RFC4655]は、エリア間パス計算に適しています。これにより、限られたトポロジの可視性に起因するパス計算制限を、より多くのトポロジの可視性を持つパス計算エンティティを導入するか、各エリアのパス計算エンティティ間の協力を許可することにより、克服できます。
There are two main approaches for the computation of an inter-area optimal path:
エリア間最適パスの計算には2つの主要なアプローチがあります。
- Single-PCE computation: The path is computed by a single PCE that has topology visibility in all areas and can compute an end-to-end optimal constrained path on its own.
- 単一PCE計算：パスは、すべての領域でトポロジの可視性を持ち、独自にエンドツーエンドの最適制約パスを計算できる単一のPCEによって計算されます。
- Multiple-PCE computation with inter-PCE communication: The path computation is distributed on multiple PCEs, which have partial topology visibility. They compute path segments in their domains of visibility and collaborate with each other so as to arrive at an end-to-end optimal constrained path. Such collaboration is ensured thanks to inter-PCE communication.
- PCE間通信を使用した複数PCE計算：パス計算は、部分的なトポロジの可視性を持つ複数のPCESに分散されます。それらは、可視性のドメイン内のパスセグメントを計算し、エンドツーエンドの最適な制約パスに到達するために互いに協力します。このようなコラボレーションは、PCE間通信のおかげで保証されます。
Note that the use of a PCE-based approach to perform inter-area path computation implies specific functional requirements in a PCECP, in addition to the generic requirements listed in [RFC4657]. These specific requirements are discussed in the next section.
[RFC4657]にリストされている一般的な要件に加えて、PCEベースのアプローチを使用してエリア間パス計算を実行することは、PCECPの特定の機能要件を意味することに注意してください。これらの特定の要件については、次のセクションで説明します。
This section lists a set of additional requirements for the PCECP that complement requirements listed in [RFC4657] and are specific to inter-area (G)MPLS-TE path computation.
このセクションでは、[RFC4657]にリストされている要件を補完するPCECPの追加要件のセットをリストし、エリア（G）MPLS-TEパス計算に固有のものです。
In addition to the path constraints specified in [RFC4657], the request message MUST allow indicating whether or not area crossing is permitted. Indeed, when the source and destination reside in the same IGP area, there may be intra-area and inter-area feasible paths. As set forth in [RFC4105], if the shortest path is an inter-area path, an operator either may want to avoid, as far as possible, crossing areas and thus may prefer selecting a sub-optimal intra-area path or, conversely, may prefer to use a shortest path, even if it crosses areas.
[RFC4657]で指定されたパスの制約に加えて、リクエストメッセージは、エリアの交差が許可されているかどうかを示すことを許可する必要があります。実際、ソースと目的地が同じIGP領域に存在する場合、エリア内およびエリア間の実行可能なパスが存在する可能性があります。[RFC4105]に記載されているように、最短経路がエリア間経路である場合、オペレーターは可能な限り避け、したがって、最適なエリア内パスを選択することを好むかもしれません。、エリアを横断する場合でも、最短パスを使用することを好む場合があります。
Also, when the source and destination reside in the same area it may be useful to know whether the returned path is an inter-area path. Hence, the response message MUST allow indicating whether the computed path is crossing areas.
また、ソースと目的地が同じエリアに存在する場合、返された経路がエリア間パスであるかどうかを知ることが役立つ場合があります。したがって、応答メッセージは、計算されたパスが領域を横断しているかどうかを示すことを許可する必要があります。
It may be useful for the PCC to know the set of areas crossed by an inter-area path and the corresponding path segments. Hence, the response message MUST allow identifying the crossed areas. Also, the response message MUST allow segmenting the returned path and marking each segment so that it is possible to tell which piece of the path lies within which area.
PCCが、エリア間経路と対応するパスセグメントによって交差した一連のエリアを知ることは有用かもしれません。したがって、応答メッセージは、交差領域を識別できるようにする必要があります。また、応答メッセージは、返されたパスをセグメント化し、各セグメントをマークすることを許可する必要があります。これにより、パスのどの部分がどの領域にあるかを知ることができます。
A Strict Explicit Path is defined as a set of strict hops, while a Loose Path is defined as a set of at least one loose hop and zero, one or more strict hops. An inter-area path may be strictly explicit or loose (e.g., a list of ABRs as loose hops). It may be useful to indicate to the PCE if a Strict Explicit path is required or not. Hence, the PCECP request message MUST allow indicating whether a Strict Explicit Path is required/desired.
厳密な明示的なパスは厳格ホップのセットとして定義され、ゆるいパスは少なくとも1つのルーズホップとゼロ、1つ以上の厳格なホップのセットとして定義されます。エリア間パスは、厳密に明示的または緩んでいる場合があります（例えば、緩いホップとしてのABRのリスト）。厳密な明示的なパスが必要であるかどうかをPCEに示すことは有用かもしれません。したがって、PCECP要求メッセージは、厳密な明示的なパスが必要/望ましいかどうかを示すことを許可する必要があります。
In case of multiple-PCE inter-area path computation, a PCC may want to indicate a preferred list of PCEs to be used, one per area. In each area, the preferred PCE should be tried before another PCE is selected. Note that if there is no preferred PCE indicated for an area, any PCE in that area may be used.
複数のPCEエリア間パス計算の場合、PCCは、使用するPCEの優先リストを示したい場合があります。各領域では、別のPCEが選択される前に、優先されたPCEを試してみる必要があります。面積に適した優先PCEがない場合、そのエリアのPCEが使用される可能性があることに注意してください。
Hence, the PCECP request message MUST support the inclusion of a list of preferred PCEs per area. Note that this requires that a PCC in one area has knowledge of PCEs in other areas. This could rely on configuration or on a PCE discovery mechanism, allowing discovery across area boundaries (see [RFC4674]).
したがって、PCECPリクエストメッセージは、領域ごとの優先PCEのリストを含めることをサポートする必要があります。これには、ある領域のPCCが他の領域のPCEの知識を持っていることが必要であることに注意してください。これは、構成またはPCE発見メカニズムに依存して、面積境界を越えて発見を可能にする可能性があります（[RFC4674]を参照）。
Also, it would be useful to know the list of PCEs that effectively participated in the computation. Hence, the request message MUST support a request for PCE recording, and the response message MUST support the recording of the set of one or more PCEs that took part in the computation.
また、計算に効果的に参加したPCEのリストを知ることは有用です。したがって、リクエストメッセージはPCE記録のリクエストをサポートする必要があり、応答メッセージは、計算に参加した1つ以上のPCEのセットの記録をサポートする必要があります。
It may also be useful to know the path segments computed by each PCE. Hence, the request message SHOULD allow a request for the identification of path segments computed by a PCE, and the response message SHOULD allow identifying the path segments computed by each PCE.
また、各PCEによって計算されたパスセグメントを知ることも役立つ場合があります。したがって、リクエストメッセージは、PCEによって計算されたパスセグメントの識別のリクエストを許可する必要があり、応答メッセージは各PCEによって計算されたパスセグメントを識別できるようにする必要があります。
Knowledge of the areas in which the source and destination lie would allow a PCE to select an appropriate downstream PCE. This would be useful when the area ID(s) of a PCE (i.e., the area(s) where it has visibility) is/are known, which can be achieved by the PCE Discovery Protocol (see [RFC4674]) or by any other means.
ソースと目的地が嘘をつく領域の知識により、PCEが適切な下流のPCEを選択できるようになります。これは、PCEの面積ID（つまり、可視性がある領域）が既知である場合に役立ちます。他の意味。
A PCE may not have any visibility of the source/destination area and hence may not be able to determine the area of the source/destination. In such a situation, it would be useful for a PCC to indicate the source and destination area IDs in its request message.
PCEには、ソース/宛先エリアの可視性がない場合があるため、ソース/宛先の面積を決定できない場合があります。このような状況では、PCCがリクエストメッセージにソースと宛先エリアIDを示すことが役立ちます。
For that purpose, the request message MUST support the inclusion of the source and destination area IDs. Note that this information could be learned by the PCC through configuration.
そのために、リクエストメッセージは、ソースおよび宛先エリアIDの含有をサポートする必要があります。この情報は、構成を介してPCCによって学習できることに注意してください。
In some situations, it may be useful for the request message to indicate one or more area(s) that must be followed by the path to be computed. It may also be useful for the request message to indicate one or more area(s) that must be avoided by the path to be computed (e.g., request for a path between LSRs in two stub areas connected to the same ABR(s), which must not cross the backbone area). Hence, the request message MUST allow indicating a set of one or more area(s) that must be explicitly included in the path, and a set of one or more area(s) that must be explicitly excluded from the path.
状況によっては、要求メッセージが計算するパスが続く必要がある1つ以上の領域を示すことが役立つ場合があります。また、要求メッセージが計算するパスによって回避する必要がある1つ以上の領域を示すことも役立つ場合があります（たとえば、同じABRに接続された2つのスタブエリアでのLSR間のパスの要求、バックボーン領域を渡ってはなりません）。したがって、要求メッセージは、パスに明示的に含める必要がある1つ以上の領域のセットと、パスから明示的に除外する必要がある1つ以上の領域のセットを示すことを許可する必要があります。
For various reasons, including protection and load balancing, the computation of diverse inter-area paths may be required. There are various levels of diversity in an inter-area context:
保護と負荷のバランスを含むさまざまな理由により、多様なエリア間パスの計算が必要になる場合があります。エリア間コンテキストにはさまざまなレベルの多様性があります。
- Per-area diversity (intra-area path segments are link, node, or SRLG disjoint)
- エリアごとの多様性（エリア内パスセグメントは、リンク、ノード、またはSRLGの否定です）
- Inter-area diversity (end-to-end inter-area paths are link, node, or SRLG disjoint)
- エリア間の多様性（エンドツーエンドのエリア間パスは、リンク、ノード、またはSRLGの否定です）
Note that two paths may be disjoint in the backbone area but non-disjoint in peripheral areas. Also two paths may be node-disjoint within areas but may share ABRs, in which case path segments within an area are node-disjoint, but end-to-end paths are not node disjoint.
2つのパスは、バックボーン領域ではばらばらである可能性がありますが、周辺領域では非相性があります。また、2つのパスはエリア内のノードディスジョイントですが、ABRを共有する場合があります。この場合、エリア内のパスセグメントはノードダイジョンですが、エンドツーエンドのパスはノードの分離ではありません。
The request message MUST allow requesting the computation of a set of inter-area diverse paths between the same node pair or between distinct node pairs. It MUST allow indicating the required level of diversity of a set of inter-area paths (link, node, and SRLG diversity), as well as the required level of diversity of a set of intra-area segments of inter-area paths (link, node, and SRLG diversity) on a per-area basis.
リクエストメッセージは、同じノードペア間または個別のノードペア間で、エリア間の多様なパスのセットの計算を要求することを許可する必要があります。エリア間パスのセット（リンク、ノード、およびSRLGの多様性）の必要な多様性のレベルを示すこと、およびエリア間パスのエリア内セグメントのセットの多様性の必要なレベルを示す必要があります（リンク、ノード、およびSRLGの多様性）エリアごとに。
The response message MUST allow indicating the level of diversity of a set of computed inter-area loose paths (link, node, and SRLG diversity), globally, and on a per-area basis (link, node, and SRLG diversity of intra-area path segments).
応答メッセージは、グローバルに、およびエリアごと（リンク、ノード、およびSRLGの多様性の多様性（リンク、ノード、およびSRLGの多様性）のセット（リンク、ノード、およびSRLGの多様性）のセットの多様性を示すことを許可する必要があります。エリアパスセグメント）。
Note that, in order to ensure SRLG consistency, SRLG identifiers within the IGP domain should be assigned and allocated by the same entity.
SRLGの一貫性を確保するために、IGPドメイン内のSRLG識別子を同じエンティティによって割り当てて割り当てる必要があることに注意してください。
Note that specific objective functions may be requested for diverse path computation, such as minimizing the cumulated cost of a set of diverse paths as set forth in [RFC4657].
[RFC4657]に記載されている一連の多様なパスの累積コストを最小化するなど、さまざまなパス計算には特定の目的関数が要求される場合があることに注意してください。
In addition to the policy requirements discussed in [RFC4657], the application of inter-area path computation policies requires some additional information to be carried in the PCECP request messages. The request message MUST allow for the inclusion of the address of the originating PCC. This may be useful in a multiple-PCE computation, so as to apply policies not only based on the PCECP peer but also based on the originating PCC.
[RFC4657]で議論されているポリシー要件に加えて、エリア間パス計算ポリシーを適用するには、PCECP要求メッセージでいくつかの追加情報を掲載する必要があります。リクエストメッセージは、発生するPCCのアドレスを含めることを許可する必要があります。これは、PCECPピアだけでなく、発生するPCCに基づいてポリシーを適用するために、複数のPCE計算でも役立つ場合があります。
Note that work on supported policy models and the corresponding requirements/implications is being undertaken as a separate work item in the PCE working group [PCE-POL-FMWK].
サポートされているポリシーモデルの作業と、対応する要件/影響は、PCEワーキンググループ[PCE-POL-FMWK]の別の作業項目として行われていることに注意してください。
In case of multiple-PCE inter-area path computation, there may be risks of PCECP request loops. A mechanism MUST be defined to detect and correct PCECP request message loops. This may rely, for instance, on the recording, in the request message, of the set of traversed PCEs.
複数のPCEエリア間パス計算の場合、PCECPリクエストループのリスクがある場合があります。PCECP要求メッセージループを検出および修正するために、メカニズムを定義する必要があります。これは、たとえば、リクエストメッセージの録音に依存して、トラバースされたPCESのセットに依存する場合があります。
Also, the returned path in a response message MUST be loop free.
また、応答メッセージの返されたパスはループフリーでなければなりません。
The inter-area application implies some new manageability requirements in addition to those already listed in [RFC4657]. The PCECP PCC and PCE MIB modules MUST allow recording the proportion of inter-area requests and the success rate of inter-area requests. The PCECP PCC MIB module MUST also allow recording the performances of a PCE chain (minimum, maximum, and average response times), in case of multiple-PCE inter-area path computation.
エリア間アプリケーションは、[RFC4657]にすでにリストされているものに加えて、いくつかの新しい管理可能性要件を意味します。PCECP PCCおよびPCE MIBモジュールは、エリア間要求の割合とエリア間要求の成功率を記録する必要があります。PCECP PCC MIBモジュールは、多重PCEエリア間パス計算の場合、PCEチェーンのパフォーマンス（最小、最大、および平均応答時間）を記録することもできます。
It is really important, for diagnostic and troubleshooting reasons, to monitor the availability and performances of each PCE of a PCE chain used for inter-area path computation. Particularly, it is really important to identify the PCE(s) responsible for a delayed reply.
診断およびトラブルシューティングの理由で、エリア間パス計算に使用されるPCEチェーンの各PCEの可用性とパフォーマンスを監視することが非常に重要です。特に、返信の遅延の原因となるPCEを特定することが本当に重要です。
Hence, a mechanism MUST be defined to monitor the performances of a PCE chain. It MUST allow determining the availability of each PCE of the chain as well as its minimum, maximum, and average response times.
したがって、PCEチェーンのパフォーマンスを監視するために、メカニズムを定義する必要があります。チェーンの各PCEの可用性と、最小、最大、および平均応答時間を決定できるようにする必要があります。
IGP areas are administrated by the same entity. Hence, the inter-area application does not imply a new trust model or new security issues beyond those already defined in [RFC4657].
IGPエリアは同じエンティティによって管理されます。したがって、エリア間アプリケーションは、[RFC 4657]ですでに定義されているものを超えた新しい信頼モデルまたは新しいセキュリティ問題を意味するものではありません。
We would also like to thank Adrian Farrel, Jean-Philippe Vasseur, Bruno Decraene, Yannick Le Louedec, Dimitri Papadimitriou, and Lou Berger for their useful comments and suggestions. Thanks also to Ross Callon, Catherine Meadow, and Dan Romascanu for their review during the final stages of publication.
また、エイドリアン・ファレル、ジャン・フィリップ・ヴァスザー、ブルーノ・デクレアン、ヤニック・ル・ルーデック、ディミトリ・パパジミトリウ、ルー・バーガーの有用なコメントと提案に感謝します。出版の最終段階でのレビューをしてくれたロス・カロン、キャサリン・メドウ、ダン・ロマスカヌにも感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle, Ed., "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105] Le Roux、J.-L.、ed。、vasseur、J.-P.、ed。、およびJ. Boyle、ed。、「A-A-Area MPLS Traffic Engineeringの要件」、RFC 4105、2005年6月。
[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., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657] Ash、J.、ed。、およびJ. Le Roux、ed。、「Path Computation Element（PCE）通信プロトコルジェネリック要件」、RFC 4657、2006年9月。
[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
[RFC4674] Le Roux、J.、ed。、「Path Computation Element（PCE）Discoveryの要件」、RFC 4674、2006年10月。
[PD-COMP] Vasseur, J.P., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-domain path computation method for computing Inter-domain Traffic Engineering (TE) Label Switched Path (LSP)", Work in Progress, April 2007.
[PD-Comp] Vasseur、J.P.、ed。、Ayyangar、A.、ed。、およびR. Zhang、「ドメイン間トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）を計算するためのドメインごとのパス計算方法」」、作業中の2007年4月。
[PCE-POL-FMWK] Bryskin, I., Papadimitriou, D., Berger L., and J. Ash, "Policy-Enabled Path Computation Framework", Work in Progress, March 2007.
[PCE-POL-FMWK] Bryskin、I.、Papadimitriou、D.、Berger L.、およびJ. Ash、「ポリシー対応パス計算フレームワーク」、2007年3月、進行中の作業。
[RFC3785] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP 87, RFC 3785, May 2004.
[RFC3785] Le Faucheur、F.、Uppili、R.、Vedrenne、A.、Merckx、P。、およびT. Telkamp、「Interior Gateway Protocol（IGP）メトリックの使用としての2番目のMPLSトラフィックエンジニアリング（TE）メトリック」、BCP 87、RFC 3785、2004年5月。
Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1-(732)-420-4578 EMail: gash5107@yahoo.com
ジェリーアッシュAT＆TルームMT D5-2A01 200ローレルアベニューミドルタウン、ニュージャージー州07748、米国電話：1-（732）-420-4578メール：gash5107@yahoo.com
Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 EMail: nabil.n.bitar@verizon.com Dean Cheng Cisco Systems Inc. 3700 Cisco Way San Jose, CA 95134 USA Phone: +1 408 527 0677 EMail: dcheng@cisco.com
Nabil Bitar Verizon 40 Sylvan Road Waltham、MA 02145メール：nabil.n.n.bitar@verizon.com Dean Cheng Cisco Systems Inc. 3700 Cisco Way San Jose、CA 95134 USA電話：
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Phone: +81-3-6678-3103 EMail: ke-kumaki@kddi.com
Kenji Kumaki Kddi Corporation Garden Air Tower Iidabashi、Chiyoda-Ku、Tokyo 102-8460、日本電話：81-3-6678-3103メール：ke-kumaki@kddi.com
Eiji Oki NTT Midori-cho 3-9-11 Musashino-shi, Tokyo 180-8585, JAPAN EMail: oki.eiji@lab.ntt.co.jp
eiji oki ntt midori-cho 3-9-11 Musashino-shi、東京180-8585、日本メール：oki.eiji@lab.ntt.co.jp
Raymond Zhang BT 2160 E. Grand Ave. El Segundo, CA 90245 USA EMail: raymond.zhang@bt.com
Raymond Zhang BT 2160 E. Grand Ave. El Segundo、CA 90245 USAメール：raymond.zhang@bt.com
Renhai Zhang Huawei Technologies No. 3 Xinxi Road, Shangdi, Haidian District, Beijing City, P. R. China EMail: zhangrenhai@huawei.com
Renhai Zhang Huawei Technologies No. 3 Xinxi Road、Shangdi、Haidian District、Beijing City、P。R。China Email：zhangrenhai@huawei.com
Editor's Address
編集者のアドレス
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE EMail: jeanlouis.leroux@orange-ftgroup.com
Jean-Louis Le Roux France Telecom 2、Avenue Pierre-Marzin 22307 Lannion Cedex Franceメール：jeanlouis.leroux@orange-ftgroup.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
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エディター機能の資金は現在、インターネット協会によって提供されています。