Network Working Group K. Kumaki, Ed.
Internet Draft KDDI Corporation
Intended Status: Standards Track T. Murai
Expires: October 29, 2012 Furukawa Network Solutions Corp.
D. Cheng
Huawei Technologies
S. Matsushima
Softbank Telecom
P. Jiang
KDDI Corporation
April 29, 2012
Support for RSVP-TE in L3VPNs
draft-kumaki-murai-l3vpn-rsvp-te-05.txt
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.
The VPNs may support a number of customer services including RSVP and
RSVP-TE traffic. This document describes how to support RSVP-TE
between customer sites when a single PE supports multiple VPNs.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 29, 2012.
K.Kumaki, et al. [Page 1]
draft-kumaki-murai-l3vpn-rsvp-te-05 April 2012
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. 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.
Table of Contents
1. Introduction..................................................3
2. Motivation....................................................3
2.1 Network Example...........................................3
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
..............................................................5
3.1.2 LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 SENDER_TEMPLATE
Objects.......................................................7
3.1.3 LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 FILTER_SPEC
Objects.......................................................8
3.1.4 VPN-IPv4 and VPN-IPv6 RSVP_HOP Objects..................8
3.2 Handling..................................................8
3.2.1 Path Message Processing at Ingress PE...................8
3.2.2 Path Message Processing at Egress PE....................9
3.2.3 Resv Processing at Egress PE............................10
3.2.4 Resv Processing at Ingress PE...........................10
3.2.5 Other RSVP Messages.....................................11
4. Management Considerations.....................................11
4.1 Impact on Network Operation...............................11
5. Security Considerations.......................................11
6. IANA Considerations...........................................12
7. References....................................................12
7.1 Normative References......................................12
7.2 Informative References....................................12
8. Acknowledgments...............................................13
9. Author's Addresses............................................13
K.Kumaki, et al. [Page 2]
draft-kumaki-murai-l3vpn-rsvp-te-05 April 2012
Conventions used in this document
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 [RFC2119].
1. Introduction
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].
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 Path
messages and Resv messages described in [RFC3209], to be
appropriately handled by the Provider Edge (PE) routers. [RFC6016]
defines the new types of existing RSVP objects (i.e. SESSION,
SENDER_TEMPLATE, FILTERSPEC and RSVP_HOP) to replace those described
in [RFC2205] for use to establish reservations for customer flows in
the context of a BGP/MPLS IP-VPNs. Section 7.4 of [RFC6016] notes
the applicability of [RFC6016], but delegates a description of
RSPV-TE in the BGP/MPLS IP-VPN environment to a separate document.
This document provides the necessary description.
In order to support multiple MPLS-TE LSPs in different BGP/MPLS
IP-VPNs that are interconnected via the same Provider Edge (PE)
routers, new RSVP-TE extensions are required. This document defines
the required extensions and describes the procedures.
2. Motivation
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 appropriately handled by the PE.
2.1 Network Example
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 supported by the two PEs shown in the figure. The
customer sites operate MPLS-TE LSPs.
Here, we make the following set of assumptions.
K.Kumaki, et al. [Page 3]
draft-kumaki-murai-l3vpn-rsvp-te-05 April 2012
1. VPN1 and VPN2 are for different customers.
2. CE1 and CE3 are head-end routers.
3. CE2 and CE4 are tail-end routers.
4. The same address (e.g., 192.0.2.1) is assigned at CE2 and CE4.
<--------A customer MPLS TE LSP for VPN1-------->
....... .......
. --- . --- --- --- --- . --- .
.|CE1|----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2|.
. --- . --- --- --- --- . --- .
....... | | .......
(VPN1) | | (VPN1)
| |
....... | | .......
. --- . | | . --- .
.|CE3|------+ +-------|CE4|.
. --- . . --- .
....... .......
(VPN2) (VPN2)
<--------A 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 a
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. CE1 would send a Path message to PE1 to establish
the MPLS TE LSP (VPN1) between CE1 and CE2.
2. CE3 would also send a Path message to PE1 to establish
the MPLS TE LSP (VPN2) between CE1 and CE2.
After receiving each Path messages, 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].
When the Path messages are received at PE2, that node needs to
distinguish the messages and determine which applies to VPN1 and
K.Kumaki, et al. [Page 4]
draft-kumaki-murai-l3vpn-rsvp-te-05 April 2012
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 will arrive at PE2 with an MPLS label that identifies
the VPN, the messages will be delivered to the RSVP-TE component on
PE2 and the context of the core VPN LSP (i.e., the label) will be
lost. Some RSVP-TE protocol mechanism is therefore needed to embed
the VPN identifier within the RSVP-TE message.
Similarly, Resv messages sent from PE2 to PE1 need an RSVP-TE
mechanisms to assign them to the correct VPN.
3. Protocol Extensions and Procedures
This section provides the additional RSVP-TE objects to meet the
requirements described in Section 2. These are new variants of the
SESSION, SENDER_TEMPLATE and FILTERSPEC objects. These new objects
will act as identifiers and allow PEs to The new object types are
defined in Section 3.1, and the specific procedure is described in
Section 3.2.
3.1 Object Definitions
3.1.1 LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 SESSION Object
The LSP_TUNNEL_VPN-IPv4 (or VPN-IPv6) SESSION object appears in
RSVP-TE messages that ordinarily contain a SESSION object and are
sent between ingress PE and egress PE in either direction. The object
MUST NOT be included in any RSVP-TE message that is sent outside of
the provider's backbone.
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]).
The formats of the objects are as follows:
Class = SESSION, LSP_TUNNEL_VPN-IPv4 C-Type = TBA
K.Kumaki, et al. [Page 5]
draft-kumaki-murai-l3vpn-rsvp-te-05 April 2012
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 end point address (12 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class = SESSION, LSP_TUNNEL_VPN-IPv6 C-Type = TBA
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 end point address |
+ +
| (24 bytes) |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Extended Tunnel ID |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The VPN-IPv4 tunnel end point address (respectively, VPN-IPv6 tunnel
end point address) field contains an address of
the VPN-IPv4 (respectively, VPN-IPv6) address family encoded as
specified in [RFC4364](respectively, [RFC4659]).
K.Kumaki, et al. [Page 6]
draft-kumaki-murai-l3vpn-rsvp-te-05 April 2012
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].
3.1.2 LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 SENDER_TEMPLATE
Objects
The LSP_TUNNEL_VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object appears
in RSVP-TE messages that ordinarily contain a SENDER_TEMPLATE object
and are sent between ingress PE and egress PE in either direction
(such as Path, PathError, and PathTear). The object MUST NOT be
included in any RSVP-TE messages that are sent outside of the
provider's backbone. The format of the object is as follows:
Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv4 C-Type = TBA
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 = TBA
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
K.Kumaki, et al. [Page 7]
draft-kumaki-murai-l3vpn-rsvp-te-05 April 2012
The VPN-IPv4 tunnel sender address (respectively, VPN-IPv6 tunnel
sender address) field contains an address of the VPN-IPv4
(respectively, VPN-IPv6) address family encoded as specified
in [RFC4364] (respectively, [RFC4659]).
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].
3.1.3 LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 FILTER_SPEC Objects
The LSP_TUNNEL_VPN-IPv4 (or VPN-IPv6) FILTER_SPEC object appears in
RSVP-TE messages that ordinarily contain a FILTER_SPEC object and are
sent between ingress PE and egress PE in either direction (such as
Resv, ResvError, and ResvTear). The object MUST NOT be included in
any RSVP-TE messages that are sent outside of the provider's
backbone.
Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv4 C-Type = TBA
The format of the LSP_TUNNEL_VPN-IPv4 FILTER_SPEC object is identical
to the LSP_TUNNEL_VPN-IPv4 SENDER_TEMPLATE object.
Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv6 C-Type = TBA
The format of the LSP_TUNNEL_VPN-IPv6 FILTER_SPEC object is identical
to the LSP_TUNNEL_VPN-IPv6 SENDER_TEMPLATE object.
3.1.4 VPN-IPv4 and VPN-IPv6 RSVP_HOP Objects
The format of the VPN-IPv4 and VPN-IPv6 RSVP_HOP objects are
identical to objects described in [RFC6016].
3.2 Handling
It assumes that ingress PEs and egress PEs in the context of BGP/MPLS
IP-VPNs have RSVP-TE capabilities.
3.2.1 Path Message Processing at Ingress PE
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). In this section
we described the message handling process at the ingress PE.
1. CE1 would send 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,
K.Kumaki, et al. [Page 8]
draft-kumaki-murai-l3vpn-rsvp-te-05 April 2012
in accordance with [RFC2205]. The ingress PE must recognize
the router alert, intercept these messages and process them
as RSVP-TE signalling messages.
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).
3. The tunnel end point address of the receiver is looked up in
the appropriate VRF, and the BGP Next-Hop for that tunnel end
point address is identified. The next-hop is the egress 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 end
point address, and the IPv4/IPv6 tunnel end point address from
the original SESSION object.
5. A new LSP_TUNNEL_VPN-Pv4/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.
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 as being looked up
in step 3 above) without IP Router Alert.
3.2.2 Path Message Processing at Egress PE
In this section we described the message handling process at the
egress 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.
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.
3. The entire incoming RSVP message, including the VRF
information, is stored as part of the Path state.
K.Kumaki, et al. [Page 9]
draft-kumaki-murai-l3vpn-rsvp-te-05 April 2012
4. The egress PE can now construct a Path message which differs
from the Path message it received in the following ways:
a. Its tunnel end point address is the IP address extracted
from the SESSION object;
b. The SESSION and SENDER_TEMPLATE objects are converted
back to IPv4-type/IPv6-type by discarding the attached
RD;
c. The RSVP_HOP object contains the IP address of the
outgoing interface of the egress PE and an LIH, as per
normal RSVP processing.
5. The egress PE then sends the Path message on towards its
tunnel end point address over the interface identified above.
This Path message carries the IP Router-Alert option as
required by [RFC2205].
3.2.3 Resv Processing at Egress PE
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
"egress" with respect to the direction of data flow, i.e. PE2 in
figure 1). On arriving at PE2, the SESSION and FILTER_SPEC objects
in the Resv, and the VRF in which the Resv was received, are used to
find the matching Path state stored previously.
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. 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.
The Resv message MUST be addressed to the IP address contained within
the RSVP_HOP object in the Path message.
3.2.4 Resv Processing at Ingress PE
Upon receiving a Resv message at the ingress PE (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 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 will contain LSP TUNNEL IPv4/IPv6 SESSION and LSP
TUNNEL FILTER_SPEC objects, derived from the appropriate Path state.
K.Kumaki, et al. [Page 10]
draft-kumaki-murai-l3vpn-rsvp-te-05 April 2012
3.2.5 Other RSVP Messages
Processing of other RSVP messages, i.e., PathError, PathTear,
ResvError, ResvTear, and ResvConf message in general follows the
rules defined in [RFC2205], with additional rules that MUST be
observed for messages transmitted within the VPN, i.e., between the
PEs as follows:
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 in the same manner as described above for Path and Resv
messages.
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 Depending on the type of RSVP_HOP object received from the
neighbor, the message MUST be MPLS encapsulated or IP encapsulated.
o The matching state and VRF MUST be determined by decoding the
corresponding RD and IPv4 (respectively, IPv6) address in the
SESSION and FILTER_SPEC objects.
o The message MUST be directly addressed to the appropriate PE,
without using the Router Alert Option.
4. Management Considerations
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 modify the configuration
of other VPNs.
4.1 Impact on Network Operation
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 MPLS-TE resiliency
mechanisms available within MPLS-TE.
5. Security Considerations
K.Kumaki, et al. [Page 11]
draft-kumaki-murai-l3vpn-rsvp-te-05 April 2012
This document defines RSVP-TE extensions for BGP/MPLS IP-VPNs. Hence
the security of the RSVP-TE extensions relies on the security of
RSVP-TE extensions for LSP tunnels.
The security issues are described in the existing RSVP-TE extensions
for LSP tunnels. [RFC3209]
6. IANA Considerations
IANA maintains a registry of RSVP parameters. As described in Section
3 (Protocol Extensions and Procedures) six new Class Types (C-types)
have been defined. IANA is requested to make the following
allocations from the "RSVP C-Types" sub-registry:
Class = SESSION, LSP_TUNNEL_VPN-IPv4 C-Type = TBA
Class = SESSION, LSP_TUNNEL_VPN-IPv6 C-Type = TBA
Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv4 C-Type = TBA
Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv6 C-Type = TBA
Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv4 C-Type = TBA
Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv6 C-Type = TBA
7. References
7.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V. and Swallow, G., "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
7.2 Informative References
[RFC5824] Kumaki, K., Zhang, R. and Kamite, Y., "Requirements for
supporting Customer RSVP and RSVP-TE over a BGP/MPLS
IP-VPN", RFC 5824, April 2010.
[RFC6016] Davie, B., Faucheur, F. and Narayanan, A., "Support for
the Resource Reservation Protocol (RSVP) in Layer 3
VPNs", RFC 6016, October 2010.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and
Jamin, S., "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
K.Kumaki, et al. [Page 12]
draft-kumaki-murai-l3vpn-rsvp-te-05 April 2012
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[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.
8. Acknowledgments
The authors would like to express thanks to Makoto Nakamura for his
helpful and useful comments and feedback.
9. Author's Addresses
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Email: ke-kumaki@kddi.com
Tomoki Murai
Furukawa Network Solutions 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, U.S.A.
Email: dean.cheng@huawei.com
Satoru Matsushima
Softbank Telecom
1-9-1,Higashi-Shimbashi,Minato-Ku
Tokyo 105-7322, JAPAN
Email: satoru.matsushima@tm.softbank.co.jp
Peng Jiang
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Email: pe-jiang@kddi.com
K.Kumaki, et al. [Page 13]
draft-kumaki-murai-l3vpn-rsvp-te-05 April 2012
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
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Email: da-tatsumi@kddi.com
K.Kumaki, et al. [Page 14]
draft-kumaki-murai-l3vpn-rsvp-te-05 April 2012