RFC4927 日本語訳

Network Working Group                                 J.-L. Le Roux, Ed.
Request for Comments: 4927                                France Telecom
Category: Informational                                        June 2007

ワーキンググループJ.-Lをネットワークでつないでください。 エドル・ルー、コメントを求める要求: 4927年のフランス電子通信カテゴリ: 情報の2007年6月

    Path Computation Element Communication Protocol (PCECP) Specific
    Requirements for Inter-Area MPLS and GMPLS Traffic Engineering

相互領域MPLSとGMPLS交通工学のための経路計算要素通信プロトコル(PCECP)決められた一定の要求

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).

IETFが信じる著作権(C)(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.

スケーラビリティ目的のために、ネットワークは複数のInteriorゲートウェイプロトコル(IGP)部門を包括するかもしれません。 相互領域Traffic Engineered Label Switched Path(TE-LSP)は少なくとも2つのIGP領域を通って通過するLSPです。 マルチ領域ネットワークでは、トポロジー目に見えることは与えられた領域に地方のままで残っています、そして、ギヤエンドLabel Switching Router(LSR)は相互領域の最も短い強制的な経路を計算できません。 Path Computation Elementの(PCE)ベースの構造の1つの主要な応用は相互領域TE-LSP経路の計算です。 PCE Communicationプロトコル(PCECP)はPath Computation Clients(PCCs)からPCEsまでの計算要求を伝えるのに使用されました、そして、戻るのは応答における経路を計算しました。 このドキュメントは相互領域TE-LSP経路計算のサポートのための詳細なPCECP-決められた一定の要求をリストアップします。 それはPCE Communicationプロトコルのための一般的な要件の補足となります。

Le Roux                      Informational                      [Page 1]

RFC 4927         PCECP Requirements for MPLS and GMPLS         June 2007

MPLSのためのル・ルー情報[1ページ]のRFC4927PCECP RequirementsとGMPLS2007年6月

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

1. 序論…2 2. 用語…3 2.1. このドキュメントで中古のコンベンション…4 3. PCEベースの相互領域経路計算に関する動機…4 4. PCECPに関する詳細な相互領域決められた一定の要求…5 4.1. 領域交差点のコントロールと録音…5 4.2. 領域録音…6 4.3. 厳しい明白な経路とゆるい経路…6 4.4. PCEは複数のPCE計算における実施と録音を記載します…6 4.5. 要求での領域IDの包含…7 4.6. 領域包含/除外…7 4.7. 相互領域のさまざまの経路計算…7 4.8. 相互領域方針…8 4.9. 回避を輪にしてください…8 5. 管理可能性問題…9 6. セキュリティ問題…9 7. 承認…9 8. 参照…9 8.1. 標準の参照…9 8.2. 有益な参照…10 9. 貢献者…10

1.  Introduction

1. 序論

   [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-LSPsをセットアップするための1セットの動機と要件をリストアップします。 これらのLSPsは相互領域TE-LSPsと呼ばれます。 これらの要件は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つです。 最適の相互領域経路の計算は、1PCEsのサービスを利用することで達成されるかもしれません。

   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領域をカバーするPCEsの間の協力に依存するかもしれません、そして、PCEsのフルセットはすべての領域をカバーしています。

Le Roux                      Informational                      [Page 2]

RFC 4927         PCECP Requirements for MPLS and GMPLS         June 2007

MPLSのためのル・ルー情報[2ページ]のRFC4927PCECP RequirementsとGMPLS2007年6月

   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.

PCE Communicationプロトコル(PCECP)のための一般的な要件は[RFC4657]に詳しく説明されます。(PCCは、経路計算応答をPCCに送るためにプロトコルで経路計算要求をPCEとPCEに送ることができます)。 PCEベースのアプローチの相互領域経路計算の使用はPCE Communicationプロトコルに関する決められた一定の要求を含意します、[RFC4657]に既にリストアップされた一般的な要件に加えて。 このドキュメントは、相互領域経路計算に特定の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]でそのようなメカニズムのための詳細な要件について議論します。

2.  Terminology

2. 用語

   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領域、-、レベル。

   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 Area Border Router、1つ以上のIGP領域に付けられているルータ、(OSPFのABRか中のL1/L2ルータ、-、)

   Inter-Area TE-LSP: TE-LSP that traverses more than one IGP area.

相互領域Te-LSP: 1つ以上のIGP領域を横断するTE-LSP。

   CSPF: Constrained Shortest Path First.

CSPF: 最短パス強制的な1番目。

   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: 経路Computation Client、PCEによって実行されるよう経路計算に要求するどんなアプリケーション。

   PCECP: PCE Communication Protocol, a protocol for communication
   between PCCs and PCEs, and between PCEs.

PCECP: PCE Communicationプロトコル、PCCsとPCEsと、PCEsとのコミュニケーションのためのプロトコル。

Le Roux                      Informational                      [Page 3]

RFC 4927         PCECP Requirements for MPLS and GMPLS         June 2007

MPLSのためのル・ルー情報[3ページ]のRFC4927PCECP RequirementsとGMPLS2007年6月

   ERO: Resource Reservation Protocol (RSVP)-TE Explicit Route Object.
   It encodes the explicit path followed by a TE-LSP.

ERO: 資源予約プロトコル(RSVP)Te明白なルート物。 それはTE-LSPによって続かれた明白な経路をコード化します。

2.1.  Conventions Used in This Document

2.1. 本書では使用されるコンベンション

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

3.  Motivations for PCE-Based Inter-Area Path Computation

3. PCEベースの相互領域経路計算に関する動機

   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経路を計算する現在の解決策は1ドメインあたり1つの経路計算[PD-COMP]に依存します。 ERO拡大が各ABRにある状態で、それはゆるいホップルーティングに基づいています。 これは、強制的な経路に続いて、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.

- これは、いくつかのcrankbackシグナリングメッセージに通じて、したがって、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]は相互領域経路計算によく合っています。 それは、限られたトポロジー目に見えることから生じる経路計算限界が、より多くのトポロジー目に見えることで経路計算実体を導入するか、または各領域の経路計算実体の間に協力を許容することによって克服されるのを許容します。

