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
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.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
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）的产品。它代表了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.
版权所有（c）2013 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. 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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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，必须由提供商边缘（PE）路由器适当处理RSVP-TE控制消息，包括[RFC3209]中描述的路径和Resv消息。[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.
本文档定义了遵循不同方法的实验格式和机制。记录的方法允许在RSVP-TE协议消息中携带VPN标识符，因此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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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，则需要新的RSVP-TE扩展，以便PE可以适当处理来自CEs的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网络支持的两个VPN。两个VPN在图中所示的两个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在CE2和CE4分配相同的地址（例如192.0.2.1）。
<--------Customer MPLS-TE LSP for VPN1-------->
<--------Customer MPLS-TE LSP for VPN1-------->
....... .......
. --- . --- --- --- --- . --- .
.|CE1|----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2|.
. --- . --- --- --- --- . --- .
....... | | .......
(VPN1) | | (VPN1)
| |
....... | | .......
. --- . | | . --- .
.|CE3|------+ +-------|CE4|.
. --- . . --- .
....... .......
(VPN2) (VPN2)
....... .......
. --- . --- --- --- --- . --- .
.|CE1|----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2|.
. --- . --- --- --- --- . --- .
....... | | .......
(VPN1) | | (VPN1)
| |
....... | | .......
. --- . | | . --- .
.|CE3|------+ +-------|CE4|.
. --- . . --- .
....... .......
(VPN2) (VPN2)
<--------Customer MPLS-TE LSP for VPN2-------->
^ ^
| |
VRF instance VRF instance
<--------Customer MPLS-TE LSP for VPN2-------->
^ ^
| |
VRF instance VRF instance
<-Customer-> <---BGP/MPLS IP VPN---> <-Customer->
network network
<-Customer-> <---BGP/MPLS IP VPN---> <-Customer->
network network
Figure 1: Customer MPLS TE LSPs in the context of BGP/MPLS IP VPNs
图1:BGP/MPLS IP VPN上下文中的客户MPLS TE LSP
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:
考虑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].
在收到每条Path消息后，PE1可以从接收消息的传入接口识别每条Path消息的客户上下文。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.
当在PE2处接收到路径消息时，该节点需要区分消息并确定哪个适用于VPN1，哪个适用于VPN2，以便可以建立正确的转发状态，并将消息传递给正确的CE。尽管消息到达PE2时带有标识VPN的MPLS标签，但消息被传递到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消息需要RSVP-TE机制将其分配到正确的VPN。
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.
本节定义了额外的RSVP-TE对象，以满足第2节所述的要求。这些对象是会话、SENDER_模板和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-Type=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
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）会话对象出现在RSVP-TE消息中，这些消息通常包含会话对象，并在入口PE和出口PE之间以任意方向发送。此对象不得包含在在提供商主干网之外发送的任何RSVP-TE消息中。
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会话对象类似于LSP_TUNNEL_VPN-IPv4会话对象，使用VPN-IPv6地址（[RFC4659]）而不是VPN-IPv4地址（[RFC4364]）。
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.
实验者必须确保用于此实验的私有类类型与PEs使用的其他类类型之间没有冲突。
The formats of the SESSION objects are as follows:
会话对象的格式如下所示：
Class = SESSION, LSP_TUNNEL_VPN-IPv4 C-Type = EXP1
类=会话，LSP\U隧道\U VPN-IPv4 C-Type=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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
类=会话，LSP\U隧道\U VPN-IPv6 C-Type=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) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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].
根据[RFC3209]，隧道ID和扩展隧道ID与LSP_Tunnel_IPv4和LSP_Tunnel_IPv6会话对象中的相同字段相同。
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发送方_模板对象
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）发送方_模板对象出现在RSVP-TE消息中，这些消息通常包含发送方_模板对象，并在入口PE和出口PE之间以任意方向发送，例如Path、PathError和PathTear消息。在提供程序主干之外发送的任何RSVP-TE消息中不得包含该对象。
The format of the object is as follows:
对象的格式如下所示：
Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv4 C-Type = EXP3
类=发送方\模板，LSP\隧道\ VPN-IPv4 C-Type=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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
类=发送方\模板，LSP\隧道\ VPN-IPv6 C-Type=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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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].
根据[RFC3209]，LSP ID与LSP_TUNNEL_IPv4和LSP_TUNNEL_IPv6发送方_模板对象中的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对象出现在RSVP-TE消息中，这些消息通常包含FILTER_SPEC对象，并在入口PE和出口PE之间以任意方向发送，如Resv、ResvError和ResvTear消息。在提供程序主干之外发送的任何RSVP-TE消息中不得包含该对象。
Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv4 C-Type = EXP5
类=筛选器规范，LSP\u隧道\u 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筛选器_规范对象的格式与LSP_TUNNEL_VPN-IPv4发送方_模板对象的格式相同。
Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv6 C-Type = EXP6
类=筛选器规范，LSP\u隧道\u VPN-IPv6 C-Type=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.
当路径消息到达入口PE（图1中的PE1）时，PE需要建立适当的路径状态并将路径消息转发到出口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]，路径消息被发送到最终目的地（远程客户站点的接收器），并携带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会话对象，其中包含作为此隧道端点地址的VPN-IPv4/VPN-IPv6路由前缀的一部分的路由标识符（RD），以及来自原始会话对象的IPv4/IPv6隧道端点地址。
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发送者_模板对象，其中包含来自传入发送者_模板的原始IPv4/IPv6隧道发送者地址加上PE用于为客户VPN播发前缀的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. 将发送包含原始路径消息中所有对象的新路径消息，用新的LSP_隧道\u VPN-IPv4/VPN-IPv6类型对象替换原始会话和发送方\u模板对象。此路径消息直接发送到出口PE（在步骤3中确定的下一个跃点），无需IP路由器警报选项。
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会话对象提取RD和IPv4/IPv6地址，并通过查找与指定RD匹配的VPN-IPv4前缀来确定本地VRF上下文，该RD已由该路由器播发到BGP中。
3. The entire incoming RSVP message, including the VRF information, is stored as part of the Path state.
3. 整个传入RSVP消息（包括VRF信息）存储为路径状态的一部分。
4. The egress PE can now construct a Path message that differs from the Path message it received in the following ways:
4. 出口PE现在可以通过以下方式构造不同于其接收的路径消息的路径消息：
a. Its tunnel endpoint address is the IP address extracted from the SESSION object.
a. 其隧道端点地址是从会话对象提取的IP地址。
b. The SESSION and SENDER_TEMPLATE objects have been converted back to IPv4-type/IPv6-type by discarding the attached RD.
b. 通过丢弃连接的RD，会话和发送方模板对象已转换回IPv4类型/IPv6类型。
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处理，RSVP_-HOP对象包含出口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中标识的接口向其隧道端点地址发送路径消息。根据[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跃点，即入口PE（图1中的PE1）。LSP隧道IPv4/IPv6会话对象替换为路径消息中接收到的相同LSP_隧道VPN-IPv4/VPN-IPv6会话对象。LSP隧道IPv4/IPv6筛选器_规范对象将替换为LSP隧道VPN-IPv4/VPN-IPv6筛选器_规范对象，该对象从匹配路径消息中接收的LSP隧道发送方_模板复制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
当入口PE接收到Resv消息（入口与数据流有关，即图1中的PE1）时，PE通过解码接收到的会话和筛选器规范对象来确定该Resv消息的本地VRF上下文和相关路径状态。现在可以生成Resv消息以发送给相应的CE。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.
发送到入口CE的消息包含从相应路径状态派生的LSP隧道IPv4/IPv6会话和LSP隧道筛选器规范对象。
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内（即在PEs之间）传输的消息，必须遵守以下附加规则：
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 会话、发送方模板和筛选器规范对象必须分别从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 必须通过解码会话和筛选器规范对象中相应的RD和IPv4或IPv6地址来确定匹配状态和VRF。
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扩展。[RFC3209]中描述了RSVP-TE的一般安全问题，[RFC4364]阐述了BGP/MPLS VPN的具体安全注意事项。[RFC5920]中描述了MPLS的一般安全注意事项。
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身份验证机制。
[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：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[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.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“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加密身份验证——更新的消息类型值”，RFC 3097，2001年4月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“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，“用于IPv6 VPN的BGP-MPLS IP虚拟专用网络（VPN）扩展”，RFC 46592006年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.，和Y.Kamite，“通过BGP/MPLS IP-VPN支持客户资源预留协议（RSVP）和RSVP流量工程（RSVP-TE）的要求”，RFC 58242010年4月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，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，“TCP认证选项”，RFC 59252010年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 60162010年10月。
The authors would like to express thanks to Makoto Nakamura and Daniel King for their helpful and useful comments and feedback.
作者要感谢Makoto Nakamura和Daniel King提供的有用的评论和反馈。
Chikara Sasaki KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama 356-8502 Japan EMail: ch-sasaki@kddilabs.jp
Chikara Sasaki KDDI研发实验室有限公司2-1-15 Ohara Fujimino Saitama 356-8502日本电子邮件：ch-sasaki@kddilabs.jp
Daisuke Tatsumi KDDI Corporation 2-3-2 Nishishinjuku Shinjuku-ku Tokyo 163-8003 Japan EMail: da-tatsumi@kddi.com
Daisuke Tatsumi KDDI Corporation 2-3-2 Nishishinjuku新宿东京163-8003日本电子邮件：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
Kenji Kumaki KDDI公司东京千代田区第三达巴希花园航空塔102-8460日本电子邮件：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
Tomoki Murai Furukawa网络解决方案公司5-1-9，Hiratsuka Kanagawa Hiratsuka Yawata 254-0016日本电子邮件：murai@fnsc.co.jp
Dean Cheng Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA EMail: dean.cheng@huawei.com
Dean Cheng Huawei Technologies 2330美国加利福尼亚州圣克拉拉中央高速公路95050电子邮件：Dean。cheng@huawei.com
Satoru Matsushima Softbank Telecom 1-9-1,Higashi-Shimbashi,Minato-Ku Tokyo 105-7322 Japan EMail: satoru.matsushima@g.softbank.co.jp
松岛佐藤软银电信1-9-1，日本东京弥敦区东新桥105-7322电子邮件：佐藤。matsushima@g.softbank.co.jp
Peng Jiang KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460 Japan EMail: pe-jiang@kddi.com
彭江KDDI株式会社东京千代田区Iidabashi花园航空大厦102-8460日本电子邮件：pe-jiang@kddi.com