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
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）IETFトラスト（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）は、少なくとも二つのIGP領域を介して遷移するLSPです。マルチエリア・ネットワークでは、トポロジの可視性は、所与の領域に局所ままであり、ヘッドエンドラベルスイッチングルータ（LSR）は、エリア間の最短パス制約を計算することができません。経路計算エレメント（PCE）ベースのアーキテクチャの一の主要なアプリケーションは、インターエリアTE-LSPパスの計算です。 PCE通信プロトコル（PCECP）はのPCEに経路計算クライアント（のPCC）から計算要求を通信すること、および応答で計算パスを返すために使用されます。この文書では、エリア間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は、エリア間TE-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]の主要なアプリケーションの一つです。最適なエリア間経路の計算は、一の以上の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は、PCEとPCCに経路計算応答を送信するPCEに経路計算要求を送信することを可能にするPCE通信プロトコル（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またはIS-ISでL1 / L2ルータでABR）に取り付けられているルータ。
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：経路計算クライアント、PCEによって実行される経路計算を要求する任意のアプリケーション。
PCECP: PCE Communication Protocol, a protocol for communication between PCCs and PCEs, and between PCEs.
PCECP：PCE通信プロトコルのPCCとの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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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領域（S）の境界を横切るエンド・ツー・エンドの経路を計算することができません。
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が制約パス以下に設定されることを可能にするが、二つの主要な制約に直面しています。
- 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の計算：経路計算は、部分トポロジーの可視性を持つ複数のPCE、上に分散されています。彼らは、可視のそのドメイン内経路セグメントを計算し、エンドツーエンド最適経路制約に到達するように互いに協力します。このようなコラボレーションは、相互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]に記載されている一般的な要件に加えて、PCECPに特定の機能要件を意味PCEベースのアプローチの使用は、エリア間経路計算を実行することに留意されたいです。これらの特定の要件は、次のセクションで説明されています。
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]に記載されている要件を補完し、エリア間（G）MPLS-TEパス計算に固有のPCECPの追加要件のセットを示しています。
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.
緩いパスは、少なくとも一つのルーズホップ、ゼロ、一つ以上の厳密ホップの集合として定義されている間厳密な明示的なパスは、厳密ホップの集合として定義されます。エリア間の経路は、厳密に明示的または緩んであってもよい（例えば、の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記録の要求をサポートしなければなりません、そして、応答メッセージは、計算に参加した一の以上の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（それは可視性を有する、すなわち、領域（S））のエリアID（複数可）PCE発見プロトコルによって（[RFC4674]を参照）、またはいずれかによって達成することができる/知られているとき、これは有用であろう他の意味。
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は、ソース/デスティネーション領域のいずれかの可視性を持っていない可能性があり、したがって、送信元/送信先の領域を決定することができないかもしれません。そのような状況では、その要求メッセージの送信元と宛先エリアIDを示すために、PCCのために有用であろう。
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つまたは計算される経路によって回避されなければならない複数の領域（単数または複数）を示すためにのためにも有用であり得る（例えば、同じABR（S）に接続された2つのスタブエリア内のLSRの間の経路を求める要求、これはバックボーンエリアを越えてはいけません）。従って、要求メッセージは、明示的経路に含まれなければならない一つ以上の領域（単数または複数）のセット、及び明示的経路から除外されなければならない一つ以上の領域（単数または複数）のセットを示す可能にしなければなりません。
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ダイバーシティ）のセットの多様性のレベルを示す可能にしなければなりませんエリアパスセグメント）。
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-POL-FMWK] PCEのワーキンググループで別の作業項目として行われています。
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要求メッセージがループします。これは、横断のPCEのセットで、要求メッセージに、記録に、例えば、依存することができます。
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.
我々はまた、彼らの役に立つコメントと提案のためのエードリアンファレル、ジャン=フィリップVasseur、ブルーノDecraene、ヤニック・ルLouedec、ディミトリPapadimitriou、およびルー・バーガーに感謝したいと思います。出版物の最終段階で彼らのレビューのためにも、ロスCallon、キャサリン草原、そしてダンRomascanuに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ル・ルー、J.-L.、エド。、Vasseur、J.-P.、エド。、およびJ.ボイル、エド。、 "エリア間MPLSトラフィックエンジニアリングのための要件"、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]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（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]アッシュ、J.、エド。、およびJ.ル・ルー、エド。、 "パス計算要素（PCE）通信プロトコルジェネリック要件"、RFC 4657、2006年9月。
[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
[RFC4674]ル・ルー、J.、エド。、RFC 4674、2006年10月 "経路計算エレメント（PCE）の発見のための要件"。
[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、JP、編、Ayyangar、A.編、及びR.張、 "インタードメイントラフィックエンジニアリング（TE）ラベルスイッチパス（LSP）を計算するためのA単位のドメイン経路計算方法" 、進捗状況、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.、バーガーL.、およびJ.アッシュ、 "政策対応の経路計算フレームワーク"、進歩、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]ルFaucheur、F.、Uppili、R.、Vedrenne、A.、メルクス、P.、およびT. Telkamp、 "第二のMPLSトラフィックエンジニアリング（TE）メトリックとしてインテリアゲートウェイプロトコル（IGP）メトリックの使用" 、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ローレルアベニューミドルタウン、NJ 07748、USA電話：+ 1-（732）-420-4578 Eメール：gash5107@yahoo.com
Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 EMail: nabil.n.bitar@verizon.com
ナビル・ビタールベライゾン40シルバンロードウォルサム、MA 02145 Eメール：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
ディーン・チェンシスコシステムズ株式会社3700シスコウェイサンノゼ、CA 95134 USA電話：+1 408 527 0677 Eメール：dcheng@cisco.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Phone: +81-3-6678-3103 EMail: ke-kumaki@kddi.com
健二熊木KDDI株式会社ガーデンエアタワー飯田橋、東京都千代田区102-8460、JAPAN電話：+ 81-3-6678-3103 Eメール：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
えいじ おき んっｔ みどりーちょ ３ー９ー１１ むさしのーし、 ときょ １８０ー８５８５、 じゃぱん えまいｌ： おき。えいじ＠ぁｂ。んっｔ。こ。ｊｐ
Raymond Zhang BT 2160 E. Grand Ave. El Segundo, CA 90245 USA EMail: raymond.zhang@bt.com
レイモンド・チャンBT 2160 E.グランドアベニューエル・セグンド、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
N張HU再海は技術、H低ポイント地区、北京市、P. R.中国は電子メールへのシャン道路の無3 X、:. Huawei社ZhangRen @に基づいており、さらに.COM
Editor's Address
編集者の住所
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE EMail: jeanlouis.leroux@orange-ftgroup.com
ジャン=ルイ・ルーフランステレコム2、大通りピエールMarzin 22307ラニオンCedexのFRANCE Eメール：jeanlouis.leroux@orange-ftgroup.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。