Le Roux                      Informational                      [Page 4]

RFC 4927         PCECP Requirements for MPLS and GMPLS         June 2007

MPLSのためのル・ルー情報[4ページ]のRFC4927PCECP RequirementsとGMPLS2007年6月

   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に広げられます。(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.

PCECP[RFC4657]にリストアップされた一般的な要件に加えて相互領域経路計算を実行するPCEベースのアプローチの使用が特定の機能条件書を含意することに注意してください。 次のセクションでこれらの決められた一定の要求について議論します。

4.  Detailed Inter-Area Specific Requirements on PCECP

4. 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.

このセクションはPCECPのための補数要件が[RFC4657]に記載して、相互領域(G)MPLS-TE経路計算に特定であるという1セットの追加要件をリストアップします。

4.1.  Control and Recording of Area Crossing

4.1. 領域交差点のコントロールと録音

   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.

また、ソースと目的地が同じ領域にあるとき、返された経路が相互領域経路であるかどうかを知るのも役に立つかもしれません。 したがって、応答メッセージは、計算された経路が領域に交差しているかどうかを示すのを許容しなければなりません。

Le Roux                      Informational                      [Page 5]

RFC 4927         PCECP Requirements for MPLS and GMPLS         June 2007

MPLSのためのル・ルー情報[5ページ]のRFC4927PCECP RequirementsとGMPLS2007年6月

4.2.  Area Recording

4.2. 領域録音

   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が相互領域経路と対応する経路セグメントによって交差される領域のセットを知るのは、役に立つかもしれません。 したがって、応答メッセージで、交差している領域を特定しなければなりません。 また、応答メッセージで、経路のどの断片がどの領域に属すかを言うのが可能であるように、返された経路を区分して、各セグメントをマークしなければなりません。

4.3.  Strict Explicit Path and Loose Path

4.3. 厳しい明白な経路とゆるい経路

   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.

Strict Explicit Pathは1セットの厳しいホップと定義されます、Loose Pathが1セットの少なくとも1つのゆるいホップとゼロと定義されますが、1つ以上の厳しいホップ。 相互領域経路は、厳密に明白であるか、またはゆるいかもしれません(例えば、ゆるいホップとしてのABRsのリスト)。 それは、Strict Explicit経路が必要であるかどうかをPCEに示すために役に立つかもしれません。 したがって、PCECP要求メッセージは、Strict Explicit Pathが必要である、または望まれているかどうかを示すのを許容しなければなりません。

4.4.  PCE List Enforcement and Recording in Multiple-PCE Computation

4.4. 複数のPCE計算におけるPCEリスト実施と録音

   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は使用されるためにPCEsの都合のよいリストを示したがっているかもしれません、1領域あたり1つ。 各領域では、別の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要求メッセージは1領域あたりの都合のよいPCEsのリストの包含を支持しなければなりません。 これが、1つの領域のPCCが他の領域にPCEsに関する知識を持っているのを必要とすることに注意してください。 エリアの境界の向こう側に発見を許して、これは構成、または、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.

また、事実上、計算に参加したPCEsのリストを知るのも役に立つでしょう。 したがって、要求メッセージはPCE録音を求める要求を支持しなければなりません、そして、応答メッセージは計算に参加した1PCEsのセットの録音を支持しなければなりません。

   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によって計算された経路セグメントを知るのも役に立つかもしれません。 したがって、要求メッセージSHOULDはPCEによって計算された経路セグメントの識別のために要求を認めます、そして、応答メッセージSHOULDは各PCEによって計算された経路セグメントを特定するのを許容します。

Le Roux                      Informational                      [Page 6]

RFC 4927         PCECP Requirements for MPLS and GMPLS         June 2007

MPLSのためのル・ルー情報[6ページ]のRFC4927PCECP RequirementsとGMPLS2007年6月

4.5.  Inclusion of Area IDs in Request

4.5. 要求での領域IDの包含

   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が/(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はソース/目的地の地域の少しの目に見えることも持たないで、したがって、ソース/目的地の領域を決定できないかもしれません。 そのような状況で、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が構成を通してこの情報について学習できたことに注意してください。

4.6.  Area Inclusion/Exclusion

4.6. 領域包含/除外

   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(s)に接続したよう2スタッブのLSRsの間の経路に要求してください)。 したがって、要求メッセージで、経路に明らかに含まなければならない1つ以上の領域、および経路から明らかに除かなければならない1つ以上の領域の1セットの1セットを示さなければなりません。

4.7.  Inter-Area Diverse Path Computation

4.7. 相互領域のさまざまの経路計算

   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)

