[要約] RFC 6882は、レイヤー3仮想プライベートネットワーク（L3VPN）でのリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）のサポートに関するものです。このRFCの目的は、L3VPN環境でRSVP-TEを使用してトラフィックエンジニアリングを実現するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) K. Kumaki, Ed.
Request for Comments: 6882 KDDI Corporation
Category: Experimental T. Murai
ISSN: 2070-1721 Furukawa Network Solution Corp.
D. Cheng
Huawei Technologies
S. Matsushima
Softbank Telecom
P. Jiang
KDDI Corporation
March 2013
Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs)
レイヤー3バーチャルプライベートネットワーク（L3VPN）でのリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）のサポート
Abstract
概要
IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS, and a single Provider Edge (PE) node may provide access to multiple customer sites belonging to different VPNs.
IP仮想プライベートネットワーク（VPN）は、IP / MPLSバックボーンを介したサイト間の接続を提供します。これらのVPNはBGP / MPLSを使用して操作でき、単一のプロバイダーエッジ（PE）ノードは、異なるVPNに属する複数の顧客サイトへのアクセスを提供できます。
The VPNs may support a number of customer services, including RSVP and Resource Reservation Protocol Traffic Engineering (RSVP-TE) traffic. This document describes how to support RSVP-TE between customer sites when a single PE supports multiple VPNs and labels are not used to identify VPNs between PEs.
VPNは、RSVPおよびリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）トラフィックを含む、多くのカスタマーサービスをサポートします。このドキュメントでは、単一のPEが複数のVPNをサポートし、PE間のVPNの識別にラベルが使用されていない場合に、カスタマーサイト間でRSVP-TEをサポートする方法について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6882.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6882で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions ................................................3
2. Motivation ......................................................4
2.1. Network Example ............................................4
3. Protocol Extensions and Procedures ..............................5
3.1. Object Definitions .........................................5
3.1.1. LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6
SESSION Object ......................................6
3.1.2. LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6
SENDER_TEMPLATE .....................................7
3.1.3. LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6
FILTER_SPEC Objects .................................9
3.1.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP Objects ..............9
3.2. Handling the Messages ......................................9
3.2.1. Path Message Processing at the Ingress PE ...........9
3.2.2. Path Message Processing at the Egress PE ...........10
3.2.3. Resv Processing at the Egress PE ...................11
3.2.4. Resv Processing at the Ingress PE ..................11
3.2.5. Other RSVP Messages ................................12
4. Management Considerations ......................................12
4.1. Impact on Network Operation ...............................12
5. Security Considerations ........................................13
6. References .....................................................13
6.1. Normative References ......................................13
6.2. Informative References ....................................13
7. Acknowledgments ................................................14
8. Contributors ...................................................14
Service Providers would like to use BGP/MPLS IP VPNs [RFC4364] to support connections between Customer Edge (CE) sites. As described in [RFC5824], these connections can be MPLS Traffic Engineered (TE) Label Switched Paths (LSPs) established using extensions to RSVP [RFC3209] for a number of different deployment scenarios. The requirements for supporting MPLS-TE LSP connections across BGP/MPLS IP VPNs are documented in [RFC5824].
サービスプロバイダーは、BGP / MPLS IP VPN [RFC4364]を使用して、カスタマーエッジ（CE）サイト間の接続をサポートしたいと考えています。 [RFC5824]で説明されているように、これらの接続は、RSVP [RFC3209]の拡張機能を使用して確立されたMPLSトラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）であり、さまざまな展開シナリオに対応します。 BGP / MPLS IP VPNを介したMPLS-TE LSP接続をサポートするための要件は、[RFC5824]で文書化されています。
In order to establish a customer MPLS-TE LSP over a BGP/MPLS IP VPN, it is necessary for the RSVP-TE control messages, including the Path and Resv messages described in [RFC3209], to be handled appropriately by the Provider Edge (PE) routers. [RFC4364] allows RSVP messages sent within a VPN's context to be handled just like any other VPN data. In such a solution, the RSVP-TE component at a PE that sends messages toward a remote PE must process the messages in the context of the VPN and must ensure that the messages are correctly labeled. Similarly, when a message sent across the core is received by a PE, both labels must indicate the correct VPN context.
BGP / MPLS IP VPNを介してカスタマーMPLS-TE LSPを確立するには、[RFC3209]で説明されているPathおよびResvメッセージを含むRSVP-TE制御メッセージがプロバイダーエッジで適切に処理される必要があります（ PE）ルーター。 [RFC4364]を使用すると、VPNのコンテキスト内で送信されるRSVPメッセージを他のVPNデータと同じように処理できます。このようなソリューションでは、リモートPEにメッセージを送信するPEのRSVP-TEコンポーネントは、VPNのコンテキストでメッセージを処理し、メッセージに正しくラベルが付けられていることを確認する必要があります。同様に、コアを介して送信されたメッセージがPEによって受信された場合、両方のラベルが正しいVPNコンテキストを示す必要があります。
Implementation of the standards-based solution described in the previous paragraph is possible, but requires proper support on the PE. In particular, a PE must be able to process RSVP messages within the context of the appropriate VPN Routing and Forwarding (VRF). This may be easy to achieve in some implementations, but in others, it is not so easy.
前の段落で説明した標準ベースのソリューションの実装は可能ですが、PEでの適切なサポートが必要です。特に、PEは適切なVPNルーティングおよび転送（VRF）のコンテキスト内でRSVPメッセージを処理できる必要があります。これは、一部の実装では簡単に実現できますが、他の実装ではそれほど簡単ではありません。
This document defines experimental formats and mechanisms that follow a different approach. The documented approach enables the VPN identifier to be carried in the RSVP-TE protocol message so that there is no requirement for label-based VRF identification on the PE.
このドキュメントでは、異なるアプローチに従う実験的なフォーマットとメカニズムを定義します。文書化されたアプローチにより、VPN識別子をRSVP-TEプロトコルメッセージで伝送できるため、PEでラベルベースのVRF識別が不要になります。
The experiment proposed by this document does not negate the label-based approach supported by [RFC4364]. The experiment is intended to enable research into alternate methods of supporting RSVP-TE within VPNs.
このドキュメントで提案されている実験は、[RFC4364]でサポートされているラベルベースのアプローチを否定するものではありません。この実験は、VPN内でRSVP-TEをサポートする別の方法を研究できるようにすることを目的としています。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
If multiple BGP/MPLS IP VPNs are supported at the same PE, new RSVP-TE extensions are required so that RSVP-TE control messages from the CEs can be handled appropriately by the PE.
同じPEで複数のBGP / MPLS IP VPNがサポートされている場合、CEからのRSVP-TE制御メッセージをPEが適切に処理できるように、新しいRSVP-TE拡張が必要です。
Figure 1 ("Customer MPLS TE LSPs in the context of BGP/MPLS IP VPNs") shows two VPNs supported by a core IP/MPLS network. Both VPNs have customer sites on the two PEs shown in the figure. The customer sites operate MPLS-TE LSPs.
図1（「BGP / MPLS IP VPNのコンテキストでのカスタマーMPLS TE LSP」）は、コアIP / MPLSネットワークでサポートされる2つのVPNを示しています。図に示すように、両方のVPNの2つのPEにカスタマーサイトがあります。カスタマーサイトはMPLS-TE LSPを運用しています。
Here, we make the following set of assumptions:
ここでは、以下の一連の仮定を行います。
o VPN1 and VPN2 are for different customers. o CE1 and CE3 are head-end routers. o CE2 and CE4 are tail-end routers. o The same address (e.g., 192.0.2.1) is assigned at CE2 and CE4.
o VPN1とVPN2は異なる顧客向けです。 o CE1およびCE3はヘッドエンドルーターです。 o CE2およびCE4はテールエンドルーターです。 o同じアドレス（192.0.2.1など）がCE2とCE4に割り当てられています。
<--------Customer MPLS-TE LSP for VPN1-------->
....... .......
. --- . --- --- --- --- . --- .
.|CE1|----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2|.
. --- . --- --- --- --- . --- .
....... | | .......
(VPN1) | | (VPN1)
| |
....... | | .......
. --- . | | . --- .
.|CE3|------+ +-------|CE4|.
. --- . . --- .
....... .......
(VPN2) (VPN2)
<--------Customer MPLS-TE LSP for VPN2-------->
^ ^
| |
VRF instance VRF instance
<-Customer-> <---BGP/MPLS IP VPN---> <-Customer->
network network
Figure 1: Customer MPLS TE LSPs in the context of BGP/MPLS IP VPNs Consider that customers in VPN1 and VPN2 would like to establish customer MPLS-TE LSPs between their sites (i.e., between CE1 and CE2, and between CE3 and CE4). In this situation, the following RSVP-TE Path messages would be sent:
図1：BGP / MPLS IP VPNのコンテキストでのカスタマーMPLS TE LSP VPN1とVPN2のカスタマーがサイト間（つまり、CE1とCE2の間、およびCE3とCE4の間）にカスタマーMPLS-TE LSPを確立したいと考えていることを考慮してください。この状況では、次のRSVP-TEパスメッセージが送信されます。
1. CE1 would send a Path message to PE1 to establish the MPLS-TE LSP (VPN1) between CE1 and CE2.
1. CE1は、パスメッセージをPE1に送信して、CE1とCE2の間にMPLS-TE LSP（VPN1）を確立します。
2. CE3 would also send a Path message to PE1 to establish the MPLS-TE LSP (VPN2) between CE1 and CE2.
2. CE3はまた、パスメッセージをPE1に送信して、CE1とCE2の間にMPLS-TE LSP（VPN2）を確立します。
After receiving each Path message, PE1 can identify the customer context for each Path message from the incoming interface over which the message was received. PE1 forwards the messages to PE2 using the routing mechanisms described in [RFC4364] and [RFC4659].
各パスメッセージを受信した後、PE1は、メッセージが受信された着信インターフェイスから各パスメッセージのカスタマーコンテキストを識別できます。 PE1は、[RFC4364]および[RFC4659]で説明されているルーティングメカニズムを使用して、メッセージをPE2に転送します。
When the Path messages are received at PE2, that node needs to distinguish the messages and determine which applies to VPN1 and which to VPN2 so that the right forwarding state can be established and so that the messages can be passed on to the correct CE. Although the messages arrive at PE2 with an MPLS label that identifies the VPN, the messages are delivered to the RSVP-TE component on PE2, and the context of the core VPN LSP (i.e., the label) is lost. Some RSVP-TE protocol mechanism is therefore needed to embed the VPN identifier within the RSVP-TE message.
PathメッセージがPE2で受信されると、そのノードはメッセージを区別し、VPN1とVPN2のどちらに適用するかを決定して、正しい転送状態を確立し、メッセージを正しいCEに渡すことができるようにする必要があります。メッセージは、VPNを識別するMPLSラベルと共にPE2に到着しますが、メッセージはPE2のRSVP-TEコンポーネントに配信され、コアVPN LSP（つまり、ラベル）のコンテキストは失われます。したがって、RSVP-TEメッセージ内にVPN識別子を埋め込むには、RSVP-TEプロトコルメカニズムが必要です。
Similarly, Resv messages sent from PE2 to PE1 need an RSVP-TE mechanism to assign them to the correct VPN.
同様に、PE2からPE1に送信されるResvメッセージには、正しいVPNにメッセージを割り当てるためのRSVP-TEメカニズムが必要です。
This section defines the additional RSVP-TE objects to meet the requirements described in Section 2. These objects are new variants of the SESSION, SENDER_TEMPLATE, and FILTERSPEC objects. They act as identifiers and allow PEs to distinguish Path/Resv messages per VPN in the context of BGP/MPLS IP VPNs. Section 3.1 defines the new object types, and Section 3.2 defines the specific procedures for handling RSVP messages.
このセクションでは、セクション2で説明した要件を満たすための追加のRSVP-TEオブジェクトを定義します。これらのオブジェクトは、SESSION、SENDER_TEMPLATE、およびFILTERSPECオブジェクトの新しいバリアントです。それらは識別子として機能し、PEがBGP / MPLS IP VPNのコンテキストでVPNごとにPath / Resvメッセージを区別できるようにします。セクション3.1は新しいオブジェクトタイプを定義し、セクション3.2はRSVPメッセージを処理するための特定の手順を定義します。
This experiment will be carried out using the following private Class Types. This document identifies these Class Types as "C-Type = EXPn".
この実験は、次のプライベートクラスタイプを使用して実行されます。このドキュメントでは、これらのクラスタイプを「Cタイプ= EXPn」として識別します。
Class = SESSION, LSP_TUNNEL_VPN-IPv4 C-Type = EXP1
Class = SESSION, LSP_TUNNEL_VPN-IPv6 C-Type = EXP2
Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv4 C-Type = EXP3
Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv6 C-Type = EXP4
Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv4 C-Type = EXP5
Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv6 C-Type = EXP6
The LSP_TUNNEL_VPN-IPv4 (or LSP_TUNNEL_VPN-IPv6) SESSION object appears in RSVP-TE messages that ordinarily contain a SESSION object and that are sent between the ingress PE and egress PE in either direction. This object MUST NOT be included in any RSVP-TE message that is sent outside of the provider's backbone.
LSP_TUNNEL_VPN-IPv4（またはLSP_TUNNEL_VPN-IPv6）SESSIONオブジェクトは、通常SESSIONオブジェクトを含み、入力PEと出力PEの間でいずれかの方向に送信されるRSVP-TEメッセージに表示されます。このオブジェクトは、プロバイダーのバックボーンの外部に送信されるRSVP-TEメッセージに含まれていてはなりません（MUST NOT）。
The LSP_TUNNEL_VPN-IPv6 SESSION object is analogous to the LSP_TUNNEL_VPN-IPv4 SESSION object, using a VPN-IPv6 address ([RFC4659]) instead of a VPN-IPv4 address ([RFC4364]).
LSP TUNNEL VPN-IPv6 SESSIONオブジェクトは、VPN-IPv4アドレス（[RFC4364]）の代わりにVPN-IPv6アドレス（[RFC4659]）を使用するLSP TUNNEL VPN-IPv4 SESSIONオブジェクトに類似しています。
Experimenters MUST ensure that there is no conflict between the private Class Types used for this experiment and other Class Types used by the PEs.
実験者は、この実験で使用されるプライベートクラスタイプとPEで使用される他のクラスタイプの間に競合がないことを確認する必要があります。
The formats of the SESSION objects are as follows:
SESSIONオブジェクトのフォーマットは次のとおりです。
Class = SESSION, LSP_TUNNEL_VPN-IPv4 C-Type = EXP1
クラス= SESSION、LSP_TUNNEL_VPN-IPv4 Cタイプ= EXP1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| VPN-IPv4 Tunnel Endpoint Address (12 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class = SESSION, LSP_TUNNEL_VPN-IPv6 C-Type = EXP2
クラス= SESSION、LSP_TUNNEL_VPN-IPv6 Cタイプ= EXP2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| |
+ VPN-IPv6 Tunnel Endpoint Address (24 bytes) +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Extended Tunnel ID (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The VPN-IPv4 or VPN-IPv6 tunnel endpoint address field contains an address of the VPN-IPv4 or VPN-IPv6 address family encoded as specified in [RFC4364] or [RFC4659], respectively.
VPN-IPv4またはVPN-IPv6トンネルエンドポイントアドレスフィールドには、[RFC4364]または[RFC4659]でそれぞれ指定されているようにエンコードされたVPN-IPv4またはVPN-IPv6アドレスファミリのアドレスが含まれます。
The Tunnel ID and Extended Tunnel ID are identical to the same fields in the LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6 SESSION objects as per [RFC3209].
トンネルIDと拡張トンネルIDは、[RFC3209]のLSP_TUNNEL_IPv4およびLSP_TUNNEL_IPv6 SESSIONオブジェクトの同じフィールドと同じです。
3.1.2. LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 SENDER_TEMPLATE Objects
3.1.2. LSP_TUNNEL_VPN-IPv4およびLSP_TUNNEL_VPN-IPv6 SENDER_TEMPLATEオブジェクト
The LSP_TUNNEL_VPN-IPv4 (or LSP_TUNNEL_VPN-IPv6) SENDER_TEMPLATE object appears in RSVP-TE messages that ordinarily contain a SENDER_TEMPLATE object and that are sent between ingress PE and egress PE in either direction, such as Path, PathError, and PathTear messages. The object MUST NOT be included in any RSVP-TE messages that are sent outside of the provider's backbone.
LSP_TUNNEL_VPN-IPv4（またはLSP_TUNNEL_VPN-IPv6）SENDER_TEMPLATEオブジェクトは、通常はSENDER_TEMPLATEオブジェクトを含み、入力PEと出力PEの間で、Path、PathError、PathTearメッセージなどのいずれかの方向で送信されるRSVP-TEメッセージに表示されます。オブジェクトは、プロバイダーのバックボーンの外部に送信されるRSVP-TEメッセージに含まれていてはなりません（MUST NOT）。
The format of the object is as follows:
オブジェクトの形式は次のとおりです。
Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv4 C-Type = EXP3
クラス= SENDER_TEMPLATE、LSP_TUNNEL_VPN-IPv4 Cタイプ= EXP3
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| VPN-IPv4 Tunnel Sender Address (12 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv6 C-Type = EXP4
クラス= SENDER_TEMPLATE、LSP_TUNNEL_VPN-IPv6 Cタイプ= EXP4
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| |
+ VPN-IPv6 Tunnel Sender Address (24 bytes) +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The VPN-IPv4 or VPN-IPv6 tunnel sender address field contains an address of the VPN-IPv4 or VPN-IPv6 address family encoded as specified in [RFC4364] or [RFC4659], respectively.
VPN-IPv4またはVPN-IPv6トンネル送信者アドレスフィールドには、[RFC4364]または[RFC4659]でそれぞれ指定されているようにエンコードされたVPN-IPv4またはVPN-IPv6アドレスファミリのアドレスが含まれます。
The LSP ID is identical to the LSP ID field in the LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6 SENDER_TEMPLATE objects as per [RFC3209].
LSP IDは、[RFC3209]のLSP_TUNNEL_IPv4およびLSP_TUNNEL_IPv6 SENDER_TEMPLATEオブジェクトのLSP IDフィールドと同一です。
The LSP_TUNNEL_VPN-IPv4 (or LSP_TUNNEL_VPN-IPv6) FILTER_SPEC object appears in RSVP-TE messages that ordinarily contain a FILTER_SPEC object and that are sent between ingress PE and egress PE in either direction, such as Resv, ResvError, and ResvTear messages. The object MUST NOT be included in any RSVP-TE messages that are sent outside of the provider's backbone.
LSP_TUNNEL_VPN-IPv4（またはLSP_TUNNEL_VPN-IPv6）FILTER_SPECオブジェクトは、通常FILTER_SPECオブジェクトを含み、入力PEと出力PEの間でResv、ResvError、ResvTearメッセージなどのいずれかの方向に送信されるRSVP-TEメッセージに表示されます。オブジェクトは、プロバイダーのバックボーンの外部に送信されるRSVP-TEメッセージに含まれていてはなりません（MUST NOT）。
Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv4 C-Type = EXP5
クラス= FILTER SPECIFICATION、LSP_TUNNEL_VPN-IPv4 C-Type = EXP5
The format of the LSP_TUNNEL_VPN-IPv4 FILTER_SPEC object is identical to the LSP_TUNNEL_VPN-IPv4 SENDER_TEMPLATE object.
LSP_TUNNEL_VPN-IPv4 FILTER_SPECオブジェクトのフォーマットは、LSP_TUNNEL_VPN-IPv4 SENDER_TEMPLATEオブジェクトと同じです。
Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv6 C-Type = EXP6
クラス= FILTER SPECIFICATION、LSP_TUNNEL_VPN-IPv6 Cタイプ= EXP6
The format of the LSP_TUNNEL_VPN-IPv6 FILTER_SPEC object is identical to the LSP_TUNNEL_VPN-IPv6 SENDER_TEMPLATE object.
LSP_TUNNEL_VPN-IPv6 FILTER_SPECオブジェクトの形式は、LSP_TUNNEL_VPN-IPv6 SENDER_TEMPLATEオブジェクトと同じです。
The formats of the VPN-IPv4 and VPN-IPv6 RSVP_HOP objects are identical to the RSVP_HOP objects described in [RFC6016].
VPN-IPv4およびVPN-IPv6 RSVP_HOPオブジェクトのフォーマットは、[RFC6016]で説明されているRSVP_HOPオブジェクトと同じです。
This section describes how the RSVP-TE messages are handled. Handling of these messages assumes that, in the context of BGP/MPLS IP VPNs, the ingress and egress PEs have RSVP-TE capabilities.
このセクションでは、RSVP-TEメッセージの処理方法について説明します。これらのメッセージの処理は、BGP / MPLS IP VPNのコンテキストでは、入力および出力PEにRSVP-TE機能があることを前提としています。
When a Path message arrives at the ingress PE (PE1 in Figure 1), the PE needs to establish suitable Path state and forward the Path message on to the egress PE (PE2 in Figure 1). Below, we describe the message handling process at the ingress PE.
Pathメッセージが入力PE（図1のPE1）に到着すると、PEは適切なPath状態を確立し、Pathメッセージを出力PE（図1のPE2）に転送する必要があります。以下では、入力PEでのメッセージ処理プロセスについて説明します。
1. CE1 sends a Path message to PE1 to establish the MPLS-TE LSP (VPN1) between CE1 and CE2. The Path message is addressed to the eventual destination (the receiver at the remote customer site) and carries the IP Router Alert option, in accordance with [RFC2205]. The ingress PE must recognize the router alert, intercept these messages, and process them as RSVP-TE signaling messages.
1. CE1は、パスメッセージをPE1に送信して、CE1とCE2の間にMPLS-TE LSP（VPN1）を確立します。 [RFC2205]に従って、Pathメッセージは最終的な宛先（リモートカスタマーサイトの受信者）宛てに送信され、IPルーターアラートオプションを伝達します。入力PEはルータアラートを認識し、これらのメッセージを代行受信し、RSVP-TEシグナリングメッセージとして処理する必要があります。
2. When the ingress PE receives a Path message from a CE that is addressed to the receiver, the VRF that is associated with the incoming interface can be identified. (This step does not deviate from current behavior.)
2. 入力PEがCEから受信者宛てのパスメッセージを受信すると、着信インターフェイスに関連付けられているVRFを識別できます。 （この手順は、現在の動作から逸脱していません。）
3. The tunnel endpoint address of the receiver is looked up in the appropriate VRF, and the BGP next hop for that tunnel endpoint address is identified. The next hop is the egress PE.
3. レシーバーのトンネルエンドポイントアドレスが適切なVRFで検索され、そのトンネルエンドポイントアドレスのBGPネクストホップが識別されます。ネクストホップは出力PEです。
4. A new LSP_TUNNEL_VPN-IPv4/VPN-IPv6 SESSION object is constructed, containing the Route Distinguisher (RD) that is part of the VPN-IPv4/VPN-IPv6 route prefix for this tunnel endpoint address, and the IPv4/IPv6 tunnel endpoint address from the original SESSION object.
4. 新しいLSP_TUNNEL_VPN-IPv4 / VPN-IPv6 SESSIONオブジェクトが作成され、このトンネルエンドポイントアドレスのVPN-IPv4 / VPN-IPv6ルートプレフィックスの一部であるRoute Distinguisher（RD）と、からのIPv4 / IPv6トンネルエンドポイントアドレスが含まれます元のSESSIONオブジェクト。
5. A new LSP_TUNNEL_VPN-IPv4/IPv6 SENDER_TEMPLATE object is constructed, with the original IPv4/IPv6 tunnel sender address from the incoming SENDER_TEMPLATE plus the RD that is used by the PE to advertise the prefix for the customers VPN.
5. 新しいLSP_TUNNEL_VPN-IPv4 / IPv6 SENDER_TEMPLATEオブジェクトが構築され、着信SENDER_TEMPLATEからの元のIPv4 / IPv6トンネル送信者アドレスに加えて、顧客のVPNのプレフィックスをアドバタイズするためにPEによって使用されるRDが含まれます。
6. A new Path message is sent containing all the objects from the original Path message, replacing the original SESSION and SENDER_TEMPLATE objects with the new LSP_TUNNEL_VPN-IPv4/VPN-IPv6 type objects. This Path message is sent directly to the egress PE (the next hop that was determined in Step 3) without the IP Router Alert option.
6. 元のPathメッセージのすべてのオブジェクトを含む新しいPathメッセージが送信され、元のSESSIONオブジェクトとSENDER_TEMPLATEオブジェクトが新しいLSP_TUNNEL_VPN-IPv4 / VPN-IPv6タイプのオブジェクトに置き換えられます。このパスメッセージは、IPルーターアラートオプションなしで、出力PE（ステップ3で決定されたネクストホップ）に直接送信されます。
Below, we describe the message handling process at the egress PE.
以下では、出力PEでのメッセージ処理プロセスについて説明します。
1. When a Path message arrives at the egress PE (PE2 in Figure 1), it is addressed to the PE itself and is handed to RSVP for processing.
1. Pathメッセージが出力PE（図1のPE2）に到着すると、それはPE自体にアドレス指定され、処理のためにRSVPに渡されます。
2. The router extracts the RD and IPv4/IPv6 address from the LSP_TUNNEL_VPN-IPv4/VPN-IPv6 SESSION object and determines the local VRF context by finding a matching VPN-IPv4 prefix with the specified RD that has been advertised by this router into BGP.
2. ルータは、LSP_TUNNEL_VPN-IPv4 / VPN-IPv6 SESSIONオブジェクトからRDおよびIPv4 / IPv6アドレスを抽出し、このルータによってBGPにアドバタイズされた、指定されたRDと一致するVPN-IPv4プレフィックスを見つけることにより、ローカルVRFコンテキストを決定します。
3. The entire incoming RSVP message, including the VRF information, is stored as part of the Path state.
3. VRF情報を含む着信RSVPメッセージ全体が、パス状態の一部として保存されます。
4. The egress PE can now construct a Path message that differs from the Path message it received in the following ways:
4. これで、出力PEは、次の点で受信したPathメッセージとは異なるPathメッセージを構築できます。
a. Its tunnel endpoint address is the IP address extracted from the SESSION object.
a. そのトンネルエンドポイントアドレスは、SESSIONオブジェクトから抽出されたIPアドレスです。
b. The SESSION and SENDER_TEMPLATE objects have been converted back to IPv4-type/IPv6-type by discarding the attached RD.
b. 接続されたRDを破棄することにより、SESSIONおよびSENDER_TEMPLATEオブジェクトがIPv4-type / IPv6-typeに変換されます。
c. The RSVP_HOP object contains the IP address of the outgoing interface of the egress PE and a Logical Interface Handle (LIH), as per normal RSVP processing.
c. RSVP_HOPオブジェクトには、通常のRSVP処理に従って、出力PEの発信インターフェイスのIPアドレスと論理インターフェイスハンドル（LIH）が含まれています。
5. The egress PE then sends the Path message towards its tunnel endpoint address over the interface identified in Step 4c. This Path message carries the IP Router Alert option, as required by [RFC2205].
5. 次に、出力PEは、ステップ4cで識別されたインターフェイスを介して、そのトンネルエンドポイントアドレスに向けてPathメッセージを送信します。このパスメッセージには、[RFC2205]で要求されているIPルーターアラートオプションが含まれています。
When a receiver at the customer site originates a Resv message for the session, normal RSVP procedures apply until the Resv, making its way back towards the sender, arrives at the "egress" PE (it is the egress with respect to the direction of data flow, i.e., PE2 in Figure 1). Upon arriving at PE2, the SESSION and FILTER_SPEC objects in the Resv message, and the VRF in which the Resv was received, are used to find the matching Path state that was stored previously.
カスタマーサイトのレシーバがセッションのResvメッセージを発信すると、通常のRSVP手順が適用され、Resvが送信側に戻り、「出力」PEに到着します（データの方向に関しては出力です）。フロー、つまり図1のPE2）。 PE2に到着すると、Resvメッセージ内のSESSIONオブジェクトとFILTER_SPECオブジェクト、およびResvが受信されたVRFを使用して、以前に保存された一致するパス状態が検索されます。
The PE constructs a Resv message to send to the RSVP HOP stored in the Path state, i.e., the ingress PE (PE1 in Figure 1). The LSP TUNNEL IPv4/IPv6 SESSION object is replaced with the same LSP_TUNNEL_VPN-IPv4/VPN-IPv6 SESSION object received in the Path message. The LSP TUNNEL IPv4/IPv6 FILTER_SPEC object is replaced with a LSP_TUNNEL_VPN-IPv4/VPN-IPv6 FILTER_SPEC object, which copies the VPN-IPv4/VPN-IPv6 address from the LSP TUNNEL SENDER_TEMPLATE received in the matching Path message.
PEはResvメッセージを作成して、Path状態に格納されているRSVP HOP、つまり入力PE（図1のPE1）に送信します。 LSP TUNNEL IPv4 / IPv6 SESSIONオブジェクトは、Pathメッセージで受信した同じLSP_TUNNEL_VPN-IPv4 / VPN-IPv6 SESSIONオブジェクトに置き換えられます。 LSP TUNNEL IPv4 / IPv6 FILTER_SPECオブジェクトは、LSP_TUNNEL_VPN-IPv4 / VPN-IPv6 FILTER_SPECオブジェクトに置き換えられます。このオブジェクトは、一致するパスメッセージで受信されたLSP TUNNEL SENDER_TEMPLATEからVPN-IPv4 / VPN-IPv6アドレスをコピーします。
The Resv message MUST be addressed to the IP address contained within the RSVP_HOP object in the Path message.
Resvメッセージは、PathメッセージのRSVP_HOPオブジェクト内に含まれるIPアドレスにアドレス指定する必要があります。
When the ingress PE receives a Resv message (the ingress with respect to data flow, i.e., PE1 in Figure 1), the PE determines the local VRF context and associated Path state for this Resv message by decoding the received SESSION and FILTER_SPEC objects. It is now possible to generate a Resv message to send to the appropriate CE. The Resv message sent to the ingress CE contains the LSP TUNNEL IPv4/IPv6 SESSION and LSP TUNNEL FILTER_SPEC objects, which are derived from the appropriate Path state.
入力PEがResvメッセージ（データフローに関する入力、つまり図1のPE1）を受信すると、PEは、受信したSESSIONおよびFILTER_SPECオブジェクトをデコードして、このResvメッセージのローカルVRFコンテキストと関連するパス状態を決定します。適切なCEに送信するResvメッセージを生成することが可能になりました。入力CEに送信されるResvメッセージには、LSP TUNNEL IPv4 / IPv6 SESSIONオブジェクトとLSP TUNNEL FILTER_SPECオブジェクトが含まれ、これらのオブジェクトは適切なパス状態から導出されます。
Processing of other RSVP messages (i.e., PathError, PathTear, ResvError, ResvTear, and ResvConf) generally follows the rules defined in [RFC2205]. The following additional rules MUST be observed for messages transmitted within the VPN, i.e., between the PEs:
他のRSVPメッセージ（つまり、PathError、PathTear、ResvError、ResvTear、およびResvConf）の処理は、一般に[RFC2205]で定義されている規則に従います。 VPN内、つまりPE間で送信されるメッセージについては、次の追加ルールを遵守する必要があります。
o The SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects MUST be converted from LSP_TUNNEL_IPv4/LSP_TUNNEL_IPv6 [RFC3209] to LSP_TUNNEL_VPN-IPv4/LSP_TUNNEL_VPN-IPv6 form, respectively, and back again, in the same manner as described above for Path and Resv messages.
o SESSION、SENDER_TEMPLATE、およびFILTER_SPECオブジェクトは、LSP_TUNNEL_IPv4 / LSP_TUNNEL_IPv6 [RFC3209]からLSP_TUNNEL_VPN-IPv4 / LSP_TUNNEL_VPN-IPv6フォームにそれぞれ変換し、上記のPathおよびResvメッセージと同じ方法で変換する必要があります。
o The appropriate type of RSVP_HOP object (VPN-IPv4 or VPN-IPv6) MUST be used, as described in Section 8.4 of [RFC6016].
o [RFC6016]のセクション8.4で説明されているように、適切なタイプのRSVP_HOPオブジェクト（VPN-IPv4またはVPN-IPv6）を使用する必要があります。
o Depending on the type of RSVP_HOP object received from the neighbor, the message MUST be MPLS encapsulated or IP encapsulated.
o ネイバーから受信したRSVP_HOPオブジェクトのタイプに応じて、メッセージはMPLSカプセル化またはIPカプセル化する必要があります。
o The matching state and VRF MUST be determined by decoding the corresponding RD and IPv4 or IPv6 address in the SESSION and FILTER_SPEC objects.
o 一致する状態とVRFは、SESSIONおよびFILTER_SPECオブジェクトの対応するRDおよびIPv4またはIPv6アドレスをデコードすることによって決定する必要があります。
o The message MUST be directly addressed to the appropriate PE, without using the Router Alert Option.
o ルータアラートオプションを使用せずに、メッセージを適切なPEに直接送信する必要があります。
MPLS-TE-based BGP/MPLS IP VPNs are based on a peer model. If an operator would like to configure a new site to an existing VPN, configuration of both the CE router and the attached PE router is required. The operator is not required to modify the configuration of PE routers connected to other sites or to modify the configuration of other VPNs.
MPLS-TEベースのBGP / MPLS IP VPNは、ピアモデルに基づいています。オペレーターが既存のVPNに新しいサイトを構成する場合は、CEルーターと接続されたPEルーターの両方の構成が必要です。オペレーターは、他のサイトに接続されているPEルーターの構成を変更したり、他のVPNの構成を変更したりする必要はありません。
It is expected that the use of the extensions specified in this document will not significantly increase the level of operational traffic.
このドキュメントで指定されている拡張機能を使用しても、運用トラフィックのレベルが大幅に増加することはありません。
Furthermore, the additional extensions described in this document will have no impact on the operation of existing resiliency mechanisms available within MPLS-TE.
さらに、このドキュメントで説明されている追加の拡張機能は、MPLS-TE内で利用可能な既存の復元力メカニズムの動作に影響を与えません。
This document defines RSVP-TE extensions for BGP/MPLS IP VPNs. The general security issues for RSVP-TE are described in [RFC3209], [RFC4364] addresses the specific security considerations of BGP/MPLS VPNs. General security considerations for MPLS are described in [RFC5920].
このドキュメントでは、BGP / MPLS IP VPNのRSVP-TE拡張機能を定義しています。 RSVP-TEの一般的なセキュリティ問題は[RFC3209]で説明されており、[RFC4364]はBGP / MPLS VPNの特定のセキュリティの考慮事項に対処しています。 MPLSの一般的なセキュリティの考慮事項は、[RFC5920]で説明されています。
In order to secure the control plane, techniques such as the TCP Authentication Option (TCP-AO) [RFC5925] MAY be used authenticate BGP messages.
コントロールプレーンを保護するために、TCP認証オプション（TCP-AO）[RFC5925]などの技術を使用して、BGPメッセージを認証できます。
To ensure the integrity of an RSVP request, the RSVP Authentication mechanisms defined in [RFC2747], and updated by [RFC3097], SHOULD be used.
RSVPリクエストの完全性を保証するには、[RFC2747]で定義され、[RFC3097]によって更新されたRSVP認証メカニズムを使用する必要があります（SHOULD）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、12月2001年。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、and S. Jamin、 "Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification"、RFC 2205、September 1997年
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベイカー、F。、リンデル、B。、およびM.タルワー、「RSVP暗号認証」、RFC 2747、2000年1月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097] Braden、R。およびL. Zhang、「RSVP Cryptographic Authentication-Updated Message Type Value」、RFC 3097、2001年4月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、2006年2月。
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.
[RFC4659] De Clercq、J.、Ooms、D.、Carugi、M。、およびF. Le Faucheur、「BGP-MPLS IP Virtual Private Network（VPN）Extension for IPv6 VPN」、RFC 4659、2006年9月。
[RFC5824] Kumaki, K., Ed., Zhang, R., and Y. Kamite, "Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN", RFC 5824, April 2010.
[RFC5824] Kumaki、K.、Ed。、Zhang、R.、and Y. Kamite、 "Supporting Supporting Customer Resource ReSerVation Protocol（RSVP）and RSVP Traffic Engineering（RSVP-TE）over BGP / MPLS IP-VPN" 、RFC 5824、2010年4月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、2010年6月。
[RFC6016] Davie, B., Le Faucheur, F., and A. Narayanan, "Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs", RFC 6016, October 2010.
[RFC6016] Davie、B.、Le Faucheur、F。、およびA. Narayanan、「レイヤー3 VPNでのリソース予約プロトコル（RSVP）のサポート」、RFC 6016、2010年10月。
The authors would like to express thanks to Makoto Nakamura and Daniel King for their helpful and useful comments and feedback.
中村誠とダニエル・キングの有益で有用なコメントとフィードバックに感謝します。
Chikara Sasaki KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama 356-8502 Japan EMail: ch-sasaki@kddilabs.jp
ちから ささき Ｋっぢ Ｒ＆Ｄ ぁぼらとりえｓ、 いんｃ。 ２ー１ー１５ おはら ふじみの さいたま ３５６ー８５０２ じゃぱん えまいｌ： ｃｈーささき＠ｋっぢぁｂｓ。ｊｐ
Daisuke Tatsumi KDDI Corporation 2-3-2 Nishishinjuku Shinjuku-ku Tokyo 163-8003 Japan EMail: da-tatsumi@kddi.com
だいすけ たつみ Ｋっぢ こｒぽらちおん ２ー３ー２ にししんじゅく しんじゅくーく ときょ １６３ー８００３ じゃぱん えまいｌ： だーたつみ＠ｋっぢ。こｍ
Authors' Addresses
著者のアドレス
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460 Japan EMail: ke-kumaki@kddi.com
けんじ くまき Ｋっぢ こｒぽらちおん がｒでん あいｒ とうぇｒ いいだばし、 ちよだーく、 ときょ １０２ー８４６０ じゃぱん えまいｌ： けーくまき＠ｋっぢ。こｍ
Tomoki Murai Furukawa Network Solution Corp. 5-1-9, Higashi-Yawata, Hiratsuka Kanagawa 254-0016 Japan EMail: murai@fnsc.co.jp
ともき むらい ふるかわ ねとぉｒｋ そぅちおん こｒｐ。 ５ー１ー９、 ひがしーやわた、 ひらつか かながわ ２５４ー００１６ じゃぱん えまいｌ： むらい＠ｆんｓｃ。こ。ｊｐ
Dean Cheng Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA EMail: dean.cheng@huawei.com
Dean Cheng hu Aはテクノロジー2330の中央高速道路であるSanta Clara、CA 95050 USA電子メール：Dean。成@ Huawei.com
Satoru Matsushima Softbank Telecom 1-9-1,Higashi-Shimbashi,Minato-Ku Tokyo 105-7322 Japan EMail: satoru.matsushima@g.softbank.co.jp
さとる まつしま そｆｔばんｋ てぇこｍ １ー９ー１、ひがしーしｍばし、みなとーく ときょ １０５ー７３２２ じゃぱん えまいｌ： さとる。まつしま＠ｇ。そｆｔばんｋ。こ。ｊｐ
Peng Jiang KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460 Japan EMail: pe-jiang@kddi.com
ぺんｇ じあんｇ Ｋっぢ こｒぽらちおん がｒでん あいｒ とうぇｒ いいだばし、 ちよだーく、 ときょ １０２ー８４６０ じゃぱん えまいｌ： ぺーじあんｇ＠ｋっぢ。こｍ