RFC 6882 EXPERIMENTAL MPLS · ROUTING · VPN · TRAFFIC ENGINEERING
Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs)
Extensions to RSVP-TE for quality-of-service tunnels within BGP/MPLS Layer 3 virtual private networks.
RFC EDITOR
Kumaki, K., Ed., Murai, T., Cheng, D., Matsushima, S., and P. Jiang, "Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs)", RFC 6882, DOI 10.17487/RFC6882, March 2013, <https://www.rfc-editor.org/info/rfc6882>.
BIBTEX
@misc{rfc6882,
series = {Request for Comments},
number = 6882,
howpublished = {RFC 6882},
publisher = {RFC Editor},
doi = {10.17487/RFC6882},
url = {https://www.rfc-editor.org/info/rfc6882},
author = {K. Kumaki and T. Murai and D. Cheng and S. Matsushima and P. Jiang},
title = {{Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs)}},
pagetotal = 15,
year = 2013,
month = mar,
} RFC text
Contents
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)
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 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.
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.
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.
Copyright Notice
Copyright (c) 2013 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
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
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 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.
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.
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.
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.
1.1. Conventions
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].
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 handled appropriately 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 on the two PEs shown in the figure. The customer
sites operate MPLS-TE LSPs.
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.
<--------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. 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 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].
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.
Similarly, Resv messages sent from PE2 to PE1 need an RSVP-TE
mechanism to assign them to the correct VPN.
3. Protocol Extensions and Procedures
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.
3.1. Object Definitions
This experiment will be carried out using the following private Class
Types. This document identifies these Class Types as
"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
3.1.1. LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 SESSION Object
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.
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]).
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.
The formats of the SESSION objects are as follows:
Class = SESSION, LSP_TUNNEL_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class = SESSION, LSP_TUNNEL_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) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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 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.
The format of the object is as follows:
Class = SENDER_TEMPLATE, LSP_TUNNEL_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class = SENDER_TEMPLATE, LSP_TUNNEL_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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 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.
Class = 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.
Class = FILTER SPECIFICATION, LSP_TUNNEL_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.
3.1.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP Objects
The formats of the VPN-IPv4 and VPN-IPv6 RSVP_HOP objects are
identical to the RSVP_HOP objects described in [RFC6016].
3.2. Handling the Messages
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.
3.2.1. Path Message Processing at the 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). Below, we describe
the message handling process at the ingress 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.
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 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.
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.
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.
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.
3.2.2. Path Message Processing at the Egress PE
Below, we describe 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.
4. The egress PE can now construct a Path message that differs
from the Path message it received in the following ways:
a. Its tunnel endpoint address is the IP address extracted from
the SESSION object.
b. The SESSION and SENDER_TEMPLATE objects have been 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 a Logical Interface Handle
(LIH), as per normal RSVP processing.
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].
3.2.3. Resv Processing at the 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 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.
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.
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 the Ingress PE
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.
3.2.5. Other RSVP Messages
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:
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 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 or 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 to 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 resiliency
mechanisms available within MPLS-TE.
5. Security Considerations
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].
In order to secure the control plane, techniques such as the TCP
Authentication Option (TCP-AO) [RFC5925] MAY be used authenticate BGP
messages.
To ensure the integrity of an RSVP request, the RSVP Authentication
mechanisms defined in [RFC2747], and updated by [RFC3097], SHOULD be
used.
6. References
6.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 G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
6.2. Informative References
[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.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097,
April 2001.
[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.
[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.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
[RFC6016] Davie, B., Le Faucheur, F., and A. Narayanan, "Support for
the Resource Reservation Protocol (RSVP) in Layer 3 VPNs",
RFC 6016, October 2010.
7. Acknowledgments
The authors would like to express thanks to Makoto Nakamura and
Daniel King for their helpful and useful comments and feedback.
8. Contributors
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
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
AI ELI5
On this page
PROBLEMService providers use BGP/MPLS Layer 3 VPNs to offer private connectivity to multiple customers over a shared backbone. When a provider edge router handles multiple VPNs with traffic engineering, RSVP-TE control messages arrive stripped of their VPN labels, and the PE cannot tell which VPN each message belongs to.
MECHANISMRFC 6882 defines new RSVP-TE object types that embed VPN identifiers directly in the protocol messages, allowing provider edge routers to identify and correctly route RSVP-TE control messages for multiple VPNs without relying on labels.
EXPERIMENTAL EXTENSIONThis experimental approach enables service providers to offer traffic-engineered paths within L3VPNs without requiring complex label-aware RSVP processing at PE routers, providing an alternative to the label-based approach in RFC 4364.
§1Introduction
RFC 6882 addresses a problem in BGP/MPLS IP VPNs where multiple customer sites need traffic-engineered paths. BGP/MPLS VPNs (defined in RFC 4364) allow service providers to offer VPN connectivity using provider edge (PE) routers that manage multiple customer VPNs. The fundamental issue is that when RSVP-TE control messages (Path and Resv messages) arrive at a PE from another PE, they have been processed by RSVP-TE and lose the VPN label context that identified which VPN the message belonged to.
RFC 4364 describes a label-based approach where VPNs are identified by labels during transport, and PE routers process RSVP messages within the appropriate VPN Routing and Forwarding (VRF) context. However, this approach requires PE routers to process RSVP messages in a VPN-aware manner, which is not straightforward in all implementations. RFC 6882 proposes an alternative experimental approach: embedding the VPN identifier directly in the RSVP-TE protocol message, so the PE can identify the VPN without relying on label context.
Imagine two telephone companies sharing one backbone network, but each with their own private customer line. When a service request comes in, how does the system know which company it's for? This RFC puts the company name in the message itself.
§2The VPN and RSVP-TE Challenge
Consider a network with two VPNs served by provider edge routers PE1 and PE2. Customer sites CE1 and CE2 belong to VPN1, and customer sites CE3 and CE4 belong to VPN2. Both pairs want to establish MPLS traffic-engineered paths using RSVP-TE. CE1 sends a Path message to PE1 destined for CE2. PE1 can identify the VPN from the incoming interface, looks up the remote PE (PE2) through routing, and forwards the Path message.
The problem arises at PE2. The incoming message carries an MPLS label that identifies the VPN, but once the message is handed to the RSVP-TE component for processing, that label context is lost. PE2 sees two Path messages (one from VPN1 and one from VPN2) but cannot distinguish which is which to forward them to the correct customer edge router. RFC 6882 solves this by defining new RSVP object types that carry VPN addresses directly in the RSVP message.
The post office receives packages labeled for both companies, but once they're sorted by the routing system, the labels come off. The solution is to write the company name inside the package itself.
§3New RSVP-TE Objects for VPNs
The RFC defines new object types for SESSION, SENDER_TEMPLATE, and FILTER_SPEC, with IPv4 and IPv6 variants designated as LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6. These objects are identical to the standard RSVP-TE objects, except the address fields contain VPN-IPv4 or VPN-IPv6 addresses, which include a Route Distinguisher (RD) prefix. The RD is a 12-byte value assigned by each provider to uniquely identify EID-to-RLOC mappings within that provider's domain.
For example, the LSP_TUNNEL_VPN-IPv4 SESSION object contains a 12-byte VPN-IPv4 tunnel endpoint address, a 2-byte Tunnel ID, and a 4-byte Extended Tunnel ID. Similarly, the SENDER_TEMPLATE object contains a VPN-IPv4 tunnel sender address and an LSP ID. The RFC also defines VPN-IPv4 and VPN-IPv6 RSVP_HOP objects analogous to those in RFC 6016. These objects are only used in messages between PEs within the provider backbone; messages sent outside the backbone use standard objects.
Instead of using a label that gets stripped off, the message itself says 'For Company A' before it even leaves the backbone.
§4Path and Resv Message Processing
When an ingress PE (PE1) receives a Path message from a customer edge router, it identifies the VPN from the incoming interface and determines the egress PE (PE2) by routing. The PE then constructs a new Path message replacing the standard SESSION and SENDER_TEMPLATE objects with VPN variants that include the Route Distinguisher along with the endpoint addresses. This modified Path message is sent directly to the egress PE.
At the egress PE, the VPN-IPv4 address is decoded to extract the RD and IP address, allowing the PE to identify the correct VRF context. The PE stores the entire incoming message and determines which customer edge router this belongs to. It then creates a new Path message with standard (non-VPN) objects and sends it toward the destination CE router with the IP Router Alert option. When the Resv message returns from the destination, the egress PE applies the reverse transformation, replacing standard objects with VPN variants and sending the message back to the ingress PE. The ingress PE decodes the VPN objects and forwards the message to the originating CE.
When the package comes in, the PE1 reads 'Company A' and adds a special VPN label to the message before sending it to PE2. PE2 reads the VPN address inside the message to know it's Company A, then strips the label and sends a regular message to the customer. On the way back, it puts the VPN address in again.
§5Security Considerations
The RFC notes that general RSVP-TE security issues are covered in RFC 3209, and VPN-specific considerations are in RFC 4364, with broader MPLS security covered in RFC 5920. To secure RSVP control messages between PEs, the RFC recommends using RSVP Authentication as defined in RFC 2747 and updated by RFC 3097. For BGP messages used in VPN routing, TCP Authentication Option (TCP-AO) as specified in RFC 5925 MAY be used.
The embedding of VPN identifiers in RSVP messages does not itself introduce new security threats beyond those already present in the label-based approach. However, implementers must ensure that RSVP messages are only accepted from authorized sources and that the VPN context is correctly validated to prevent unauthorized PE-to-PE communication or traffic leakage between VPNs.
The security of this approach relies on the same mechanisms as regular RSVP and VPNs—making sure that messages come from trusted sources and that the VPN context is correctly validated.
§6References
[RFC2119]RFC 2119Bradner, S., 'Key words for use in RFCs to Indicate Requirement Levels', BCP 14, RFC 2119, March 1997.March 1997[RFC2205]RFC 2205Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 'Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification', RFC 2205, September 1997.September 1997[RFC2747]RFC 2747Baker, F., Lindell, B., and M. Talwar, 'RSVP Cryptographic Authentication', RFC 2747, January 2000.January 2000[RFC3097]RFC 3097Braden, R. and L. Zhang, 'RSVP Cryptographic Authentication -- Updated Message Type Value', RFC 3097, April 2001.April 2001[RFC3209]RFC 3209Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, 'RSVP-TE: Extensions to RSVP for LSP Tunnels', RFC 3209, December 2001.December 2001[RFC4364]RFC 4364Rosen, E. and Y. Rekhter, 'BGP/MPLS IP Virtual Private Networks (VPNs)', RFC 4364, February 2006.February 2006[RFC4659]RFC 4659De 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.September 2006[RFC5824]RFC 5824Kumaki, 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.April 2010[RFC5920]RFC 5920Fang, L., Ed., 'Security Framework for MPLS and GMPLS Networks', RFC 5920, July 2010.July 2010[RFC5925]RFC 5925Touch, J., Mankin, A., and R. Bonica, 'The TCP Authentication Option', RFC 5925, June 2010.June 2010[RFC6016]RFC 6016Davie, B., Le Faucheur, F., and A. Narayanan, 'Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs', RFC 6016, October 2010.October 2010