- 1領域あたりの多様性(イントラ領域経路セグメントはリンク、ノードであるか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つの経路も領域の中でノードでばらばらになるかもしれませんが、シェアABRs(その場合では、領域の中の経路セグメントはノードでばらばらになりますが、終わりから端への経路はノードでない)がばらばらになりますように。

Le Roux                      Informational                      [Page 7]

RFC 4927         PCECP Requirements for MPLS and GMPLS         June 2007

MPLSのためのル・ルー情報[7ページ]のRFC4927PCECP RequirementsとGMPLS2007年6月

   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.

要求メッセージで、同じノード組、または、異なったノード組の間の1セットの相互領域のさまざまの経路の計算を要求しなければなりません。 それで、必要なレベルの1セットの相互領域経路(リンク、ノード、およびSRLGの多様性)の多様性を示さなければなりません、必要なレベルの1セットの相互領域経路の地域制に関するイントラ領域区分(リンク、ノード、および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の多様性)の上に1セットの計算された相互領域ゆるい経路の多様性(リンク、ノード、およびSRLGの多様性)のレベルを示さなければなりません。

   Note that, in order to ensure SRLG consistency, SRLG identifiers
   within the IGP domain should be assigned and allocated by the same
   entity.

IGPドメインの中のSRLG識別子が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]に詳しく説明されるように1セットのさまざまの経路のcumulated費用を最小にするのなどように。

4.8.  Inter-Area Policies

4.8. 相互領域方針

   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のアドレスの包含を考慮しなければなりません。 これは複数のPCE計算で役に立つかもしれません、PCECP同輩に基づいているだけではありませんが、由来しているPCCにまた基づく方針を適用するために。

   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]で引き受けられていることに注意してください。

4.9.  Loop Avoidance

4.9. 輪の回避

   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.

また、応答メッセージにおける返された経路には、輪があってはいけません。

Le Roux                      Informational                      [Page 8]

RFC 4927         PCECP Requirements for MPLS and GMPLS         June 2007

MPLSのためのル・ルー情報[8ページ]のRFC4927PCECP RequirementsとGMPLS2007年6月

5.  Manageability Considerations

5. 管理可能性問題

   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(s)を特定するのは本当に重要です。

   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の有用性を決定しなければなりません。

