[要約] RFC 5376は、異なるAS間での経路計算要素通信プロトコル（PCECP）の要件を定義しています。このRFCの目的は、異なるAS間での経路計算要素の相互運用性を確保し、ネットワークの効率と信頼性を向上させることです。
Network Working Group N. Bitar
Request for Comments: 5376 Verizon
Category: Informational R. Zhang
BT
K. Kumaki
KDDI R&D Labs
November 2008
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）2008 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
マルチプロトコルラベルスイッチングトラフィックエンジニアリング（MPLS TE）ラベルスイッチパス（LSP）は、自律システム（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.
パス計算要素（PCE）は、（g）MPLS TE LSPの制約パスを計算できるコンポーネントです。PCE通信プロトコル（PCECP）は、PATH計算クライアント（PCCS）とPCE、およびPCE間の通信を可能にするために定義されます。PCECPは、制約付きパスを要求し、それに応じて計算されたパスを提供するために使用されます。PCECPの一般的な要件は、「PATH計算要素（PCE）通信プロトコルジェネリック要件」、RFC 4657に記載されています。このドキュメントは、MPLS Inter-AS MPLS TEをサポートするPCECPの使用をカバーするためにそれらの要件を拡張します。
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
[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間のマルチプロトコルラベルスイッチングトラフィックエンジニアリング（MPLS TE）の展開を動機付けるシナリオを定義し、ASEが1つのサービスプロバイダー（SP）の管理下にある場合、またはMPLS間の要件を指定します。異なるSPS。
Three signaling options are defined for setting up an inter-AS TE Label Switched Path (LSP):
3つのシグナル伝達オプションが、テラメシン間スイッチ付きパス（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]で議論された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 LSPの計算のメカニズムを定義します。[RFC5152]のメカニズムは、TE LSPの最適なパスが正規化されたTEメトリックに従って（TEメトリックまたはインテリアゲートウェイプロトコルに基づく（IGP）、TE LSPの最適なパスが最小のパスである複数のASES間の最適な制約パスを保証するものではありません。）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計算要素（PCE）[RFC4655]は、MPLS TEおよび一般化されたマルチプロトコルラベルスイッチングプロトコル（（g）MPLS TE）LSPのパスを計算できるコンポーネントです。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通信プロトコル（PCECP）は、PATH計算クライアント（PCCS）とPCES、およびPCE間の通信を可能にするために定義されています。PCECPは、（g）MPLS TEパスを要求し、それに応じて計算されたパスを提供するために使用されます。PCECPの一般的な要件については、[RFC4657]で説明しています。このドキュメントは、（g）MPLS TEパス計算に固有のPCECP要件のセットを提供します。
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：自律システムボーダールーター（RFC 4216のセクション3を参照）
PCECP: PCE Communication Protocol (G)MPLS TE: MPLS or Generalized MPLS Traffic Engineering
PCECP：PCE通信プロトコル（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.
Inter-AS（g）MPLS TEパス：2つ以上のASを横断するMPLS TEまたは一般化された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.
Intra-AS（g）MPLS TEパス：単一に限定されるMPLS TEまたはGMPLSパス。1つ以上のIGP領域を横断する場合があります。
Intra-AS PCE: A PCE responsible for computing (G)MPLS TE paths remaining within a single AS.
PCE Intra-AS：単一のAS内に残っているMPLS TEパスのコンピューティング（g）の責任者。
Inter-AS PCE: A PCE responsible for computing inter-AS (G)MPLS paths or path segments, possibly by cooperating with intra-AS PCEs.
AS Inter-AS PCE：おそらくAS Inter PCEと協力することにより、（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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119に記載されているとおりに解釈されます。
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 Inter-ASアプリケーションのPCESの参照モデルを示しています。このドキュメントでは、2種類のPCE関数を参照してください：PCESとAS PCESINTINTINTINT。AS Inter-AS PCESは、（g）MPLS TEパス計算に必要な手順を実行しますが、AS Intra-AS PCESは、（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
<==AS1==> <=====AS2=====> <====AS3====>
Figure 1: Inter- and Intra-AS PCE Reference Model
図1：PCE間およびAS Intra-AS 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 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.
図1に示すように、PCCS、AS Inter-AS PCES、およびAS PCES間の相互作用を示すシナリオに従ってみましょう。AS1のR1は、（g）MPLS TEパスをセットアップしたい場合、LSP1を呼び出し、AS3のR7。R1は、このドキュメントの範囲からメカニズムを使用して、R7はInter-ASルートであり、R1（それ自体）がパスを計算するためにそのPCE1間で接触する必要があることを決定します。R1は、PCCとして、PCECPパス計算要求をPCE1に送信します。PCE1は、R7がAS2を介して到達可能であり、PCE2がAS2全体でパス計算を要求するPCEであると判断します。PCE1は、PCECPパス計算要求をPCE2に送信します。inter-as pce2は、PCECPパス計算リクエストをPCE R4 AS Intra-As-AS R4に送信してAS2内のパスを計算します（特定の場合、R3などの同じルーターは、AS間およびAS Intra-AS PATH計算関数の両方を仮定できます。）。たとえば、R4は、AS1からAS2へのエントリポイントとしてASBR3を使用してPCECPパス計算応答を、出口ポイントとしてAS2からASBR7に戻すことができます。PCE2は、PCECPパス計算要求をPCE3に送信して、ASBR7から開始し、R7で終了するAS3全体でパスセグメントを計算します。PCE3は、パスセグメントASBR7-R7を使用してPCECPパス計算応答をPCE2に返します。PCE2は、PATH ASBR3- ASBR5-ASBR7-R7をPCE1に戻します。これにより、PATH 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はPCE間のPCEに連絡して、Inter-ASパスの計算を要求する場合があります。そのPCEは、パス自体を供給するか、他のPCEのサービスを募集する場合があります。これは、それ自体が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間のPCCがPCSにパスを通知するためのPCCSがPCESへのPATH計算要求を通信し、PCESが応答するためのPCCSのPCE通信プロトコル要件について説明します。また、PCESがパス計算リクエストと応答を伝達するための要件も含まれています。
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 (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.
すべてではないにしても、PCECPベースの通信をすべてではないにしても、[RFC4655]で説明されている協同PCEモデルで動作するPCEの間には、ほとんどのほとんどが予想されます。明らかに、このモデルでは、要求するPCEはパス計算要求を発行する目的でPCCとして機能しますが、それでも要求ノードはPCEのより広い役割を独自のASで満たします。現在、PCC（たとえば、通常のラベルスイッチングルーター）が、ASの外側のPCEにパス計算要求を行う可能性は低いと考えられています。これは、ASE間のPCECP関係が最大のN 2乗（n^2）に限定されていることを意味します。ここで、nはさまざまなASEのピアリングPCEの数です（[RFC4657]で100以下と見なされます）。ただし、実際には、隣接するASでPCECP通信に指定されるPCECP通信に指定される1つのPCEsのみが、それぞれが隣接するものしか選択されていない可能性があります。展開モデルは、PCEをASBRとの共同居住者として配置し、PCE-PCE関係の管理可能なスケーリングをもたらす可能性があります。スケーリングの考慮事項（セクション4.2）、管理可能性の考慮事項（セクション4.3）、およびセキュリティに関する考慮事項（セクション5）は、これらの展開の期待に照らして調べる必要があります。
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 LSPの詳細なPCECP要件について説明します。展開環境に応じて、ここで説明する要件の一部またはすべてが利用される場合があります。具体的には、一部の要件は、プロバイダー間の操作よりも、プロバイダー間界面間の（g）MPLS TE操作により適用可能です。
Requirements specific to inter-AS PCECP path computation requests and responses are discussed in the following sections.
PCECP PATHの計算リクエストと応答をAS Inter-AS ASに固有の要件については、次のセクションで説明します。
The following are inter-AS specific requirements for PCECP requests for path computation:
以下は、PATH計算のPCECP要求の特定の要件としての間であります。
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には、PCE間のPCEが、ローカルポリシーの適用から生じる可能性のあるリクエスト優先レベルの変更を要求する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. PCE間のパス計算要求または別のPCCへのPCCは、ASBRSおよび/またはASEを所望のパスのホップとしてASBRSおよび/またはASESに提供することにより、ASEおよび/またはASBRのシーケンスを指定できる必要があります。目的地へのte lsp。たとえば、PCE間のPCEは、隣接するASBRとして提供するPCEをAS Inter-AS PCEに指定して、それを終了し、目的地に到達するために指定できる必要があります。つまり、複数のASBRが存在する場合、要求者はそのうちの1つの好みを示すことができなければなりません。PCEは、指定されたASBRが（g）MPLS TEパスで必須または非監視であるかどうかを示すことができなければなりません。
3. PCECP MUST allow a requester to provide a list of ASes and/or ASBRs to be excluded from the computed path.
3. PCECPは、要求者がASEおよび/またはASBRのリストを計算されたパスから除外することを許可する必要があります。
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つのPCE間から別のPCEへのPCECPパス計算要求には、2番目のPCE間でローカルポリシーの正しいアプリケーションを有効にするために、要求の数を含める必要があります。
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からPCE間のPCCへのパス計算要求または別のPCEへのパス計算リクエストは、1：1の迂回または共有リスクリンクグループ（SRLG）障害に対するノード、リンク、または共有リスクリンクグループ（SRLG）障害に対する保護の必要性を指定できる必要があります。施設のバックアップ。すべてのASEまたは特定のASEにわたって保護を要求することは可能でなければなりません。
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は、[RFC4657]で指定されているように、分離パス要件をサポートする必要があります。さらに、2つ以上のパスのセットの計算のために、diversity性の仕様を許可する必要があります。
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に制限するようにすることができる必要があります。
The following are inter-AS specific requirements for PCECP responses for path computation:
以下は、PATH計算のためのPCECP応答の特定の要件としての間であります。
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. PCE間のPCE間から別のPCE間のPCECPパス計算応答は、パスセグメントとトポロジの機密性を保持しながら、計算されたパスにASBRとASEの両方を含めることができなければなりません。
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. PCE間の1つのPCECP PATH計算応答は、PCE間のPCE間の要求に応じて、パスセグメントとトポロジの機密性を保持するために計算するパスセグメントの識別子を携帯できる必要があります。識別子の目的は、このドキュメントの範囲外であるTE LSPシグナル伝達に含めることであり、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. 目的のASBRの制約（セクション4.1.1、要件2を参照）をPCEで満たすことができない場合、PCECPは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. PCE間のPCECP PATH計算応答は、PCE間のPCEまたはPCCを要求するリクエスト型またはPCCへの累積パス間コストを運ぶことができなければなりません。ASES間のパスコストの正規化は、このドキュメントの範囲外です。
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. PCE間のPCCからPCCへのPCECPパス計算応答は、PCC内のパスセグメントの中間コストを運ぶことができるはずです。
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ヘッドエンドとテールエンドを除き、ノード、リンク、またはSRLGを共有しないパスです。1つ以上のASE内で多様化された経路セグメントが望まれている場合、分離パスセグメントは、これらのASESを横切る最初のASと最後のASBRのASBRのみを共有できます。
PCECP design for use in the inter-AS case SHOULD consider the following criteria:
AS Inter-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 PCCの数の範囲内のPCCの数o PCE Intra-AS PCEの数は、PCE間の範囲内でPCEの範囲内でPCE oインター間のピアリング間でのPCEの数ですPCEとして - AS Inter -AS機能によって引き起こされる複雑さを追加しました。
[RFC4657] specifies generic requirements for PCECP management. This document specifies new requirements that apply to inter-AS operations.
[RFC4657]は、PCECP管理の一般的な要件を指定します。このドキュメントは、AS Inter-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 Inter-ASアプリケーションでPCECPの動作を制御するオブジェクトを提供する必要があります。これらのオブジェクトには、PCE間の範囲内のASESが含まれ、要求するPCEが通信する、または通信しない、またはポリシーが通信する、またはポリシーを行う隣接ASEのPCE間のASを含みます。
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間）。
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]に記載されているように、しきい値が交差する場合、または重要なイベントが発生したときにトラップ関数をサポートする必要があります。これらのしきい値は、PCEとしてのピア間およびトラップを生成する場合と同様に、近隣ごとに指定できる必要があります。
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モジュールは、活気のあるメッセージ周波数MIBオブジェクトを提供することにより、活気のあるチェック動作を制御できるようにする必要があります。この周波数オブジェクトは、PCEピア間で指定する必要があります。さらに、Dead間隔を活気のあるメッセージ頻度の乗数として指定するMIBオブジェクトがある必要があります。これにより、PCE間でその時間内に生世界のメッセージが受信されない場合、PCE間は到達不能であると宣言されます。
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通信に適用されます。PCEの間で交換される情報を保護し、SPのネットワーク内のトポロジ情報を保護することです。機密性ルールは、単一のspが所有するASEにも適用される場合があります。ほとんどの場合、各SPは、独自の管理ドメイン内の（g）MPLS TEパス計算のいくつかのPCEを指定し、プロバイダー間界間間（g）MPLS TEパス計算の他のPCESを指定します。各SPドメインのプロバイダー間でスコープした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は、SPが他のSPSから、Provider Inter-Provider TE LSP（C.F.、[RFC4216]のセクション5.2.1）によって横断される独自のASE内のホップのセットを隠すことを許可する必要があります。マルチSP管理ドメイン環境では、SPSはセキュリティまたは商業上の理由でネットワークトポロジを非表示にすることをお勧めします。したがって、各LSPパスセグメントの各PCEコンピューターとの間に、それは、明示的なASホップの詳細を詳述することなく、独自のASESからの間のLSPパスセグメントを要求するPCEに戻ることができます。前述のように、PCECP応答は、そのパスセグメントの詳細を置き換えるパスセグメント識別子を運ぶことができるはずです。たとえば、LSPシグナル伝達中のパス拡張のためのその識別子の潜在的な使用は、このドキュメントの範囲外です。
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.
[RFC4216]のセクション5.2.2は、相互接続契約、属性/パラメーター翻訳、セキュリティ硬化の施行の境界としての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 signaling of TE LSPs to enforce their bilateral or multilateral agreements at AS boundaries, but signaling is out of scope for this document.
このセクションでは、PCECPの[RFC4216]のセクション5.2.2で説明されているものと同様のポリシー管理要件について説明します。SPSは、TE LSPのシグナル伝達中に境界で二国間または多国間協定を強制するために依然としてポリシー管理を必要とする場合がありますが、この文書のシグナリングは範囲外ではありません。
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 Inter-AS PCEは、PATH計算要求を隣接するAS PCEに送信し、そのようなリクエストを受信するPCE間のPCEは、リクエストの送信者に適用されるポリシーを強制します。これらのポリシーには、パラメーターの一部を書き換えたり、パラメーター値に基づいてリクエストを拒否したりすることが含まれます。このようなポリシーは、異なるSPSに属するPCEまたは単一のSP管理ドメイン内のASEの原因となるPCEに適用される場合があります。ポリシーの対象となる可能性のあるパラメーターには、帯域幅、セットアップ/保持優先度、高速リルートリクエスト、差別化されたサービストラフィックエンジニアリング（DS-TE）クラスタイプ（CT）、および[RFC4216]のセクション5.2.2.1で指定されているものが含まれます。
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は、特定のパラメーターがローカルポリシーを満たさなかったために要求が拒否されたことを示すPCCまたはPCCの要求にエラーメッセージを送信できるようにする必要があります。
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クラスの使用に異なる定義を持っている場合があります。パス計算要求を受信するPCE間のPCEは、パラメーターと制約を解釈し、それらをローカル環境に適応させる必要があります。具体的には、PCCまたはPCEによって作成されたリクエストは、異なる方法で解釈するか、または異なるASにある受信PCEによって翻訳されるパラメーターと制約を持つ場合があります。AS境界でのポリシーの再解釈に従う信号パラメーターのリストは、[RFC4216]のセクション5.2.2.2に記載されており、パス計算要求パラメーターと制約のリストは同じです。さらに、TETEパスに沿ったトランジットSPは、GMPLSネットワークまたはその逆のパス計算を有効にするために、MPLS固有のPCECPパス計算要求オブジェクトの再解釈が必要になる場合があります。
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 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は、IPネットワークを介して潜在的にリモートエンティティ（PCCSおよびPCES）間で使用するための通信プロトコルです。PCC、PCE、およびそれらが交換する情報を保護するために、セキュリティの懸念が生じます。[RFC4758]は、PCECPの要件を指定して、スプーフィング、スヌーピング、およびDOS攻撃から保護します。そのドキュメントは、PCECPの基本的な使用に適用される一般的なプロトコル要件に関係しています。このドキュメントは、AS Inter-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の場合に重要になります。
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スピーカーには、互いのアイデンティティを認証し、交換するデータを検証するメカニズムが必要です。また、暗号化を介して交換するデータを保護するメカニズムも必要です。このようなメカニズムは通常、キーの使用を必要とするため、PCECPはセキュリティキーの交換と使用の手法を説明する必要があります。AS Inter-AS PCE発見が使用され、PCECPセキュリティが必要な場合、自動化された主要な分布メカニズムも使用する必要があります。このような重要な交換は、境界として（必然的に）境界を越えて動作する必要があるため、主要な交換がどのように実行されるか、およびキーエクスチェンジ自体がどのように保護されるかを適切に考慮する必要があります。[RFC4107]を考慮して、主要な分布メカニズムを定義する必要があります。PCECPセッションがPCES間のペア間で構成されている場合、そのセッションにセキュリティキーを手動で設定することができます。
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].
ポリシーは、特にASEが異なるSPSによって管理されている場合、セクション4.5で説明されているように、AS間の環境でPCESの操作の重要な部分を形成します。PCEアーキテクチャへのポリシーの適用に関するより広範な議論は、[PCE-Policy]にあります。
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 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のセキュリティモデルの一部を形成する場合があり、特にAS Inter-AS Path計算要求に適用できる場合があります。PCEでのポリシーの適用の基本的な要素は、要求するPCC/PCEのアイデンティティです。これにより、セクション5.1で説明されている認証の使用が特に重要になります。ポリシー情報が計算要求および/または応答の一部として交換される場合、ポリシーオブジェクトは、PCEまたはPCCのポリシーコンポーネントに対して、検査されずに提供されていないPCECPに対して透明です。したがって、ポリシーコンポーネントは、PCECPの基本プロトコル要素によって提供されるよりも高いレベルの検証が必要な場合、ポリシー情報を保護し（たとえば暗号化）、追加の識別と認証を使用する責任があります。
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は、PCEによって計算されたパスセグメントの機密性をASで計算し、別の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には、同一性をマスクするメカニズムを提供する必要があります。これにより、協同組合PCEモデル（[BRPC]に記載されているなど）が計算されたパスから導出できないパス計算チェーンに存在するようになります。これは、ターゲット攻撃からPCEを保護するのに役立ちます。明らかに、そのような機密性は、PATH計算要求でPCEを呼び出すPCECPピア（つまり、PCCまたはPCCまたは別のPCE）にまで及ぶことはありません。
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が協力すると、1つのPCEが複数のパスセグメントで構成されるパス計算結果を返す場合があります。それぞれが異なるPCEで計算されます。Inter-ASの場合、各PCEは異なる管理ドメインに属し、ソースPCCが下流のPCEについて知らないことも、それらを完全に信頼することもありません。PCE間で信頼の連鎖を確立することが可能であり、推奨されていますが、これは必ずしも可能であるとは限りません。この場合、別の下流のPCEが提供する情報を変更するPCEを防ぐことが必要になります。一部のメカニズムはPCECPで利用可能でなければならず、対応するシグナル伝達に反映される必要があります。これにより、信号されたパスがローカルPCEによって計算され、パス計算リクエストで返されるパスセグメントに適合していることを確認できます。
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.
エイドリアン・ファレル、ジャン・フィリップ・ヴァスザー、ジャン・ルイ・ル・ルーの有用なコメントと提案に感謝します。Pasi EronenとSandy Murphyは、貴重な早期セキュリティ局のレビューを提供しました。Adrian Farrelは、セキュリティ上の考慮事項セクションを書き直しました。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107] Bellovin、S。およびR. Housley、「暗号化キー管理のためのガイドライン」、BCP 107、RFC 4107、2005年6月。
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216] Zhang、R.、ed。、およびJ.-P。Vasseur、ed。、「MPLS Inter-autonomous System（AS）Traffic Engineering（TE）要件」、RFC 4216、2005年11月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657] Ash、J.、ed。、およびJ. Le Roux、ed。、「Path Computation Element（PCE）通信プロトコルジェネリック要件」、RFC 4657、2006年9月。
[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。、Zhang、R.、Bitar、N。、およびJl。Le Roux、「最短制約されたドメイン間トラフィックエンジニアリングラベルの切り替えパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、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）階層」、RFC 4206、2005年10月。
[RFC4758] Nystroem, M., "Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1", RFC 4758, November 2006.
[RFC4758] Nystroem、M。、「暗号化トークンキー初期化プロトコル（CT-KIP）バージョン1.0リビジョン1」、RFC 4758、2006年11月。
[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. Farrel、「一般化されたマルチプロトコルラベルスイッチングトラフィックエンジニアリング（GMPLS TE）を使用したラベルスイッチパスステッチ」、RFC 5150、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] Farrel、A.、ed。、Ayyangar、A。、およびJp。Vasseur、「ドメイン間MPLSおよびGMPLSトラフィックエンジニアリング - リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 5151、2008年2月。
[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。、ed。、Ayyangar、A.、ed。、およびR. Zhang、「ドメイン間トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）を確立するためのドメインごとのパス計算方法」、RFC 5152、2008年2月。
[PCE-POLICY] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", Work in Progress, October 2007.
[PCE-Policy] Bryskin、I.、Papadimitriou、D.、Berger、L。、およびJ. Ash、「ポリシー対応パス計算フレームワーク」、2007年10月、作業進行中。
Authors' Addresses
著者のアドレス
Nabil Bitar Verizon 117 West Street Waltham, MA 02451 USA EMail: nabil.n.bitar@verizon.com
Nabil Bitar Verizon 117 West Street Waltham、MA 02451 USAメール：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
Kenji Kumaki Kddi R＆D Laboratories、Inc。2-1-15 Ohara Fujimino Saitama 356-8502、日本メール：ke-kumaki@kddi.com
Raymond Zhang BT 2160 E. Grand Ave. El Segundo, CA 90245 USA EMail: Raymond.zhang@bt.com
Raymond Zhang BT 2160 E. Grand Ave. El Segundo、CA 90245 USAメール：raymond.zhang@bt.com