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)
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.
著作権（C）2008 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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）はパス計算クライアント（のPCC）とのPCEの間、同様のPCE間の通信を許可するように定義されています。 PCECPは制約のパスを要求することに応答して計算されたパスを供給するために使用されます。 PCECPのための一般的な要件は、この文書は、相互AS MPLS TEの支援でPCECPの使用をカバーするために、これらの要件を拡張し、「経路計算エレメント（PCE）通信プロトコルジェネリック要件」、RFC 4657.に記載されています。
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]はトラフィックエンジニアリング（MPLS TE）を切り替える間ASマルチプロトコルラベルの展開をやる気にシナリオを定義してのASは1つのサービスプロバイダ（SP）または投与の投与を受けているとき、インター-AS MPLS TEのための要求事項を規定します異なるSP。
Three signaling options are defined for setting up an inter-AS TE Label Switched Path (LSP):
三つのシグナリングオプションは相互AS TEラベルスイッチパス（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].
[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によれば、最小コストを有するものである複数のASを横断最適制約パスを保証しません）メトリックLSP TE制約を満たすすべての可能なパスのうちの各トランジットAS）で採用されています。
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.
経路計算エレメント（PCE）[RFC4655]はプロトコル（（G）MPLS TE）LSPをスイッチングMPLS TEと一般化マルチプロトコルラベルのパスを計算することができる成分です。 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）はパス計算クライアント（のPCC）とのPCEの間、とするPCE間の通信を許可するように定義されています。 PCECPは、（G）MPLS TEパスを要求することに応答して計算されたパスを供給するために使用されます。 PCECPための一般的な要件は、[RFC4657]に記載されています。この文書は、インターAS（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.
インター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.
イントラ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.
イントラASのPCE：単一のAS内の残りの（G）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.
AS間のPCE：インターAS（G）MPLSパス又は経路セグメントを計算する責任PCE、おそらくはイントラASの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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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アプリケーションでのPCEのための参照モデルを示します。 AS間のPCEと、イントラASのPCE：私たちは、この文書のPCEの2種類の機能を参照してください。イントラASののPCEがイントラAS（G）MPLS TEパス計算のために必要な機能を実行しながら、AS間のPCEは、インター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
<==AS1==> <=====AS2=====> <====AS3====>
<== S 1 ==> <==== ====大> <===== =====虐待を受けました>
Figure 1: Inter- and Intra-AS PCE Reference Model
図1：インターとイントラ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.
AS1に図1 R1に示すように一定の制約を、LSP1それを呼び出す、（G）MPLS TEパス設定に望んでいる、のはのPCCの間の相互作用を示したシナリオに従ってみましょう、AS間のPCE、イントラASののPCE AS3でR7。 R1は、R7は、AS間の経路であり、R1（自体）が経路を計算するために、そのインターAS PCE1に連絡する必要があることは、この文書の範囲外の機構を使用して、決定します。 R1は、PCCとして、PCE1にPCECPパス計算要求を送信します。 PCE1は、R7は、AS2を経由して到達可能であると判断し、PCE2は、AS2間で経路計算を依頼するPCEがあること。 PCE1は、PCE2にPCECPの経路計算要求を送信します。インターAS PCE2は、今度は、AS2内経路を計算するためにイントラAS PCE R4にPCECPパス計算要求を送信する（ある場合には、例えばR3と同じルータは、インターASとイントラAS経路計算機能の両方をとることができます）。 R4は、例えば、AS3への出口点としてAS1及びASBR7からAS2へのエントリポイントとしてASBR3とPCE2にPCECPパス計算応答を返すことができます。 PCE2は、その後ASBR7で開始しR7で終端する、AS3を横切る経路セグメントを計算するPCE3にPCECPパス計算要求を送信します。 PCE3は、パスセグメントASBR7-R7とPCE2にPCECPパス計算応答を返します。 PCE2は、その後順番に、PCC R1にパスASBR1-ASBR3- ASBR5-ASBR7-R7を返し、PCE1、パスASBR3- ASBR5-ASBR7-R7を返します。
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は、経路自体を供給することができるか、それ自体がAS間のPCEであってもよいし、ただ一つのAS内のパスセグメントを計算するための責任を持つイントラASとのPCEであってもよい、他のPCEのサービスを求めることができます。
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.
この文書では、すなわち、のPCEにインターAS（G）MPLS TEパスの経路計算要求を通信するためのPCCのために、及びのPCEは、応答するため、AS間の経路計算のためのPCE通信プロトコルの要件を記載しています。また、AS間経路計算要求と応答を通信するためのPCEのための要件が含まれています。
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.
ほとんどの、すべてではない場合は、インターAS PCECPベースの通信は、[RFC4655]に記載の協調PCEモデルで動作するのPCEの間であることが期待されます。明らかに、このモデルでは、要求元のPCEは、経路計算要求を発行する目的のためにPCCとして作用するが、それにもかかわらず、要求ノードは、独自のASにおけるPCEのより広い役割を満たします。現時点では、（例えば、ルータを切り替え、通常のラベル）PCCは、自身のAS外部のPCEへの経路計算要求を行う可能性は低いと考えられています。これは、AS間PCECP関係が最大でN乗（N ^ 2）、nは種々のAS（大きくない[RFC4657]に100よりもないと考えられる）でのPCEのピアリングの数であるに限定されることを意味します。しかし、実際には、1 ASで唯一の少数のPCEは、隣接ASでのPCEでPCECP通信用に指定される可能性があり、これらの各々は唯一の中から選択するように、隣接のいくつかののPCEを持つことになります。展開モデルは、PCE-PCE関係の管理可能なスケーリングが得られ、ASBRはとの共存などの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要件について説明します。デプロイメント環境によっては、ここで説明した要件の一部または全てを利用することができます。具体的には、いくつかの要件は、イントラプロバイダー操作に比べ間プロバイダ間AS（G）MPLS TE操作に対してより適用可能です。
Requirements specific to inter-AS PCECP path computation requests and responses are discussed in the following sections.
AS間PCECP経路計算要求と応答に固有の要件は、次のセクションで説明されています。
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.
AS間PCEまたは別のAS間PCEにPCC 2.経路計算要求は、所望の経路におけるホップとしてのASBR及び/又はのASを提供することによって、のASおよび/またはネットワーク全体のASBRの順序を指定できなければなりません目的地へのTE LSPの。例えば、インターAS PCEは、そのASに出るための好ましいASBR AS隣接サービングインターAS PCEに指定して目的地に到達できなければなりません。すなわち、複数のASBRが存在する場合、リクエスタはそれらのいずれかの好みを示すことができなければなりません。 PCEは、指定されたASBRまたはASは、（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は、リクエスタがのASおよび/または計算された経路から除外されるの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.
第2層間ASのPCEでローカルポリシーの正確な適用を可能にするため4.別のAS間PCEからPCECP経路計算要求は、要求の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.
1：5の間ASのPCEまたは別のAS間PCEへPCCから経路計算要求は1を使用して、ノード、リンク、または共有リスクリンクグループ（SRLG）障害に対する保護の必要性を指定することができなければなりません迂回路や施設のバックアップ。すべてのAS間で、または特定のAS間での保護を要求することが可能でなければなりません。
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.
[RFC4657]で指定されるように6 PCECPは独立経路要件をサポートしなければなりません。また、2つ以上のパスのセットを計算するための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. A PCECP経路計算要求メッセージは、エンドツーエンド（すなわち、（G）MPLS TEトンネルのエンドポイントとの間）であること、またはAS特定に限定されることは多様な経路計算の範囲を特定できなければなりません。
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.
別のAS間PCEから1 A PCECP経路計算応答は、経路セグメントおよびトポロジの機密性を維持しながら、計算された経路の両方のASBRとのASを含むことができなければなりません。
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.
要求間AS PCEに1 AS間PCEから2 A PCECP経路計算応答は、経路セグメントおよびトポロジの機密性を維持するために計算するパスセグメントの識別子を運ぶことができなければなりません。識別子の目的は、その機構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.所望の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.要求AS間PCEまたはPCCにAS間PCEからPCECP経路計算応答が累積AS間の経路コストを運ぶことができなければなりません。 AS間の経路コストの正規化は、この文書の範囲外です。
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.
AS間のPCEからPCCへ5. A PCECP経路計算応答は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. A PCECPパス計算応答が同じ（G）MPLS TE LSPのための多様な経路を識別できなければなりません。エンド・ツー・エンド（すなわち、（G）MPLS TEトンネルの2つのエンドポイント間の）ディスジョイントパスLSPのヘッドエンドとテールエンドを除いて、ノード、リンク、またはSRLGsを共有しない経路です。多様な経路セグメントは、1つの以上のAS内の所望される場合には、独立経路セグメントは、最初のASのASBRは、これらのASを横断AS最後のASBRのみを共有することができます。
PCECP design for use in the inter-AS case SHOULD consider the following criteria:
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メッセージ処理負荷。 - 以下のパラメータの関数としてのスケーラビリティ：AS間のピアリング相互当たりのPCEの間AS PCEのO番号の範囲内のイントラAS用のPCEの間AS PCEのO番号の範囲内のPCCの入出力数AS間の機能によって引き起こさ追加しました複雑 - PCE AS。
[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はまたは、機密性、およびポリシーを伝達されませんする先のASに隣接するインター-AS PCE、AS間の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間のPCEを横切って、すなわち）基準として隣接する上でこれらの統計を分析することができなければなりません。
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.
しきい値を超えたとき、または[RFC4657]に記載されているように、重要なイベントが発生したときにMIBモジュールは、トラップ機能をサポートしなければなりません。これらのしきい値は、AS間PCE隣人あたりASだけでなく、ピアごとの指定可能であるべきであり、トラップはそれに応じて生成されるべきです。
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オブジェクトを提供することによって、活気チェック動作の制御を可能にするべきであり、この周波数オブジェクトは、AS間のPCEピアごとに指定されるべきです。また、全く活気メッセージがAS間PCEからその時間内に受信されない場合、インターAS PCEが到達不能と宣言されるように活気メッセージ周波数の乗数としてデッド間隔を指定するMIBオブジェクトが存在すべきです。
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が所有しているのAS間で適用される場合があります。各SPは、ほとんどの場合、独自の管理ドメイン内インターAS（G）MPLS TEパス計算のためのいくつかのPCEおよびインタープロバイダインターAS（G）MPLS TEパス計算のためのいくつかの他のPCEを指定します。各SPドメイン内のインタープロバイダスコープAS間のPCEのうち、さらに具体的に異なるピアのSPののASの特定のセットを横切って経路計算のために有効のPCEのサブセットであってもよいです。
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は、他のSPからインターAS間プロバイダTE LSP（C.F.、[RFC4216]のセクション5.2.1）が横断している独自のAS内のホップのセットを非表示にできるようにしなければなりません。マルチSP管理ドメイン環境では、SPはセキュリティや商業的な理由のために彼らのネットワークトポロジを非表示にすることがあります。したがって、インターAS PCEが計算した各インターAS TE LSPパスセグメントには、明示的なイントラASホップ詳述することなく、要求間AS PCEに独自のASからインターAS TE LSPパスセグメントを返すことができます。先に述べたように、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境界で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に記載されているものと類似しているそれらのポリシー制御要件について説明します。 SPはまだ境界ASで二国間または多国間協定を施行するために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間PCEは、その近隣のAS間のPCEへの経路計算要求を送信し、そのような要求を受けたAS間のPCEは、リクエストの送信者に適用されるポリシーを適用します。これらのポリシーは、パラメータの一部を書き換えやパラメータ値に基づいて要求を拒否挙げられます。このようなポリシーが異なるSPまたはシングルSP管理ドメイン内のASの責任のPCEに属するのPCEに適用することができます。 [RFC4216]のセクション5.2.2.1で指定されたポリシーの対象となる可能性があるパラメータは、帯域幅、セットアップ/優先順位を保持し、高速リルート要求、差別化サービストラフィックエンジニアリング（DS-TE）クラスタイプ（CT）、および他の人が含まれます。
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やPCEにエラーメッセージを送信するために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は、パラメータや制約を解釈し、ローカル環境にそれらを適応させる必要があります。具体的には、一ASにおけるPCC又はPCEによって構築要求は、別のASにある受信PCEによって異なって解釈又は翻訳されるべきパラメータおよび制約を有していてもよいです。 AS境界におけるポリシー再解釈の対象パラメータをシグナリングするリストには、[RFC4216]のセクション5.2.2.2に見出すことができ、経路計算リクエストパラメータおよび制約のリストは同じです。また、インターAS TE経路に沿って通過SPはGMPLSネットワークまたはその逆上の経路計算を可能にするために、MPLS-特定PCECPパス計算要求オブジェクトの再解釈を必要とするかもしれないGMPLSトランスポートプロバイダであってもよいです。
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ネットワークを介して潜在的に遠隔のエンティティ（のPCCとのPCE）との間の使用のための通信プロトコルです。セキュリティ上の懸念はPCC、PCE、と彼らは交換した情報を保護するために発生します。 [RFC4758]は、なりすまし、スヌーピング、およびDoS攻撃から保護するためにPCECP上の要件を指定します。その文書は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ケースで重要になります。
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間PCEの発見が使用され、PCECPのセキュリティが必要な場合は、自動化されたキー配布メカニズムも使用しなければなりません。このような鍵交換は（必ずしも）AS境界にわたって動作しなければならないので、適切な考慮事項は、鍵交換を行うことができ、鍵交換が、それ自体が、どのように固定することができる方法インターASに与えられる必要があります。鍵配布メカニズムは[RFC4107]を考慮して定義されなければなりません。 PCECPセッションがAS間のPCEの対の間に構成されている場合、セキュリティキーは、手動でそのセッションのために設定されてもよいです。
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が異なるSPにより管理されている場合は特に、AS間の環境でのPCEの動作の重要な部分を形成します。 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経路計算要求に特に適用することができます。 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一ASで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は、（[BRPC]に記載されているような）協調PCEモデルにおける経路計算鎖中のその存在は、計算された経路に由来することができないように、そのIDをマスクするために機構が提供されるべきです。これは、標的型攻撃からPCEを保護するのに役立ちます。明らかに、そのような機密性が経路計算要求にPCEを起動PCECPピア（すなわち、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は、協働するときPCEアーキテクチャでは、1つのPCEはそれぞれ異なるPCEによって計算され、複数のパスセグメントから構成されている経路計算結果を返すことができます。 AS間の場合、各PCEは異なる管理ドメインに属していてもよい、とソースPCCは、下流のPCEを知って、またこれらを完全に信頼していない可能性があります。それは可能とのPCE間の信頼の連鎖を確立することをお勧めしますが、これは常に可能ではないかもしれません。この場合には、別の下流PCEによって提供される情報を変更するPCEを防ぐことが必要となります。いくつかのメカニズムがPCECPで利用できるように、対応するシグナリングにエコーなければならないことは、ASがシグナリングパスがローカル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.
私たちは、彼らの役に立つコメントと提案のためのエードリアンファレル、ジャン=フィリップVasseur、そしてジャン・ルイ・ル・ルーに感謝したいと思います。パシEronenとサンディマーフィーは、貴重な初期のセキュリティ総局のレビューを提供します。エードリアンファレルは、Security Considerations部を再度書きました。
[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]張、R.、編、及びJ.-P. Vasseur、エド。、 "MPLSインター自律システム（AS）トラフィックエンジニアリング（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]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（PCE）ベースのアーキテクチャ"、RFC 4655、2006年8月。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657]アッシュ、J.、エド。、およびJ.ル・ルー、エド。、 "パス計算要素（PCE）通信プロトコルジェネリック要件"、RFC 4657、2006年9月。
[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.、ビタール、N.、およびJL。ル・ルー、「最短拘束インタードメイントラフィックエンジニアリングラベルスイッチパスを計算するために、後方再帰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は、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[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.ファレルは、2008年2月、RFC 5150 "ラベルは、トラフィックエンジニアリング（TE GMPLS）をスイッチング汎用マルチプロトコルラベルとステッチスイッチパス"。
[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）"、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。、エド。、Ayyangar、A.編、およびR.張は、 "ドメイン単位の経路計算方法のために確立するドメイン間トラフィックエンジニアリング（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.、バーガー、L.、およびJ.アッシュ、 "政策対応の経路計算フレームワーク"、進歩、2007年10月の作業。
Authors' Addresses
著者のアドレス
Nabil Bitar Verizon 117 West Street Waltham, MA 02451 USA EMail: nabil.n.bitar@verizon.com
ナビル・ビタールベライゾン117西ストリートウォルサム、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
けんじ くまき Ｋっぢ Ｒ＆Ｄ ぁぼらとりえｓ、 いんｃ。 ２ー１ー１５ おはら ふじみの さいたま ３５６ー８５０２、 じゃぱん えまいｌ： けーくまき＠ｋっぢ。こｍ
Raymond Zhang BT 2160 E. Grand Ave. El Segundo, CA 90245 USA EMail: Raymond.zhang@bt.com
レイモンド・チャンBT 2160 E.グランドアベニューエル・セグンド、CA 90245 USA電子メール：Raymond.zhang@bt.com