6.  Security Considerations

6. セキュリティ問題

   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領域は同じ実体によって管理されます。 したがって、相互領域アプリケーションは[RFC4657]で既に定義されたものを超えて新しい信用モデルか新しい安全保障問題を含意しません。

7.  Acknowledgments

7. 承認

   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、ヤニックLe Louedec、ディミトリPapadimitriou、およびルウ・バーガーに感謝申し上げます。 また、彼らのレビューを公表の最終段階の間、ロスCallon、キャサリンMeadow、およびダンRomascanuをありがとうございます。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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のための要件は工学を取引します」、RFC4105、2005年6月。

Le Roux                      Informational                      [Page 9]

RFC 4927         PCECP Requirements for MPLS and GMPLS         June 2007

MPLSのためのル・ルー情報[9ページ]のRFC4927PCECP RequirementsとGMPLS2007年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)ベースの構造」、RFC4655、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)通信プロトコルジェネリック要件」、RFC4657(2006年9月)

8.2.  Informative References

8.2. 有益な参照

   [RFC4674]      Le Roux, J., Ed., "Requirements for Path Computation
                  Element (PCE) Discovery", RFC 4674, October 2006.

[RFC4674] ル・ルー、J.、エド、「経路計算要素(PCE)発見のための要件」、RFC4674、10月2006日

   [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.

Progress(2007年4月)の[PD-COMP]Vasseur、J.P.(エド)とAyyangar、A.(エド)とR.チャン、「Inter-ドメインTraffic Engineering(TE)ラベルSwitched Path(LSP)を計算するためのPer-ドメイン経路計算方法」Work。

   [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] I.、Papadimitriou、D.、バーガーL.、およびJ.灰、「方針で可能にされた経路計算枠組み」というBryskinは進歩、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.、ベドレン、A.、メルクス、P.、およびT.Telkamp、「a第2MPLS Traffic Engineering(TE)メートル法としてのメートル法のInteriorゲートウェイプロトコル(IGP)の使用」、BCP87、RFC3785(2004年5月)。

9.  Contributors

9. 貢献者

   Jerry Ash
   AT&T
   Room MT D5-2A01
   200 Laurel Avenue
   Middletown, NJ 07748, USA
   Phone: +1-(732)-420-4578
   EMail: gash5107@yahoo.com

MT D5-2A01 200ローレルアベニューミドルタウン、ニュージャージー 07748、米国が電話をするジェリー灰のAT&T部屋: +1(732)420-4578メール: gash5107@yahoo.com

   Nabil Bitar
   Verizon
   40 Sylvan Road
   Waltham, MA 02145
   EMail: nabil.n.bitar@verizon.com

ウォルサム、Nabil Bitarベライゾン40の森のRoad MA 02145はメールされます: nabil.n.bitar@verizon.com

Le Roux                      Informational                     [Page 10]

RFC 4927         PCECP Requirements for MPLS and GMPLS         June 2007

MPLSのためのル・ルー情報[10ページ]のRFC4927PCECP RequirementsとGMPLS2007年6月

   Dean Cheng
   Cisco Systems Inc.
   3700 Cisco Way
   San Jose, CA 95134 USA
   Phone: +1 408 527 0677
   EMail: dcheng@cisco.com

カリフォルニア95134サンノゼ(米国)が電話をするディーンチェンシスコシステムズ株式会社3700コクチマス道: +1 0677年の408 527メール: 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

Kenji Kumaki KDDI社の庭の空気Tower飯田橋、千代田区、東京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

美土里町の3 9-11テロのEiji Oki NTT武蔵野市、東京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

レイモンドチャンBT2160のE.の壮大なAve。 カリフォルニア90245エルセガンド(米国)はメールされます: 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チャンHuawei Technologies No.3Xinxi道路、Shangdi、Haidian地区、北京市、P.R.中国はメールされます: 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

ジャン・ルイル・ルーフランステレコム2、大通りピアー-Marzin22307Lannion CedexフランスEMail: jeanlouis.leroux@orange-ftgroup.com

Le Roux                      Informational                     [Page 11]

RFC 4927         PCECP Requirements for MPLS and GMPLS         June 2007

MPLSのためのル・ルー情報[11ページ]のRFC4927PCECP RequirementsとGMPLS2007年6月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Le Roux                      Informational                     [Page 12]

ル・ルーInformationalです。[12ページ]