RFC5376 日本語訳
5376 Inter-AS Requirements for the Path Computation ElementCommunication Protocol (PCECP). N. Bitar, R. Zhang, K. Kumaki. November 2008. (Format: TXT=33114 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group N. Bitar
Request for Comments: 5376 Verizon
Category: Informational R. Zhang
BT
K. Kumaki
KDDI R&D Labs
November 2008
Bitarがコメントのために要求するワーキンググループN.をネットワークでつないでください: 5376年のベライゾンカテゴリ: 情報のR.のBT K.Kumaki KDDI研究開発研究室チャン2008年11月
Inter-AS Requirements for the
Path Computation Element Communication Protocol (PCECP)
相互、経路計算要素通信プロトコルのための要件(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) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright(c)2008IETF Trustと人々はドキュメントとして作者を特定しました。 All rights reserved。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
事実上、このドキュメントはこのドキュメントの公表の日付にIETF Documents( http://trustee.ietf.org/license-info )へのBCP78とIETF TrustのLegal Provisions Relatingを受けることがあります。 このドキュメントに関して権利と制限について説明するとき、慎重にこれらのドキュメントを再検討してください。
Abstract
要約
Multiprotocol Label Switching Traffic Engineered (MPLS TE) Label Switched Paths (LSPs) may be established wholly within an Autonomous System (AS) or may cross AS boundaries.
Multiprotocol Label Switching Traffic Engineered(MPLS TE)ラベルSwitched Paths(LSPs)はAutonomous System(AS)の中で完全に確立されるか、またはAS境界に交差するかもしれません。
The Path Computation Element (PCE) is a component that is capable of computing constrained paths for (G)MPLS TE LSPs. The PCE Communication Protocol (PCECP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, as well as between PCEs. The PCECP is used to request constrained paths and to supply computed paths in response. Generic requirements for the PCECP are set out in "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657. This document extends those requirements to cover the use of PCECP in support of inter-AS MPLS TE.
Path Computation Element(PCE)は(G) MPLS TE LSPsのために強制的な経路を計算できるコンポーネントです。 PCE Communicationプロトコル(PCECP)は、Path Computation Clients(PCCs)とPCEsと、PCEsとのコミュニケーションを許容するために定義されます。 PCECPは、強制的な経路を要求して、応答における計算された経路を供給するのに使用されます。 RFC4657、PCECPのための一般的な要件は「経路計算要素(PCE)通信プロトコルジェネリック要件」を始められます。 このドキュメントは相互AS MPLS TEを支持してPCECPの使用をカバーするというそれらの要件を広げています。
Bitar, et al. Informational [Page 1] RFC 5376 Inter-AS Requirements for PCECP November 2008
Bitar、他 情報[1ページ]のRFC5376、相互、PCECP2008年11月のための要件
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Reference Model .................................................4
3.1. Scope of Deployment Model ..................................5
4. Detailed PCECP Requirements for Inter-AS G(MPLS) TE Path
Computation .....................................................6
4.1. PCE Communication Protocol Requirements ....................6
4.1.1. Requirements for Path Computation Requests ..........6
4.1.2. Requirements for Path Computation Responses .........7
4.2. Scalability and Performance Considerations .................8
4.3. Management Considerations ..................................8
4.4. Confidentiality ............................................9
4.5. Policy Controls Affecting Inter-AS PCECP ...................9
4.5.1. Inter-AS PCE Peering Policy Controls ...............10
4.5.2. Inter-AS PCE Re-Interpretation Policies ............10
5. Security Considerations ........................................10
5.1. Use and Distribution of Keys ..............................11
5.2. Application of Policy .....................................11
5.3. Confidentiality ...........................................12
5.4. Falsification of Information ..............................12
6. Acknowledgments ................................................12
7. Normative References ...........................................13
8. Informative References .........................................13
1. 序論…3 2. 用語…3 3. 参照モデル…4 3.1. 展開モデルの範囲…5 4. PCECP要件を詳しく述べる、相互、G(MPLS)Te経路計算…6 4.1. PCE通信プロトコル要件…6 4.1.1. 経路計算要求のための要件…6 4.1.2. 経路計算応答のための要件…7 4.2. スケーラビリティとパフォーマンス問題…8 4.3. 管理問題…8 4.4. 秘密性…9 4.5. 方針が影響を制御する、相互、PCECP…9 4.5.1. 相互、PCEじっと見る方針は制御されます…10 4.5.2. 相互、PCE再解釈方針…10 5. セキュリティ問題…10 5.1. キーの使用と分配…11 5.2. 方針の適用…11 5.3. 秘密性…12 5.4. 情報の改竄…12 6. 承認…12 7. 標準の参照…13 8. 有益な参照…13
Bitar, et al. Informational [Page 2] RFC 5376 Inter-AS Requirements for PCECP November 2008
Bitar、他 情報[2ページ]のRFC5376、相互、PCECP2008年11月のための要件
1. Introduction
1. 序論
[RFC4216] defines the scenarios motivating the deployment of inter-AS Multiprotocol Label Switching Traffic Engineering (MPLS TE) and specifies the requirements for inter-AS MPLS TE when the ASes are under the administration of one Service Provider (SP) or the administration of different SPs.
[RFC4216]は、相互AS Multiprotocol Label Switching Traffic Engineering(MPLS TE)の展開を動機づけるシナリオを定義して、ASesが1Service Provider(SP)の管理か異なったSPsの管理の下にあるとき、相互AS MPLS TEのための要件を指定します。
Three signaling options are defined for setting up an inter-AS TE Label Switched Path (LSP):
3つのシグナリングオプションが相互AS TE Label Switched Path(LSP)をセットアップするために定義されます:
1) contiguous TE LSP as documented in [RFC5151];
2) stitched inter-AS TE LSP discussed in [RFC5150];
3) nested TE LSP as in [RFC4206].
1) [RFC5151]に記録される隣接のTE LSP。 2)は[RFC5150]で議論した相互AS TE LSPをステッチしました。 3)は[RFC4206]のようにTE LSPを入れ子にしました。
[RFC5152] defines mechanisms for the computation of inter-domain TE LSPs using network elements along the signaling paths to compute per-domain constrained path segments. The mechanisms in [RFC5152] do not guarantee an optimum constrained path across multiple ASes where an optimum path for a TE LSP is one that has the smallest cost, according to a normalized TE metric (based upon a TE metric or Interior Gateway Protocol (IGP) metric adopted in each transit AS) among all possible paths that satisfy the LSP TE constraints.
[RFC5152]は、相互ドメインTE LSPsの計算のために1ドメインあたりの強制的な経路セグメントを計算するのにシグナリング経路に沿ってネットワーク要素を使用することでメカニズムを定義します。 [RFC5152]のメカニズムはLSP TE規制を満たすすべて中のメートル法(各トランジットASで採用されて、メートル法かInteriorゲートウェイプロトコル(IGP)をTEにメートル法で基礎づける)の可能な経路を複数のASesの向こう側のTE LSPのための最適な経路が正常にされたTEによると、最も少ない費用があるものである最適な強制的な経路に保証しません。
The Path Computation Element (PCE) [RFC4655] is a component that is capable of computing paths for MPLS TE and Generalized Multiprotocol Label Switching Protocol ((G)MPLS TE) LSPs. The requirements for a PCE have come from SP demands to compute optimum constrained paths across multiple areas and/or domains, and to be able to separate the path computation elements from the forwarding elements.
Path Computation Element(PCE)[RFC4655]はMPLS TEとGeneralized Multiprotocol Label Switchingプロトコル((G)MPLS TE) LSPsのために経路を計算できるコンポーネントです。 PCEのための要件は複数の領域、そして/または、ドメインの向こう側に最適な強制的な経路を計算して、推進要素と経路計算要素を切り離すことができるというSP要求から来ました。
The PCE Communication Protocol (PCECP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, and between PCEs. The PCECP is used to request (G)MPLS TE paths and to supply computed paths in response. Generic requirements for the PCECP are discussed in [RFC4657]. This document provides a set of PCECP requirements that are specific to inter-AS (G)MPLS TE path computation.
PCE Communicationプロトコル(PCECP)は、Path Computation Clients(PCCs)とPCEsと、PCEsとのコミュニケーションを許容するために定義されます。 PCECPは、(G) MPLS TE経路を要求して、応答における計算された経路を供給するのに使用されます。 [RFC4657]でPCECPのための一般的な要件について議論します。 このドキュメントは1セットの相互AS(G)MPLS TE経路計算に特定のPCECP要件を提供します。
2. Terminology
2. 用語
This document adopts the definitions and acronyms defined in Section 3 of [RFC4216] and Section 2 of [RFC4655]. In addition, we use the following terminology:
このドキュメントは[RFC4216]のセクション3と[RFC4655]のセクション2で定義された定義と頭文字語を採用します。 さらに、私たちは以下の用語を使用します:
ASBR: Autonomous System Border Router (see section 3 of RFC 4216)
ASBR: 自律システム境界ルータ(RFC4216のセクション3を見ます)
PCECP: PCE Communication Protocol
PCECP: PCE通信プロトコル
Bitar, et al. Informational [Page 3] RFC 5376 Inter-AS Requirements for PCECP November 2008
Bitar、他 情報[3ページ]のRFC5376、相互、PCECP2008年11月のための要件
(G)MPLS TE: MPLS or Generalized MPLS Traffic Engineering
(G) MPLS Te: MPLSか一般化されたMPLS交通工学
Inter-AS (G)MPLS TE path: An MPLS TE or Generalized MPLS (GMPLS) path
that traverses two or more ASes.
相互AS(G)MPLS TE経路: 2ASesを横断するMPLS TEかGeneralized MPLS(GMPLS)経路。
Intra-AS (G)MPLS TE path: An MPLS TE or GMPLS path that is confined
to a single AS. It may traverse one or more IGP areas.
イントラ-AS(G)MPLS TE経路: 独身のASに閉じ込められるMPLS TEかGMPLS経路。 それは1つ以上のIGP領域を横断するかもしれません。
Intra-AS PCE: A PCE responsible for computing (G)MPLS TE paths
remaining within a single AS.
イントラ、-、PCE: (G) 独身のASに残っているMPLS TE経路を計算するのに責任があるPCE。
Inter-AS PCE: A PCE responsible for computing inter-AS (G)MPLS paths
or path segments, possibly by cooperating with intra-AS PCEs.
相互、PCE: ことによるとイントラ-AS PCEsと協力することによって相互AS(G)MPLS経路か経路セグメントを計算するのに責任があるPCE。
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 RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
3. Reference Model
3. 規範モデル
Figure 1 depicts the reference model for PCEs in an inter-AS application. We refer to two types of PCE functions in this document: inter-AS PCEs and intra-AS PCEs. Inter-AS PCEs perform the procedures needed for inter-AS (G)MPLS TE path computation while intra-AS PCEs perform the functions needed for intra-AS (G)MPLS TE path computation.
図1は相互ASアプリケーションにおけるPCEsのために規範モデルについて表現します。 私たちは本書では2つのタイプのPCE関数を示します: そして、相互、PCEs、イントラ、-、PCEs。 相互AS PCEsはイントラ-AS PCEsがイントラ-AS(G)MPLS TE経路計算に必要である機能を実行しますが、相互AS(G)MPLS TE経路計算に必要である手順を実行します。
Inter-AS Inter-AS Inter-AS
PCC <-->PCE1<--------->PCE2<---------------->PCE3
:: :: :: ::
:: :: :: ::
R1----ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7
| | | | | |
| | | | | |
R2----ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8
::
::
Intra-AS
PCE
相互、相互、相互、PCC<--、>PCE1<。--------->PCE2<。---------------->PCE3:、: :: :: :: :: :: :: :: R1----ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7| | | | | | | | | | | | R2----ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8:、: :: イントラ、-、PCE
<==AS1==> <=====AS2=====> <====AS3====>
<=>AS1=<。=====AS2=====><==AS3====>。
Figure 1: Inter- and Intra-AS PCE Reference Model
図1: そして、相互、イントラ、-、PCE規範モデル
Let's follow a scenario that illustrates the interaction among PCCs, inter-AS PCEs, and intra-AS PCEs, as shown in Figure 1. R1 in AS1 wants to setup a (G)MPLS TE path, call it LSP1, with certain constraints to R7 in AS3. R1 determines, using mechanisms out of the
図1に示されるようにPCCs、相互AS PCEs、およびイントラ-AS PCEsの中で相互作用を例証するシナリオに従いましょう。 AS1のR1は(G)MPLS TE経路をセットアップしたがっていて、AS3に、ある規制でそれをR7にLSP1と呼んでください。 R1、決定して、メカニズムを使用します。
Bitar, et al. Informational [Page 4] RFC 5376 Inter-AS Requirements for PCECP November 2008
Bitar、他 情報[4ページ]のRFC5376、相互、PCECP2008年11月のための要件
scope of this document, that R7 is an inter-AS route and that R1 (itself) needs to contact its Inter-AS PCE1 to compute the path. R1, as a PCC, sends a PCECP path computation request to PCE1. PCE1 determines that R7 is reachable via AS2 and that PCE2 is the PCE to ask for path computation across AS2. PCE1 sends a PCECP path computation request to PCE2. Inter-AS PCE2, in turn, sends a PCECP path computation request to Intra-AS PCE R4 to compute a path within AS2 (in certain cases, the same router such as R3 can assume both inter-AS and intra-AS path computation functions). R4 may for instance return a PCECP path computation response to PCE2 with ASBR3 as the entry point to AS2 from AS1 and ASBR7 as the exit point to AS3. PCE2 then sends a PCECP path computation request to PCE3 to compute the path segment across AS3, starting at ASBR7 and terminating at R7. PCE3 returns a PCECP path computation response to PCE2 with the path segment ASBR7-R7. PCE2 then returns path ASBR3- ASBR5-ASBR7-R7 to PCE1, which, in turn, returns path ASBR1-ASBR3- ASBR5-ASBR7-R7 to PCC R1.
このドキュメントの範囲、そのR7は相互ASルートであり、そのR1(それ自体)は経路を計算するためにInter-AS PCE1に連絡する必要があります。 PCCとして、R1はPCECP経路計算要求をPCE1に送ります。 PCE1は、AS2の向こう側に経路計算を求めるためにR7がAS2を通して届いていて、PCE2がPCEであることを決定します。 PCE1はPCECP経路計算要求をPCE2に送ります。 相互AS PCE2は、AS2の中で経路を計算するために順番にPCECP経路計算要求をIntra-AS PCE R4に送ります(ある場合には、R3などの同じルータは相互ASとイントラ-AS経路計算機能の両方を仮定できます)。 例えば、R4はエントリー・ポイントとしてエキジットポイントとしてのAS1とASBR7からAS3までASBR3とPCE2へのPCECP経路計算応答をAS2に返すかもしれません。 次に、PCE2はAS3の向こう側に経路セグメントを計算するためにPCECP経路計算要求をPCE3に送ります、ASBR7で始まって、R7で終わって。 PCE3は経路セグメントASBR7-R7とPCE2へのPCECP経路計算応答を返します。 次に、PCE2は経路ASBR3- ASBR5-ASBR7-R7をPCE1に返します(順番に経路ASBR1-ASBR3- ASBR5-ASBR7-R7をPCC R1に返します)。
As described in the above scenario, in general, a PCC may contact an inter-AS PCE to request the computation of an inter-AS path. That PCE may supply the path itself or may solicit the services of other PCEs, which may themselves be inter-AS PCEs, or may be intra-AS PCEs with the responsibility for computing path segments within just one AS.
一般に、上のシナリオで説明されるように、PCCは相互AS経路の計算を要求するために相互AS PCEに連絡するかもしれません。 PCEが自分たちで、経路自体を供給するか、または他のPCEsのサービスに請求するかもしれないのが、相互AS PCEsである、またはちょうど1ASの中で経路セグメントを計算することへの責任があるイントラ-AS PCEsであるかもしれません。(サービスはそうするかもしれません)。
This document describes the PCE Communication Protocol requirements for inter-AS path computation, i.e., for PCCs to communicate path computation requests for inter-AS (G)MPLS TE paths to PCEs, and for the PCEs to respond. It also includes the requirements for PCEs to communicate inter-AS path computation requests and responses.
すなわち、PCCsが相互AS(G)MPLS TE経路を求める経路計算要求をPCEsに伝えて、PCEsが応じるように、このドキュメントは相互AS経路計算のためのPCE Communicationプロトコル要件について説明します。 また、それはPCEsが相互AS経路計算要求と応答を伝えるという要件を含んでいます。
3.1. Scope of Deployment Model
3.1. 展開モデルの範囲
All attempts to predict future deployment scopes within the Internet have proven fruitless. Nevertheless, it may be helpful to provide some discussion of the scope of the inter-AS deployment model as envisioned at the time of writing.
今後の展開がインターネットの中で見られると予測するすべての試みが徒労に帰しました。 それにもかかわらず、相互AS展開モデルの範囲の何らかの議論を提供するのはこれを書いている時点で思い描かれるように役立っているかもしれません。
It is expected that most, if not all, inter-AS PCECP-based communications will be between PCEs operating in the cooperative PCE model described in [RFC4655]. Clearly, in this model, the requesting PCE acts as a PCC for the purpose of issuing a path computation request, but nevertheless, the requesting node fills the wider role of a PCE in its own AS. It is currently considered unlikely that a PCC (for example, a normal Label Switching Router) will make a path computation request to a PCE outside its own AS. This means that the PCECP relationships between ASes are limited to at most n squared (n^2), where n is the number of peering PCEs in the various ASes
PCEsの間には、ほとんどの相互AS PCECPベースのすべてでないならコミュニケーションが[RFC4655]で説明された協力的なPCEモデルで作動しながらあると予想されます。 明確に、このモデルでは、PCEが経路計算要求、しかし、それにもかかわらず、要求ノードを発行する目的のためのPCCとして機能させる要求はそれ自身のASにPCEの、より広い役割をいっぱいにしています。 PCC(例えば、正常なLabel Switching Router)がそれ自身のASの外で経路計算要求をPCEにするのは現在、ありそうもないと考えられます。 これは、ASesの間のPCECP関係が高々二乗されたn(n^2)に制限されることを意味します。(そこでは、nが様々なASesのじっと見るPCEsの数です)。
Bitar, et al. Informational [Page 5] RFC 5376 Inter-AS Requirements for PCECP November 2008
Bitar、他 情報[5ページ]のRFC5376、相互、PCECP2008年11月のための要件
(considered to be no greater than 100 in [RFC4657]). In practice, however, it is likely that only a few PCEs in one AS will be designated for PCECP communications with a PCE in an adjacent AS, and each of these will only have a few PCEs in the adjacent AS to choose from. A deployment model might place the PCEs as co-resident with the ASBRs, resulting in a manageable scaling of the PCE-PCE relationships. Scaling considerations (Section 4.2), manageability considerations (Section 4.3), and security considerations (Section 5) should be examined in the light of these deployment expectations.
([RFC4657]の100以下であると考えられます。) しかしながら、実際には、1ASのほんのいくつかのPCEsが中のPCEとの隣接しているAS、およびそれぞれのこれらには選ぶ隣接しているASのいくつかのPCEsがあるだけであるPCECPコミュニケーションのために指定されそうでしょう。 展開モデルはコレジデントとしてPCEsをASBRsに置くかもしれません、PCE-PCE関係の処理しやすいスケーリングをもたらして。 スケーリング問題(セクション4.2)、管理可能性問題(セクション4.3)、およびセキュリティ問題(セクション5)はこれらの展開期待の見地から調べられるべきです。
4. Detailed PCECP Requirements for Inter-AS G(MPLS) TE Path Computation
4. PCECP要件を詳しく述べる、相互、G(MPLS)Te経路計算
This section discusses detailed PCECP requirements for inter-AS (G)MPLS TE LSPs. Depending on the deployment environment, some or all of the requirements described here may be utilized. Specifically, some requirements are more applicable to inter- provider inter-AS (G)MPLS TE operations than to intra-provider operations.
このセクションは相互AS(G)MPLS TE LSPsのための詳細なPCECP要件について論じます。 要件の環境、いくつかまたはすべてがここで説明した展開によるのは利用されるかもしれません。 明確に、いくつかの要件がイントラプロバイダー操作より相互プロバイダー相互AS(G)MPLS TE操作に適切です。
4.1. PCE Communication Protocol Requirements
4.1. PCE通信プロトコル要件
Requirements specific to inter-AS PCECP path computation requests and responses are discussed in the following sections.
以下のセクションで相互AS PCECP経路計算要求に特定の要件と応答について議論します。
4.1.1. Requirements for Path Computation Requests
4.1.1. 経路計算要求のための要件
The following are inter-AS specific requirements for PCECP requests for path computation:
↓これは経路計算を求めるPCECP要求のための相互AS決められた一定の要求です:
1. [RFC4657] states the requirement for a priority level to be
associated with each path computation request. This document does
not change that requirement. However, PCECP should include a
mechanism that enables an inter-AS PCE to inform the requesting
inter-AS PCE of a change in the request priority level that may
have resulted from the application of a local policy.
1. [RFC4657]は、要件は優先順位がそれぞれの経路計算要求に関連していると述べます。 このドキュメントはその要件を変えません。 しかしながら、PCECPは相互AS PCEがローカルの方針の適用から生じたかもしれない要求要求における変化の相互AS PCE優先順位を知らせるのを可能にするメカニズムを含んでいるはずです。
2. A path computation request by an inter-AS PCE or a PCC to another
inter-AS PCE MUST be able to specify the sequence of ASes and/or
ASBRs across the network by providing ASBRs and/or ASes as hops in
the desired path of the TE LSP to the destination. For instance,
an inter-AS PCE MUST be able to specify to the inter-AS PCE
serving the neighboring AS a preferred ASBR for exiting to that AS
and reach the destination. That is, where multiple ASBRs exist,
the requester MUST be able to indicate a preference for one of
them. The PCE must be able to indicate whether the specified ASBR
or AS is mandatory or non-mandatory on the (G)MPLS TE path.
2. 経路計算は、相互AS PCEか別の相互AS PCE MUSTへのPCCからネットワークの向こう側にホップとしてTE LSPの必要な経路にASBRs、そして/または、ASesを提供することによってASes、そして/または、ASBRsの系列を目的地に指定できるよう要求します。 例えば、相互AS PCE MUST、それに出るための都合のよいASBRに隣接しているASに役立つ相互AS PCE ASに指定して、目的地に達することができてください。 すなわち、複数のASBRsが存在しているところでは、リクエスタは彼らのひとりのために優先を示すことができなければなりません。 PCEは、(G)MPLS TE経路で指定されたASBRかASが義務的であるか、または非義務的であるかを示すことができなければなりません。
Bitar, et al. Informational [Page 6] RFC 5376 Inter-AS Requirements for PCECP November 2008
Bitar、他 情報[6ページ]のRFC5376、相互、PCECP2008年11月のための要件
3. PCECP MUST allow a requester to provide a list of ASes and/or
ASBRs to be excluded from the computed path.
3. PCECP MUSTは、リクエスタに計算された経路から除かれるためにASes、そして/または、ASBRsのリストを提供させます。
4. A PCECP path computation request from one inter-AS PCE to another
MUST include the AS number of the requesting AS to enable the
correct application of local policy at the second inter-AS PCE.
4. 1相互AS PCEから別のAS PCEまでのPCECP経路計算要求は、第2相互AS PCEでローカルの方針の正しい適用を可能にするために要求しているASのAS番号を含まなければなりません。
5. A path computation request from a PCC to an inter-AS PCE or an
inter-AS PCE to another MUST be able to specify the need for
protection against node, link, or Shared Risk Link Group (SRLG)
failure using 1:1 detours or facility backup. It MUST be possible
to request protection across all ASes or across specific ASes.
5. PCCから相互AS PCEか相互AS PCEから別のものまでの経路計算要求は、1:1回り道か施設バックアップを使用することでノード、リンク、またはShared Risk Link Group(SRLG)の故障に対する保護の必要性を指定できなければなりません。 すべてのASesの向こう側に、または、特定のASesの向こう側に保護を要求するのは可能であるに違いありません。
6. PCECP MUST support the disjoint path requirements as specified in
[RFC4657]. In addition, it MUST allow the specification of AS-
diversity for the computation of a set of two or more paths.
6. PCECP MUSTが支持する、[RFC4657]の指定されるとしての経路要件をばらばらにならせてください。 さらに、それは2つ以上の経路の1セットの計算のためのASの多様性の仕様を許容しなければなりません。
7. A PCECP path computation request message MUST be able to identify
the scope of diversified path computation to be end-to-end (i.e.,
between the endpoints of the (G)MPLS TE tunnel) or to be limited
to a specific AS.
7. PCECP経路計算要求メッセージは終わりから終わり(すなわち、(G)MPLS TEトンネルの終点の間の)であることまで特定のASに制限されることように様々な経路計算の範囲を特定できなければなりません。
4.1.2. Requirements for Path Computation Responses
4.1.2. 経路計算応答のための要件
The following are inter-AS specific requirements for PCECP responses for path computation:
↓これは経路計算のためのPCECP応答のための相互AS決められた一定の要求です:
1. A PCECP path computation response from one inter-AS PCE to another
MUST be able to include both ASBRs and ASes in the computed path
while preserving path segment and topology confidentiality.
1. 1相互AS PCEから別のAS PCEまでのPCECP経路計算応答は経路セグメントとトポロジー秘密性を保存している間、計算された経路にASBRsとASesの両方を含むことができなければなりません。
2. A PCECP path computation response from one inter-AS PCE to the
requesting inter-AS PCE MUST be able to carry an identifier for a
path segment it computes to preserve path segment and topology
confidentiality. The objective of the identifier is to be
included in the TE LSP signaling, whose mechanism is out of scope
of this document, to be used for path expansion during LSP
signaling.
2. PCECP経路計算応答、要求への1相互AS PCE相互AS PCE MUSTから、それが経路セグメントとトポロジー秘密性を保存するために計算する経路セグメントのための識別子を運ぶことができてください。 識別子の目的は経路拡大にLSPシグナリングの間、使用されるためにこのドキュメントの範囲の外にメカニズムがあるTE LSPシグナリングに含まれることです。
3. If a constraint for a desired ASBR (see Section 4.1.1, requirement
2) cannot be satisfied by a PCE, PCECP SHOULD allow the PCE to
notify the requester of that fact as an error in a path
computation response.
3. PCEが必要なASBR(セクション4.1.1を見てください、要件2)の規制を満たすことができないなら、PCECP SHOULDはPCEに経路計算応答における誤りとしてその事実のリクエスタを通知させます。
4. A PCECP path computation response from an inter-AS PCE to a
requesting inter-AS PCE or a PCC MUST be able to carry a
cumulative inter-AS path cost. Path cost normalization across
ASes is out of scope of this document.
4. 相互AS PCEかPCC MUSTが累積している相互AS経路費用を運ぶことができるよう要求する相互AS PCEからaまでのPCECP経路計算応答。 このドキュメントの範囲の外にASesの向こう側の経路費用正常化があります。
Bitar, et al. Informational [Page 7] RFC 5376 Inter-AS Requirements for PCECP November 2008
Bitar、他 情報[7ページ]のRFC5376、相互、PCECP2008年11月のための要件
5. A PCECP path computation response from an inter-AS PCE to a PCC
SHOULD be able to carry the intra-AS cost of the path segment
within the PCC AS.
5. PCECP経路計算応答、相互AS PCEからPCC SHOULDまで、PCC ASの中で経路セグメントのイントラ-AS費用を運ぶことができてください。
6. A PCECP path computation response MUST be able to identify
diversified paths for the same (G)MPLS TE LSP. End-to-end (i.e.,
between the two endpoints of the (G)MPLS TE tunnel) disjoint paths
are paths that do not share nodes, links, or SRLGs except for the
LSP head-end and tail-end. In cases where diversified path
segments are desired within one or more ASes, the disjoint path
segments may share only the ASBRs of the first AS and the ASBR of
the last AS across these ASes.
6. 応答が特定できなければならないPCECP経路計算は同じ(G)MPLS TE LSPのために経路を多角化させました。 終わらせる終わり(すなわち、(G)MPLS TEトンネルの2つの終点の間の)はばらばらになります。経路はノード、リンク、またはLSPギヤエンドと末端以外のSRLGsを共有しない経路です。 ばらばらになってください。場合では、経路セグメントが1ASesの中で多角化するところで望まれている、経路セグメントはこれらのASesの向こう側に最初のASのASBRsだけと最後のASのASBRを共有してもよいです。
4.2. Scalability and Performance Considerations
4.2. スケーラビリティとパフォーマンス問題
PCECP design for use in the inter-AS case SHOULD consider the following criteria:
SHOULDが以下の評価基準であると考える相互AS場合における使用のためのPCECPデザイン:
- PCE message processing load.
- Scalability as a function of the following parameters:
o number of PCCs within the scope of an inter-AS PCE
o number of intra-AS PCEs within the scope of an inter-AS PCE
o number of peering inter-AS PCEs per inter-AS PCE
- Added complexity caused by inter-AS features.
- PCEメッセージ処理荷重。 - 以下のパラメタの関数としてのスケーラビリティ: o 相互AS PCEあたりの相互AS PCEsにじっと見る相互AS PCE o番号の範囲の中のイントラ-AS PCEsの相互AS PCE o番号の範囲の中のPCCsの数--相互ASの特徴によって引き起こされた複雑さを加えました。
4.3. Management Considerations
4.3. 管理問題
[RFC4657] specifies generic requirements for PCECP management. This document specifies new requirements that apply to inter-AS operations.
[RFC4657]はPCECP管理のための一般的な要件を指定します。 このドキュメントは相互AS操作に適用される新しい要件を指定します。
The PCECP MIB module MUST provide objects to control the behavior of PCECP in inter-AS applications. These objects include the ASes within the scope of an inter-AS PCE, inter-AS PCEs in neighboring ASes to which the requesting PCE will or will not communicate, confidentiality, and policies.
PCECP MIBモジュールは、相互ASアプリケーションにおける、PCECPの動きを制御するために物を提供しなければなりません。 これらの物は要求しているPCEが交信するか、または交信しない隣接しているASes、秘密性、および方針に相互AS PCE、相互AS PCEsの範囲の中のASesを含んでいます。
The built-in diagnostic tools MUST enable failure detection and status checking of PCC/PCE-PCE PCECP. Diagnostic tools include statistics collection on the historical behavior of PCECP as specified in [RFC4657], but additionally it MUST be possible to analyze these statistics on a neighboring AS basis (i.e., across the inter-AS PCEs that belong to a neighboring AS).
内蔵の診断用道具はPCC/PCE-PCE PCECPの失敗検出と状態点検を可能にしなければなりません。 診断用道具は[RFC4657]の指定されるとしてのPCECPの歴史的な動きに関する統計収集を含んでいますが、さらに、隣接ASベース(すなわち、近所付き合いに属す相互AS PCEs ASの向こう側の)でこれらの統計を分析するのは可能でなければなりません。
The MIB module MUST support trap functions when thresholds are crossed or when important events occur as stated in [RFC4657]. These thresholds SHOULD be specifiable per neighbor AS as well as per peer inter-AS PCE, and traps should be accordingly generated.
敷居が交差しているか、または重大事件が起こると、MIBモジュールは[RFC4657]に述べられているように罠機能をサポートしなければなりません。 同輩相互AS PCE、および罠に従って井戸は隣人AS単位で明記できるべきですが、これらの敷居SHOULDはそうです。
Bitar, et al. Informational [Page 8] RFC 5376 Inter-AS Requirements for PCECP November 2008
Bitar、他 情報[8ページ]のRFC5376、相互、PCECP2008年11月のための要件
Basic liveliness detection for PCC/PCE-PCE PCECP is described in [RFC4657]. The PCECP MIB module SHOULD allow control of liveliness check behavior by providing a liveliness message frequency MIB object, and this frequency object SHOULD be specified per inter-AS PCE peer. In addition, there SHOULD be a MIB object that specifies the dead-interval as a multiplier of the liveliness message frequency so that if no liveliness message is received within that time from an inter-AS PCE, the inter-AS PCE is declared unreachable.
PCC/PCE-PCE PCECPに、基本的な活気検出は[RFC4657]で説明されます。 指定されていて、PCECP MIBモジュールSHOULDは相互AS PCE同輩単位で活気メッセージ頻度MIB物、およびこの頻度物のSHOULDを提供するのによる活気チェックの振舞いのコントロールに許容します。 さらにと、そこ、SHOULD、その時中に相互AS PCEから活気メッセージを全く受け取らないなら、手が届かないと相互AS PCEを申告するための活気メッセージ頻度の乗数として死んでいる間隔を指定するMIB物になってください。
4.4. Confidentiality
4.4. 秘密性
Confidentiality mainly applies to inter-provider (inter-AS) PCE communication. It is about protecting the information exchanged between PCEs and about protecting the topology information within an SP's network. Confidentiality rules may also apply among ASes owned by a single SP. Each SP will in most cases designate some PCEs for inter-AS (G)MPLS TE path computation within its own administrative domain and some other PCEs for inter-provider inter-AS (G)MPLS TE path computation. Among the inter-provider-scoped inter-AS PCEs in each SP domain, there may also be a subset of the PCEs specifically enabled for path computation across a specific set of ASes of different peer SPs.
秘密性は相互プロバイダー(相互AS)PCEコミュニケーションに主に適用されます。 それはPCEsの間で交換された情報を保護して、SPのネットワークの中にトポロジー情報を保護することに関するものです。 また、機密保持規定は独身のSPによって所有されていたASesの中で適用されるかもしれません。 多くの場合、各SPは相互プロバイダー相互AS(G)MPLS TE経路計算のためにそれ自身の管理ドメインとある他のPCEsの中で(G)MPLS TE経路計算に相互ASのためのいくつかのPCEsを指定するでしょう。 また、それぞれのSPドメインの相互プロバイダーが見られた相互AS PCEsの中に、経路計算のために異なった同輩SPsのASesの特定のセットの向こう側に明確に有効にされたPCEsの部分集合があるかもしれません。
PCECP MUST allow an SP to hide from other SPs the set of hops within its own ASes that are traversed by an inter-AS inter-provider TE LSP (c.f., Section 5.2.1 of [RFC4216]). In a multi-SP administrative domain environment, SPs may want to hide their network topologies for security or commercial reasons. Thus, for each inter-AS TE LSP path segment an inter-AS PCE computes, it may return to the requesting inter-AS PCE an inter-AS TE LSP path segment from its own ASes without detailing the explicit intra-AS hops. As stated earlier, PCECP responses SHOULD be able to carry path-segment identifiers that replace the details of that path segment. The potential use of that identifier for path expansion, for instance, during LSP signaling is out of scope of this document.
PCECP MUSTはSPに相互AS相互プロバイダーTE LSP(c.f.、.1セクション5.2[RFC4216])によって横断されるそれ自身のASesの中に他のSPsからホップのセットを隠させます。 マルチSPの管理ドメイン環境で、SPsはセキュリティか商業的理由のために彼らのネットワークtopologiesを隠したがっているかもしれません。 したがって、相互AS PCEが計算するそれぞれの相互AS TE LSP経路セグメントのために、明白なイントラ-ASホップについて詳述しないで、それは相互AS TE LSP経路セグメントをそれ自身のASesから要求している相互AS PCEに返すかもしれません。 より初期のPCECP応答SHOULDを述べるように、その経路セグメントの詳細を置き換える経路セグメント識別子は運ぶことができてください。 このドキュメントの範囲の外にその識別子の例えば、LSPシグナリングの間の経路拡大の潜在的使用があります。
4.5. Policy Controls Affecting Inter-AS PCECP
4.5. 方針が影響を制御する、相互、PCECP
Section 5.2.2 of [RFC4216] discusses the policy control requirements for inter-AS RSVP-TE signaling at the AS boundaries for the enforcement of interconnect agreements, attribute/parameter translation and security hardening.
.2セクション5.2[RFC4216]が、内部連絡協定、属性/パラメタ翻訳、およびセキュリティ硬化剤の実施のためにAS境界で合図しながら、相互AS RSVP-TEのための方針コントロール要件について議論します。
This section discusses those policy control requirements that are similar to what are discussed in section 5.2.2 of [RFC4216] for PCECP. Please note that SPs may still require policy controls during
このセクションはそれらのPCECPのために.2セクション5.2[RFC4216]で議論することと同様の方針コントロール要件について論じます。 そのSPsはまだ方針コントロールを必要としているかもしれません。
Bitar, et al. Informational [Page 9] RFC 5376 Inter-AS Requirements for PCECP November 2008
Bitar、他 情報[9ページ]のRFC5376、相互、PCECP2008年11月のための要件
signaling of TE LSPs to enforce their bilateral or multilateral agreements at AS boundaries, but signaling is out of scope for this document.
このドキュメントのための範囲の外にしかし、AS境界、シグナリングで彼らの双方の、または、多面的な協定を実施するTE LSPsのシグナリングがあります。
4.5.1. Inter-AS PCE Peering Policy Controls
4.5.1. 相互、PCEじっと見る方針は制御されます。
An inter-AS PCE sends path computation requests to its neighboring inter-AS PCEs, and an inter-AS PCE that receives such a request enforces policies applicable to the sender of the request. These policies may include rewriting some of the parameters or rejecting requests based on parameter values. Such policies may be applied for PCEs belonging to different SPs or to PCEs responsible for ASes within a single SP administrative domain. Parameters that might be subject to policy include bandwidth, setup/holding priority, Fast Reroute request, Differentiated Services Traffic Engineering (DS-TE) Class Type (CT), and others as specified in section 5.2.2.1 of [RFC4216].
相互AS PCEは経路計算要求を隣接している相互AS PCEsに送ります、そして、そのような要求を受け取る相互AS PCEは要求の送付者に適切な方針を実施します。 これらの方針は、パラメタのいくつかを書き直すか、またはパラメタ値に基づく要求を拒絶するのを含むかもしれません。 そのような方針は異なったSPsに属すPCEsかただ一つのSP管理ドメインの中のASesに責任があるPCEsに適用されるかもしれません。 方針を受けることがあるかもしれないパラメタは、セクション5.2.2で.1[RFC4216]を指定するので、帯域幅、セットアップ/把持優先権、Fast Reroute要求、Differentiated Services Traffic Engineering(DS-TE)クラスType(コネチカット)、および他のものを含んでいます。
For path computation requests that are not compliant with locally configured policies, PCECP SHOULD enable a PCE to send an error message to the requesting PCC or PCE indicating that the request has been rejected because a specific parameter did not satisfy the local policy.
局所的に構成された方針で対応でない経路計算要求のために、PCECP SHOULDは、PCEが要求へのエラーメッセージにPCCを送るか、または特定のパラメタが満足させられなかったので要求が拒絶されたのを示すPCEにローカルの方針を送るのを可能にします。
4.5.2. Inter-AS PCE Re-Interpretation Policies
4.5.2. 相互、PCE再解釈方針
Each SP may have different definitions in its use of, for example, DS-TE TE classes. An inter-AS PCE receiving a path computation request needs to interpret the parameters and constraints and adapt them to the local environment. Specifically, a request constructed by a PCC or PCE in one AS may have parameters and constraints that should be interpreted differently or translated by the receiving PCE that is in a different AS. A list of signaling parameters subject to policy re-interpretation at AS borders can be found in section 5.2.2.2 of [RFC4216], and the list for path computation request parameters and constraints is the same. In addition, the transit SPs along the inter-AS TE path may be GMPLS transport providers, which may require re-interpretation of MPLS-specific PCECP path computation request objects in order to enable path computation over a GMPLS network or vice versa.
各SPには、例えば、DS-TE TEのクラスの使用における異なった定義があるかもしれません。 経路計算要求を受け取る相互AS PCEはパラメタと規制を解釈して、地方の環境にそれらを適合させる必要があります。 明確に、1ASでPCCかPCEによって構成された要求は異なったASにある受信PCEによって異なって解釈されるはずであるか、または翻訳されるはずであるパラメタと規制を持っているかもしれません。 AS境界の方針再解釈を条件としたシグナリングパラメタのリストはセクション5.2.2で.2[RFC4216]を設立することであるかもしれません、そして、経路計算要求パラメタと規制のためのリストは同じです。 さらに、相互AS TE経路に沿ったトランジットSPsはGMPLS輸送プロバイダーであるかもしれませんか逆もまた同様です。(プロバイダーは、GMPLSネットワークの上の経路計算を可能にするためにMPLS特有のPCECP経路計算要求物の再解釈を必要とするかもしれません)。
5. Security Considerations
5. セキュリティ問題
The PCECP is a communications protocol for use between potentially remote entities (PCCs and PCEs) over an IP network. Security concerns arise in order to protect the PCC, PCE, and the information they exchange. [RFC4758] specifies requirements on the PCECP to protect against spoofing, snooping, and DoS attacks. That document
PCECPはIPネットワークの上の潜在的にリモートな実体(PCCsとPCEs)の間の使用のための通信規約です。 安全上の配慮は、彼らが交換するPCC、PCE、および情報を保護するために起こります。 [RFC4758]はスプーフィング、詮索、およびDoS攻撃から守るというPCECPに関する要件を指定します。 そのドキュメント
Bitar, et al. Informational [Page 10] RFC 5376 Inter-AS Requirements for PCECP November 2008
Bitar、他 情報[10ページ]のRFC5376、相互、PCECP2008年11月のための要件
is concerned with general protocol requirements applicable to the basic use of the PCECP. This document is specific to the application of the PCE architecture in an inter-AS environment, and so it is appropriate to highlight the security considerations that apply in that environment.
PCECPの基本的な使用に適切な一般的なプロトコル要件に、関係があります。 このドキュメントが相互AS環境における、PCE構造の応用に特定であるので、その環境で適用されるセキュリティ問題を強調するのは適切です。
Security requirements that exist within a single administrative domain become critical in the multi-AS case when the control of IP traffic and access to the network may leave the authority of a single administration.
IP交通のコントロールとネットワークへのアクセスがただ一つの管理の権威を残すとき、ただ一つの管理ドメインの中に存在するセキュリティ要件はマルチAS場合で批判的になります。
5.1. Use and Distribution of Keys
5.1. キーの使用と分配
How the participants in a PCECP session discover each other and the need for the session is out of scope of this document. It may be through configuration or automatic discovery. However, when a PCECP session is established, the PCECP speakers MUST have mechanisms to authenticate each other's identities and validate the data they exchange. They also SHOULD have mechanisms to protect the data that they exchange via encryption. Such mechanisms usually require the use of keys, and so the PCECP MUST describe techniques for the exchange and use of security keys. Where inter-AS PCE discovery is used, and PCECP security is required, automated key distribution mechanisms MUST also be used. Since such key exchange must (necessarily) operate over an AS boundary, proper consideration needs to be given to how inter-AS key exchanges may be carried out and how the key exchange, itself, may be secured. Key distribution mechanisms MUST be defined with consideration of [RFC4107]. Where a PCECP session is configured between a pair of inter-AS PCEs, a security key may be manually set for that session.
このドキュメントの範囲の外にPCECPセッションの関係者がどうセッションの互いと必要性を発見するかがあります。 それは構成か自動発見であるかもしれません。 しかしながら、PCECPセッションが確立されるとき、PCECPスピーカーには、互いのアイデンティティを認証して、それらが交換するデータを有効にするメカニズムがなければなりません。 それら、また、SHOULDには、それらが暗号化で交換するデータを保護するメカニズムがあります。 そのようなメカニズムが通常キーの使用を必要とするので、PCECP MUSTはセキュリティキーの交換と使用のためのテクニックについて説明します。 また、相互AS PCE発見が使用されていて、PCECPセキュリティが必要であるところでは、自動化された主要な分配メカニズムを使用しなければなりません。 そのような主要な交換が(必ず)AS境界の上で作動しなければならないので、適切な考慮は、どのように相互ASの主要な交換を行うかもしれないか、そして、どのように、主要な交換(それ自体)を保証するかもしれないかに与えられている必要があります。 [RFC4107]の考慮で主要な分配メカニズムを定義しなければなりません。 PCECPセッションが1組の相互AS PCEsの間で構成されるところでは、セキュリティキーはそのセッションのために手動で設定されるかもしれません。
5.2. Application of Policy
5.2. 方針の適用
Policy forms an important part of the operation of PCEs in an inter- AS environment as described in Section 4.5, especially when ASes are administrated by different SPs. A wider discussion of the application of policy to the PCE architecture can be found in [PCE-POLICY].
方針はセクション4.5で説明されるように相互AS環境における、PCEsの操作の重要な部分を形成します、特にASesが異なったSPsによって管理されるとき。 [PCE-POLICY]でPCE構造への方針の適用の、より広い議論を見つけることができます。
Policy may also form part of the security model for the PCECP and may be particularly applicable to inter-AS path computation requests. A fundamental element of the application of policy at a PCE is the identity of the requesting PCC/PCE. This makes the use of authentication described in Section 5.1 particularly important. Where policy information is exchanged as part of the computation request and/or response, the policy object is transparent to the PCECP being delivered un-inspected and unmodified to the policy component of a PCE or PCC. Therefore, the policy components are
方針は、また、PCECPのために機密保護モデルの一部を形成するかもしれなくて、特に相互AS経路計算要求に適切であるかもしれません。 PCEの方針の適用の基本的な要素は要求しているPCC/PCEのアイデンティティです。 これで、セクション5.1で説明された認証の使用は特に重要になります。 計算要求、そして/または、応答の一部として方針情報を交換するところでは、政策目的はPCEかPCCの方針の部品に不-点検されていて変更されていなく届けられるPCECPに透明です。 したがって、方針コンポーネントはそうです。
Bitar, et al. Informational [Page 11] RFC 5376 Inter-AS Requirements for PCECP November 2008
Bitar、他 情報[11ページ]のRFC5376、相互、PCECP2008年11月のための要件
responsible for protecting (for example, encrypting) the policy information and using additional identification and authentication if a higher level of validation is required than is provided by the base protocol elements of the PCECP.
より高いレベルの合法化がPCECPのベースプロトコル要素で提供するより必要であるなら、方針情報を保護して(例えば、コード化)、追加識別と認証を使用するのに責任があります。
5.3. Confidentiality
5.3. 秘密性
The PCECP MUST provide a mechanism to preserve the confidentiality of path segments computed by a PCE in one AS and provided in a computation response to another AS.
PCECP MUSTは、1ASでPCEによって計算されて、別のASへの計算応答に提供された経路セグメントの秘密性を保存するためにメカニズムを提供します。
Furthermore, a PCE SHOULD be provided with a mechanism to mask its identity such that its presence in the path computation chain in a cooperative PCE model (such as described in [BRPC]) cannot be derived from the computed path. This will help to protect the PCE from targeted attacks. Clearly, such confidentiality does not extend to the PCECP peer (i.e., a PCC or another PCE) that invokes the PCE with a path computation request.
その上、PCE SHOULD、メカニズムを提供して、計算された経路から協力的なPCEモデル([BRPC]で説明されるように)の経路計算チェーンにおける存在を得ることができないようにアイデンティティにマスクをかけてください。 これは、狙っている攻撃からPCEを保護するのを助けるでしょう。 明確に、そのような秘密性は経路計算要求でPCEを呼び出すPCECP同輩(すなわち、PCCか別のPCE)に達しません。
5.4. Falsification of Information
5.4. 情報の改竄
In the PCE architecture, when PCEs cooperate, one PCE may return a path computation result that is composed of multiple path segments, each computed by a different PCE. In the inter-AS case, each PCE may belong to a different administrative domain, and the source PCC might not know about the downstream PCEs, nor fully trust them. Although it is possible and RECOMMENDED to establish a chain of trust between PCEs, this might not always be possible. In this case, it becomes necessary to guard against a PCE changing the information provided by another downstream PCE. Some mechanism MUST be available in the PCECP, and echoed in the corresponding signaling, that allows an AS to verify that the signaled path conforms to the path segment computed by the local PCE and returned on the path computation request.
PCE構造では、PCEsが協力するとき、1PCEが複数の経路セグメント(異なったPCEによって計算されたそれぞれ)で構成される経路計算結果を返すかもしれません。 相互AS場合では、各PCEが異なった管理ドメインに属すかもしれなくて、ソースPCCは川下のPCEsに関して知って、完全に彼らを信じるかもしれないというわけではありません。 それは可能です、そして、aを設立するRECOMMENDEDはPCEsの間の信用をチェーニングしますが、これはいつも可能であるかもしれないというわけではありません。 この場合、別の川下のPCEによって提供された情報を変えるPCEに用心するのは必要になります。 何らかのメカニズムがPCECPで利用可能で、対応するシグナリングで反響していなければならない、それで、ASは合図された経路が地方のPCEによって計算されて、経路計算要求のときに返された経路セグメントに従うことを確かめることができます。
6. Acknowledgments
6. 承認
We would like to thank Adrian Farrel, Jean-Philippe Vasseur, and Jean Louis Le Roux for their useful comments and suggestions. Pasi Eronen and Sandy Murphy provided valuable early Security Directorate reviews. Adrian Farrel re-wrote the Security Considerations section.
彼らの役に立つコメントと提案についてエードリアン・ファレル、ジャンフィリップVasseur、およびジャンルイのル・ルーに感謝申し上げます。 パシEronenとサンディー・マーフィーは貴重な早めのSecurity Directorateレビューを提供しました。 エードリアン・ファレルはSecurity Considerations部を書き直しました。
Bitar, et al. Informational [Page 12] RFC 5376 Inter-AS Requirements for PCECP November 2008
Bitar、他 情報[12ページ]のRFC5376、相互、PCECP2008年11月のための要件
7. Normative References
7. 引用規格
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for
Cryptographic Key Management", BCP 107, RFC 4107, June
2005.
[RFC4107]Bellovin、S.とR.Housley、「暗号化キー管理のためのガイドライン」BCP107、2005年6月のRFC4107。
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-
Autonomous System (AS) Traffic Engineering (TE)
Requirements", RFC 4216, November 2005.
[RFC4216] エドチャン、R.、J.-P。 Vasseur、エド「MPLS相互自律システム(AS)交通は(Te)要件を設計すること」でのRFC4216、2005年11月。
[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. Informative References
8. 有益な参照
[BRPC] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A
Backward Recursive PCE-based Computation (BRPC)
Procedure To Compute Shortest Constrained Inter-domain
Traffic Engineering Label Switched paths", Work in
Progress, April 2008.
[BRPC] Vasseur、JP、チャン、R.、Bitar、N.、およびJL。 ル・ルー、「計算する中でEngineeringがラベルする中で制約つき相互ドメイン交通最も短い後方の再帰的なPCEベースの計算(BRPC)手順は経路を切り換えました」、ProgressのWork、2008年4月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
October 2005.
[RFC4206]Kompella(K.とY.Rekhter)は「一般化されたマルチプロトコルラベルスイッチング(GMPLS)交通工学(Te)で切り換えられた経路(LSP)を階層構造とラベルします」、RFC4206、2005年10月。
[RFC4758] Nystroem, M., "Cryptographic Token Key Initialization
Protocol (CT-KIP) Version 1.0 Revision 1", RFC 4758,
November 2006.
[RFC4758]Nystroem、M.、「暗号の象徴主要な初期設定プロトコル(コネチカット-キップ)バージョン、1.0、改正1インチ、2006インチ年11月のRFC4758。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
"Label Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering (GMPLS
TE)", RFC 5150, February 2008.
[RFC5150]Ayyangar(A.、Kompella、K.、Vasseur(JP)、およびA.ファレル)は「一般化されたMultiprotocolラベル切り換え交通工学(GMPLS Te)でステッチされる切り換えられた経路をラベルします」、RFC5150、2008年2月。
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-
Domain MPLS and GMPLS Traffic Engineering -- Resource
Reservation Protocol-Traffic Engineering (RSVP-TE)
Extensions", RFC 5151, February 2008.
[RFC5151] ファレル、A.、エド、Ayyangar、A.、およびJP。 Vasseurに、「相互ドメインMPLSとGMPLSは工学を取引します--資源予約プロトコル交通工学(RSVP-Te)拡大」、RFC5151、2月2008日
Bitar, et al. Informational [Page 13] RFC 5376 Inter-AS Requirements for PCECP November 2008
Bitar、他 情報[13ページ]のRFC5376、相互、PCECP2008年11月のための要件
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
Per-Domain Path Computation Method for Establishing
Inter-Domain Traffic Engineering (TE) Label Switched
Paths (LSPs)", RFC 5152, February 2008.
[RFC5152]Vasseur(JP)、エド、Ayyangar、A.、エドR.チャン、「相互ドメイン交通工学(Te)ラベルを設立するための1ドメインあたり1つの経路計算方法が経路(LSPs)を切り換えました」、RFC5152、2月2008
[PCE-POLICY] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", Work in
Progress, October 2007.
I.、Papadimitriou、D.、バーガー、L.、およびJ.灰、「方針で可能にされた経路計算枠組み」という[PCE-方針]Bryskinは進歩、2007年10月に働いています。
Authors' Addresses
作者のアドレス
Nabil Bitar Verizon 117 West Street Waltham, MA 02451 USA EMail: nabil.n.bitar@verizon.com
ウォルサム、Nabil Bitarベライゾン117MA02451米国ウェスト・ストリートはメールされます: nabil.n.bitar@verizon.com
Kenji Kumaki KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama 356-8502, JAPAN EMail: ke-kumaki@kddi.com
埼玉356-8502、Kenji Kumaki KDDI研究開発研究所Inc.2-1-15Ohara日本ふじみ野はメールされます: ke-kumaki@kddi.com
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
Bitar, et al. Informational [Page 14]
Bitar、他 情報[14ページ]
一覧
スポンサーリンク
