RFC 6016
Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs
RFC 6016: Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs ✨
Okay bestie, here's the title block 🦋 This is an Internet Standards Track document, so it's a real Internet standard and not just vibes 💅 It was written by B. Davie, F. Le Faucheur, and A. Narayanan, all from Cisco Systems, Inc., and it was published in October 2010. The ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so there's nothing being replaced or patched here 🌸
Abstract ✨
RFC 4364 and RFC 4659 explain how to build provider-provisioned Layer 3 VPNs (L3VPNs) for IPv4 and IPv6 💜 Using RSVP to do admission control on the links between Customer Edge (CE) routers and Provider Edge (PE) routers could be really useful. This document lays out how PE routers handle RSVP messages that travel from CE to CE across an L3VPN, so admission control can happen on the PE-CE links 🎀 Admission control across the provider's backbone can optionally be supported too.
Status of This Memo 🌈
This is an Internet Standards Track document 🔥
It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 📖
Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc6016 🦋
Copyright Notice 🔒
Copyright (c) 2010 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) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for 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 they come without warranty, as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Without an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸
Table of Contents 📚
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Requirements Language ......................................5
2. Problem Statement ...............................................5
2.1. Model of Operation .........................................8
3. Admission Control on PE-CE Links ................................9
3.1. New Objects of Type VPN-IPv4 ...............................9
3.2. Path Message Processing at Ingress PE .....................11
3.3. Path Message Processing at Egress PE ......................12
3.4. Resv Processing at Egress PE ..............................13
3.5. Resv Processing at Ingress PE .............................13
3.6. Other RSVP Messages .......................................14
4. Admission Control in Provider's Backbone .......................14
5. Inter-AS Operation .............................................15
5.1. Inter-AS Option A .........................................15
5.2. Inter-AS Option B .........................................15
5.2.1. Admission Control on ASBR ..........................16
5.2.2. No Admission Control on ASBR .......................16
5.3. Inter-AS Option C .........................................17
6. Operation with RSVP Disabled ...................................17
7. Other RSVP Procedures ..........................................18
7.1. Refresh Overhead Reduction ................................18
7.2. Cryptographic Authentication ..............................18
7.3. RSVP Aggregation ..........................................19
7.4. Support for CE-CE RSVP-TE .................................19
8. Object Definitions .............................................20
8.1. VPN-IPv4 and VPN-IPv6 SESSION Objects .....................20
8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE Objects .............21
8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC Objects .................22
8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP Objects ....................22
8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION Objects ..........24
8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6
SENDER_TEMPLATE Objects ...................................26
8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6
FILTER_SPEC Objects .......................................27
9. IANA Considerations ............................................28
10. Security Considerations .......................................30
11. Acknowledgments ...............................................33
Appendix A. Alternatives Considered .............................34
A.1. GMPLS UNI Approach ........................................34
A.2. Label Switching Approach ..................................34
A.3. VRF Label Approach ........................................34
A.4. VRF Label Plus VRF Address Approach .......................35
References ........................................................35
Normative References ...........................................35
Informative References .........................................361. Introduction ✨
[RFC4364] and [RFC4659] define a Layer 3 VPN service called BGP/MPLS VPNs, for IPv4 and for IPv6 respectively 💖 [RFC2205] defines the Resource Reservation Protocol (RSVP), which can be used to do admission control as part of the Integrated Services (Int-Serv) architecture [RFC1633][RFC2210] 🧚
Customers of a Layer 3 VPN service may run RSVP for admission control (and the resource reservation that goes with it) in their own networks. The links between Provider Edge (PE) and Customer Edge (CE) routers in a Layer 3 VPN are often resource constrained, so it can be really desirable to do admission control over those links 😭 To do admission control with RSVP in that kind of environment, RSVP control messages (like Path messages and Resv messages) need to be handled properly by the PE routers. In the context of BGP/MPLS VPNs, that brings up a few challenges:
- RSVP Path message processing depends on routers recognizing the Router Alert Option ([RFC2113], [RFC2711]) in the IP header. But packets crossing the backbone of a BGP/MPLS VPN are MPLS encapsulated, so the egress PE might not be able to see the Router Alert Option. That can happen because of implementation or policy choices, for example if the egress PE handles the message as "pop and go" without looking at the IP header 🙈
- BGP/MPLS VPNs support non-unique addressing of customer networks. So a PE at the ingress or egress of the provider backbone might have to process Path messages from different customer VPNs that have non-unique destination addresses inside the RSVP message. The current ways of identifying customer context from data packets don't fit with RSVP message processing rules 💀
- A PE at the ingress of the provider's backbone may get Resv messages for different customer VPNs from other PEs, and it needs to be able to match each Resv message to the right customer VPN 🦋
Section 2 has more discussion of these issues 📖
This document describes a set of procedures that get past these challenges, which makes it possible to use admission control with RSVP over the PE-CE links ✨ Similar techniques might also work for other protocols used for admission control, such as the combination of the NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service (QoS) Signaling [RFC5974] and the General Internet Signaling Transport (GIST) protocol [RFC5971] 🌸
Admission control over the provider's backbone can also be useful, done on behalf of one or more L3VPN customers. Core (P) routers in a BGP/MPLS VPN don't have forwarding entries for customer routes, so they can't natively process RSVP messages for customer flows 🙃 The core is also a shared resource carrying traffic for many customers, so resource allocation among customers and trust (or lack of it) need to be addressed too. This document specifies procedures for supporting that scenario 🎀
This document only deals with establishing reservations for unicast flows. Support for multicast traffic in BGP/MPLS VPNs is still evolving and brings extra challenges for admission control, so multicast flows are left for further study at this point 🫶
1.1. Terminology 📝
This document borrows freely from the terminology defined in [RFC2205] and [RFC4364]. Here are a few quick definitions so everyone's on the same page 💅
- Customer Edge (CE) Router: A router at the edge of a customer site that attaches to the network of the VPN provider.
- Provider Edge (PE) Router: A router at the edge of the service provider's network that attaches to one or more customer sites.
- VPN Label: An MPLS label associated with a route to a customer prefix in a VPN (also called a VPN route label).
- VPN Routing and Forwarding (VRF) Table: A PE typically has multiple VRFs, which lets it connect to CEs that are in different VPNs 👑
1.2. Requirements Language 🎀
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] 🔥
(Part 1 of 9 🫶 part 2 is coming next, bestie, so stay tuned!)
2. Problem Statement ✨
Okay so the problem space here is making admission control work between customer sites when the customer subscribes to a BGP/MPLS VPN 🫶. We split it into two bestie-sized problems: (a) admission control on the PE-CE links (in both directions) and (b) admission control across the provider's backbone 💅.
RSVP Path messages are usually addressed to the destination of a session, and they carry the Router Alert Option (RAO) in the IP header. Routers along the path that are set up to process RSVP need to spot that RAO so they can grab the Path messages 👀. But the egress PEs of a network running BGP/MPLS VPNs get packets for customer sites as MPLS-encapsulated packets, and they might forward them based only on the MPLS label 😭. To process RSVP Path messages, the egress VPN PE would have to pop the VPN label and look at the IP header underneath before forwarding (based on the VPN label disposition rules). That's not something data packets need today, so a Path message would just get forwarded without anyone checking the IP options, and it wouldn't get proper processing at the PE 💀.
Another problem is doing Connection Admission Control (CAC) at an Autonomous System Border Router (ASBR). Even an implementation that looks at the IP header when removing the VPN label (e.g., PE-CE link) still couldn't do CAC at an Option-B ASBR. That means examining the (interior) IP header while doing a label swap, which is much less desirable behavior 🙈.
Zooming out, there are big issues with requiring support for IP Router Alert outside of a controlled, "walled-garden" network, as described in [ALERT-USAGE]. An MPLS L3VPN falls under the "Overlay Model" described there. The core idea of that model is that providers want to get rid of the requirement to process RAO-marked packets from customers on any routers except the PEs facing those customers 🌸. The problems with requiring interior MPLS routers to process RAO-marked packets are also covered in [LER-OPTIONS]. The approach for RSVP packet handling in this document has the perk of not depending on any data-plane requirements, like IP Router Alert support within the VPN or examining any IP options for MPLS-encapsulated packets 🧚. The only time you need to process IP Router Alert packets is for RSVP packets received from the CE, which don't carry any MPLS encapsulation.
For the PE-CE link subproblem, the biggest challenge is that RSVP control messages contain IP addresses drawn from the customer's address space. PEs have to handle traffic from lots of customers, and those customers might have non-unique (or overlapping) address spaces 😵💫. So it's essential that a PE can, in all cases, identify the correct VPN context in which to process an RSVP control message. Right now the way it identifies the customer context is the VPN label, which is carried in an MPLS header outside of the RSVP message. That's a bit of a divergence from the general RSVP model of session identification ([RFC2205], [RFC2209]), which relies only on RSVP objects to identify sessions. It also doesn't play nicely with protocols like COPS/RSVP (Common Open Policy Service) ([RFC2748], [RFC2749]), which replace the IP encapsulation of the RSVP message and send only RSVP objects to a COPS server 💔. We think it's important to keep the model of completely identifying an RSVP session from the contents of RSVP objects, and a lot of this document is about exactly that 💜.
For making reservations across the provider backbone, BGP/MPLS VPNs don't create any per-customer forwarding state in the P (provider core) routers. So if you want to make reservations on behalf of customer-specified flows, you clearly need some kind of aggregated reservation from PE-PE, and then you map each customer-specific reservation onto that aggregate reservation 🦋. That's similar to the problem tackled in [RFC3175] and [RFC4804], with the extra twist of handling the customer-specific addressing that comes with BGP/MPLS VPNs.
Picture this: an MPLS VPN customer uses RSVP signaling across their sites for resource reservation and admission control. Let's say that, to start, RSVP isn't processed through the MPLS VPN cloud. RSVP messages from sender to receiver just travel transparently from CE to CE. In that setup, RSVP can still set up resource reservations and admission control on part of the flow path (from the sender to the ingress CE, and from the RSVP router downstream of the egress CE to the receiver) 🎀. Now if admission control gets turned on for the CE-PE link, the provider's backbone, or the PE-CE link (which this document allows), the customer gets a wider coverage of admission control and resource reservation. The reservation now spans a bigger chunk of the flow path, maybe the whole thing, and that boosts the QoS granted to the flow ⭐. Flows whose reservations succeed through admission control on the newly enabled segments really do get that QoS upgrade 🔥.
Here's the catch, though. If there aren't enough resources on one or more of the newly enabled segments, some flows won't be able to keep, or set up, their reservations. Say admission control is enabled on a given PE-->CE link and that link doesn't have enough capacity to admit every reservation for every flow crossing it. Then some flows just won't get in 😬. That can feel unfair, but this only happens when a segment really is short on capacity. Without admission control, every flow would get set up, and they'd all suffer from congestion on the bottleneck segment instead 🙃. And when capacity is tight, admission control lets you enforce controlled, flexible policies, so for example more important flows can get higher priority when reserving resources 👑. Flows also get a chance to establish smaller reservations, so the aggregate load can adapt dynamically to the bottleneck capacity ✨.
2.1. Model of Operation
Figure 1 shows the basic model of operation this document is about 🗺️.
--------------------------
/ Provider \
|----| | Backbone | |----|
Sender->| CE1| |-----| |-----| |CE2 |->Receiver
| |--| | |---| |---| | |---| |
|----| | | | P | | P | | | |----|
| PE1 |---| |-----| |-----| PE2 |
| | | | | | | |
| | |---| |---| | |
|-----| |-----|
| |
\ /
--------------------------
Figure 1. Model of Operation for RSVP-Based Admission
Control over MPLS/BGP VPNTo set up a unidirectional reservation for a point-to-point flow from Sender to Receiver, one that only takes account of resource availability on the CE-PE and PE-CE links, these steps need to happen in order:
- The Sender sends a Path message to an IP address of the Receiver.
- The Path message is processed by CE1 using normal RSVP procedures and forwarded towards the Receiver along the link CE1-PE1.
- PE1 processes the Path message and forwards it towards the Receiver across the provider backbone.
- PE2 processes the Path message and forwards it towards the Receiver along link PE2-CE2.
- CE2 processes the Path message using normal RSVP procedures and forwards it towards the Receiver.
- The Receiver sends a Resv message to CE2.
- CE2 sends the Resv message to PE2.
- PE2 processes the Resv message (including performing admission control on link PE2-CE2) and sends the Resv message to PE1.
- PE1 processes the Resv message and sends the Resv message to CE1.
- CE1 processes the Resv message using normal RSVP procedures, performs admission control on the link CE1-PE1, and sends the Resv message to the Sender if successful.
In each of the Resv steps (6 through 10), the node sending the Resv message uses the Path state it already set up to figure out the "RSVP Previous Hop (PHOP)", and then sends the Resv message to that address. Getting that Path state set up correctly at the PEs is one of the real challenges the BGP/MPLS environment throws at us 🫠.
3. Admission Control on PE-CE Links
In the following sections, we walk through the steps outlined in Section 2.1 and go deeper on the steps where standard RSVP procedures need to be extended or modified to support the BGP/MPLS VPN environment 🎀. For all the other steps in the previous section, standard RSVP processing rules apply.
All the procedures below support both IPv4 and IPv6 addressing. Wherever IPv4 is mentioned, IPv6 can be swapped in with identical procedures and results 🌈. Object definitions for both IPv4 and IPv6 are in Section 8.
3.1. New Objects of Type VPN-IPv4 🎀
okay so for RSVP signaling inside a VPN, a few RSVP objects need a glow-up 💅. Customer IP addresses don't have to be unique, which is the tea ☕. That means the current SESSION, SENDER_TEMPLATE, and FILTERSPEC objects can't globally identify RSVP state in P/PE routers, since they're based on plain IP addresses. So we're proposing new versions of those three that carry globally unique VPN-IPv4 format addresses 🦋. The ingress and egress PE nodes do the translating: regular IPv4 for messages to and from the CE, and VPN-IPv4 for messages to and from PE routers. The rules for that show up in later sections ✨.
The RSVP_HOP object currently names an IP address that the neighboring RSVP hop uses to reply to the sender. But MPLS VPN PE routers (especially ones separated by Option-B ASBRs) aren't required to have direct IP reachability to each other 😭. So we propose using label switching to forward RSVP messages inside an MPLS VPN, by defining a new VPN-IPv4 RSVP_HOP object 🧚. With it, any two adjacent RSVP hops in an MPLS VPN (e.g., a PE in Autonomous System (AS) 1 and a PE in AS2) can correctly identify each other and send RSVP messages straight to each other 💜.
The VPN-IPv4 RSVP_HOP object carries the IPv4 address of the message sender and a Logical Interface Handle (LIH) like before, plus a VPN-IPv4 address that also represents the sender. The message sender MUST also advertise this VPN-IPv4 address into BGP, tied to a locally allocated label, and that advertisement MUST be propagated by BGP throughout the VPN and to adjacent ASes if needed to provide reachability to this PE. Frames the PE receives marked with this label MUST be given to the local control plane for processing. When a neighboring RSVP hop wants to reply to a message carrying a VPN-IPv4 RSVP_HOP, it looks for a BGP advertisement of the VPN-IPv4 address in that object. If it finds that address with an associated label, the neighboring RSVP node MUST encapsulate the RSVP message with this label and send it via MPLS encapsulation to the BGP next hop tied to the route. The destination IP address comes from the IP address field of the RSVP_HOP object, as described in [RFC2205]. The IPv4 address in the RSVP_HOP object keeps doing all its other jobs too, including neighbor matching between Path/Resv and SRefresh messages [RFC2961], authentication [RFC2747], etc. 🌈
The VPN-IPv4 address in the VPN-IPv4 RSVP_HOP object MAY represent an existing address in the VRF that matches the flow (e.g., a local loopback or PE-CE link address within the VRF for this customer), or it MAY be created specially for this purpose. If it's created specially for RSVP signaling (and possibly other control protocols), the BGP advertisement MUST NOT be redistributed to, or reachable by, any CEs outside the MPLS VPN. One way to do that is a special "control protocols VPN" with VRF state on every PE/ASBR, carrying route targets that aren't imported into customer VRFs. If a customer VRF address is used as the VPN-IPv4 address, a VPN-IPv4 address in one customer VRF MUST NOT be used to signal RSVP messages for a flow in a different VRF 🙈.
If a PE/ASBR is sending a Path message to another PE/ASBR within the VPN, and it has any appropriate VPN-IPv4 address for signaling that meets the requirements above, it MUST use a VPN-IPv4 RSVP_HOP object with this address for all RSVP messages within the VPN. If a PE/ASBR doesn't have any appropriate VPN-IPv4 address to use for signaling, it MAY send the Path message with a regular IPv4 RSVP_HOP object. In that case the reply will be IP encapsulated. This option is not preferred, because there's no guarantee that the neighboring RSVP hop has IP reachability to the sending node 💀. If a PE/ASBR receives or originates a Path message with a VPN-IPv4 RSVP_HOP object, any RSVP_HOP object in corresponding upstream messages for this flow (e.g., Resv, ResvTear) or downstream messages (e.g., ResvError, PathTear) sent by this node within the VPN MUST be a VPN-IPv4 RSVP_HOP 👑.
3.2. Path Message Processing at Ingress PE 🦋
When a Path message arrives at the ingress PE (step 3 of Section 2.1), the PE needs to set up suitable Path state and forward the Path message on to the egress PE. In the paragraphs below, we walk through the steps the ingress PE takes 🧚.
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 Option, intercept these messages, and process them as RSVP signaling messages.
As noted above, recognizing Path messages as they arrive at the egress PE (PE2 in Figure 1) is tricky 😭. The approach here is to address the Path messages sent by the ingress PE directly to the egress PE, and to send them without the IP Router Alert Option. So instead of using the ultimate receiver's destination address as the Path message's destination, we use the loopback address of the egress PE. The big win: this doesn't require any new data-plane capabilities on the egress PE beyond those of a standard BGP/MPLS VPN PE 🎀. The details of processing this message at the egress PE are covered below in Section 3.3. Addressing a Path message directly to an RSVP next hop (that may or may not be the next IP hop) is already done in other environments, like those of [RFC4206] and [RFC4804].
Here's the ingress PE in detail. When the ingress PE (PE1 in Figure 1) receives a Path message from CE1 that's addressed to the receiver, the VRF associated with the incoming interface is identified, just like in normal data path operations. The Path state for the session is stored and associated with that VRF, so that potentially overlapping addresses among different VPNs don't look like they belong to the same session 🌸. The destination address of the receiver is looked up in the appropriate VRF, and the BGP next hop for that destination is identified. That next hop is the egress PE (PE2 in Figure 1). A new VPN-IPv4 SESSION object is constructed, containing the Route Distinguisher (RD) that's part of the VPN-IPv4 route prefix for this destination, and the IPv4 address from the SESSION. A new VPN-IPv4 SENDER_TEMPLATE object is also constructed, with the original IPv4 address from the incoming SENDER_TEMPLATE, plus the RD this PE uses to advertise that prefix for this customer into the VPN. A new Path message is constructed with a destination address equal to the egress PE address identified above. This new Path message contains all the objects from the original Path message, with the original SESSION and SENDER_TEMPLATE objects replaced by the new VPN-IPv4 types. The Path message is sent without the Router Alert Option and contains an RSVP_HOP object constructed as specified in Section 3.1 ✨.
3.3. Path Message Processing at Egress PE 🌸
When a Path message arrives at the egress PE (step 4 of Section 2.1), it's addressed to the PE itself and is handed to RSVP for processing. The router extracts the RD and IPv4 address from the VPN-IPv4 SESSION object, and determines the local VRF context by finding a matching VPN-IPv4 prefix with the specified RD that this router has advertised into BGP. The entire incoming RSVP message, including the VRF information, is stored as part of the Path state 💅.
Now the RSVP module can construct a Path message that differs from the Path it received in the following ways:
- a. Its destination address is the IP address extracted from the
SESSIONobject; - b. The
SESSIONandSENDER_TEMPLATEobjects are converted back to IPv4-type by discarding the attached RD; - c. The
RSVP_HOPObject contains the IP address of the outgoing interface of the egress PE and a Logical Interface Handle (LIH), as per normal RSVP processing.
The router then sends the Path message on toward its destination over the interface identified above. This Path message carries the Router Alert Option, as required by [RFC2205] 🔥.
3.4. 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 toward the sender, arrives at the "egress" PE (step 8 of Section 2.1). Note that this is the "egress" PE 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 it was received in, are used to find the matching Path state stored previously. At this stage, admission control can be performed on the PE-CE link 🧐.
Assuming admission control is successful, the PE constructs a Resv message to send to the RSVP previous hop stored in the Path state, i.e., the ingress PE (PE1 in Figure 1). The IPv4 SESSION object is replaced with the same VPN-IPv4 SESSION object received in the Path. The IPv4 FILTER_SPEC object is replaced with a VPN-IPv4 FILTER_SPEC object, which copies the VPN-IPv4 address from the SENDER_TEMPLATE received in the matching Path message. The RSVP_HOP in the Resv message MUST be constructed as specified in Section 3.1. The Resv message MUST be addressed to the IP address contained within the RSVP_HOP object in the Path message. If the Path message contained a VPN-IPv4 RSVP_HOP object, the Resv MUST be MPLS encapsulated using the label associated with that VPN-IPv4 address in BGP, as described in Section 3.1. If the Path message contained an IPv4 RSVP_HOP object, the Resv is simply IP encapsulated and addressed directly to the IP address in the RSVP_HOP object 🦋.
If admission control is not successful on the egress PE, a ResvError message is sent toward the receiver, as per normal RSVP processing 😭.
3.5. Resv Processing at Ingress PE ✨
Upon receiving a Resv message at the ingress PE (step 8 of Section 2.1), 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. Now it's possible to generate a Resv message to send to the appropriate CE. The Resv message sent to the ingress CE will contain IPv4 SESSION and FILTER_SPEC objects, derived from the appropriate Path state. Since this section assumes that admission control over the provider's backbone isn't needed, the ingress PE doesn't perform any admission control for this reservation 💜.
3.6. Other RSVP Messages 📨
Handling PathError, PathTear, ResvError, ResvTear, and ResvConf messages is pretty straightforward, and it follows the rules of [RFC2205] 💅. BUT these extra rules MUST be observed for messages sent within the VPN (so, between the PEs) 🫶:
- The
SESSION,SENDER_TEMPLATE, andFILTER_SPECobjects MUST be converted fromIPv4toVPN-IPv4form and back, in the same way as described above for Path and Resv messages. - The right type of
RSVP_HOPobject (VPN-IPv4orIPv4) MUST be used, as described above. - Depending on the type of
RSVP_HOPobject received from the neighbor, the message MUST be MPLS encapsulated or IP encapsulated, as described above. - The matching state and VRF MUST be determined by decoding the RD and IPv4 addresses in the
SESSIONandFILTER_SPECobjects. 🔍 - The message MUST be directly addressed to the appropriate PE, without using the Router Alert Option. 🎯
4. Admission Control in Provider's Backbone ✨
Okay so the previous section covers how per-customer reservations can be made over the PE-CE links 🎀. For a lot of setups that's enough, especially when the backbone is well engineered with plenty of capacity and there's no need for any admission control in the backbone. But sometimes you can't count on having extra capacity (think failures or unexpected overload 😭), and then it can be really useful to do admission control in the backbone on behalf of customer traffic.
Here's the tea: P routers don't have routes to customer addresses, and if per-customer reservations were allowed in the P routers, scalability would become a real problem 💀. So the per-customer reservations from the previous section have to be mapped onto some kind of aggregate reservations. On top of that, customer data packets still need to be tunneled across the provider backbone, just like in normal BGP/MPLS VPN operation 🌸.
Given all that, a workable way to get admission control in the backbone is to use the ideas in [RFC4804]. MPLS-TE tunnels can be set up between PEs to do aggregate admission control in the backbone 🦋.
An MPLS-TE tunnel from an ingress PE to an egress PE can be thought of as a virtual link with a certain capacity 🧚. The big change from the procedures above is that when a Resv arrives at the ingress PE, the ingress PE can make an admission control decision by checking whether enough capacity remains on that virtual link to admit the new customer reservation. Also, [RFC4804] uses the IF_ID RSVP_HOP object to identify the tunnel across the backbone, NOT the simple RSVP_HOP object described in Section 3.2 🙈. The procedures of [RFC4804] should be followed here as well.
To make admission control in the backbone actually effective, there has to be a way to separate the data-plane traffic that has a reservation from the traffic that doesn't ✨. We assume that packets subject to admission control in the core will be given a particular MPLS EXP value, and that no other packets will be allowed to enter the core with this value unless they've passed admission control 🔒. A fraction of link resources is set aside for queues on core links for packets bearing that EXP value, and the MPLS-TE tunnels use that resource pool to make their constraint-based routing and admission control decisions. All of this lines up with the principles of aggregate RSVP reservations described in [RFC3175] 👑.
5. Inter-AS Operation 🌍
[RFC4364] defines three modes of inter-AS operation for MPLS/BGP VPNs, called Options A, B, and C 💜. The next sections explain how the scheme above can work in each of those inter-AS environments.
5.1. Inter-AS Option A
RSVP in Inter-AS Option A is super straightforward 😌. Each ASBR acts like a PE, and the ASBR-ASBR links can be treated like PE-CE links when it comes to admission control. If the procedures defined in Section 3 are enabled on both ASBRs, admission control can be done on the inter-ASBR links. Each AS operator also gets to decide, independently, whether or not to do admission control across their own backbone. One hard rule here: the new objects described in this document MUST NOT be sent in any RSVP message between two Option-A ASBRs 🚫.
5.2. Inter-AS Option B
To support inter-AS Option B, we need some extra processing of RSVP messages on the ASBRs 🛠️. Quick reminder: when packets go from one AS to another in Option B, each ASBR swaps the VPN label as the packet crosses over. The BGP next hop seen by the ingress PE will be the ASBR, and the ingress and egress PEs don't need IP visibility of each other. So when the ingress PE sends the Path message to the BGP next hop of the VPN-IPv4 route toward the destination, the ASBR is the one that receives it. The ASBR figures out the next hop of the route in a similar way to the ingress PE: it finds a matching BGP VPN-IPv4 route with the same RD and a matching prefix 🔎.
The provider(s) connecting ASes using Option B might or might not want to do admission control on the inter-AS links. That choice changes how the ASBRs work in detail. The two modes, with and without admission control at the ASBRs, are described in the following sections 🎀.
5.2.1. Admission Control on ASBR
In this scenario, the ASBR does full RSVP signaling and admission control 💪. The RSVP database on the ASBR is indexed using the VPN-IPv4 SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects, which uniquely identify RSVP sessions and flows as required by [RFC2205]. The ASBR forwards these objects unmodified in both directions. Everything else in RSVP works as if the ASBR were an RSVP hop 🦋. In particular, the RSVP_HOP objects sent in Path and Resv messages contain IP addresses of the ASBR, and those addresses MUST be reachable by the neighbor the message is being sent to 📍. Since the VPN-IPv4 SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects meet the uniqueness properties needed for an RSVP database implementation as per [RFC2209], the ASBR doesn't need any customer VRF awareness 🙌.
5.2.2. No Admission Control on ASBR
If the ASBR isn't doing admission control, it's preferable that per-flow state is NOT kept on the ASBR 🙅♀️. That means the adjacent RSVP hops (the ingress and egress PEs of the respective ASes) have to send RSVP messages directly to each other. This only works if the messages are MPLS encapsulated. The VPN-IPv4 RSVP_HOP object described in Section 3.1 is REQUIRED in this case 🫶.
When an ASBR that isn't installing local RSVP state gets a Path message, it looks up the next hop of the matching BGP route as described in Section 3.2, then sends the Path message to that next hop without changing any RSVP objects (including the RSVP_HOP) 📬. This repeats at subsequent ASBRs until the Path message reaches a router that IS installing local RSVP state. That's either the ultimate egress PE, or an ASBR set up to do admission control. That router processes the Path as described in Section 3.3 if it's a PE, or as described in Section 5.2.1 if it's an ASBR doing admission control. When this router sends the Resv upstream, it looks up the routing table for a next hop+label for the VPN-IPv4 address in the PHOP, wraps the Resv with that label, and sends it upstream 🚀. The upstream RSVP hop (the one that last updated the RSVP_HOP field in the Path message) gets this message for control processing directly, without any involvement from the intermediate ASBRs 🧚.
The ASBR isn't expected to process any RSVP messages other than the Path message described above, and it doesn't need to store any RSVP state either 🌸. Note that any ASBR along the path that wants to do admission control or insert itself into the RSVP signaling flow may do so, by writing its own RSVP_HOP object with IPv4 and VPN-IPv4 addresses pointing to itself 💖.
If an Option-B ASBR gets an RSVP Path message with an IPv4 RSVP_HOP and doesn't want to do admission control, but is willing to install local state for this flow, the ASBR MUST process and forward RSVP signaling messages for this flow as described in Section 5.2.1 (except it doesn't do admission control). If an Option-B ASBR gets an RSVP Path message with an IPv4 RSVP_HOP, but doesn't want to install local state or do admission control for this flow, the ASBR MUST NOT forward the Path message. On top of that, the ASBR SHOULD send a PathError message with Error Code "RSVP over MPLS Problem" and Error Value "RSVP_HOP not reachable across VPN" (see Section 9) 😬. This tells the upstream RSVP hop that the supplied RSVP_HOP object isn't enough to provide reachability across this VPN. This failure condition is not expected to be recoverable 💀.
5.3. Inter-AS Option C
RSVP in Inter-AS Option C is also pretty straightforward 💅, because there's an LSP that goes directly from the ingress PE to the egress PE. In this case there's no big difference in operation from the single AS case in Section 3 ✨. And if you want admission control from PE to PE, you can build an inter-AS TE tunnel and then use the procedures described in Section 4 🎀.
6. Operation with RSVP Disabled 🌙
A lot of the time, RSVP won't be enabled on the PE-CE links 🙃. In that kind of setup, a customer can reasonably expect that RSVP messages sent into the L3 VPN network get forwarded just like any other IP datagrams. That transparency is handy if the customer wants to use RSVP within their own sites, or maybe to do admission control on the CE-PE links (CE->PE direction only), without the PEs getting involved 🫶. So a PE SHOULD NOT discard or modify RSVP messages sent toward it from a CE when RSVP isn't enabled on the PE-CE links. Likewise, a PE SHOULD NOT discard or modify RSVP messages destined for one of its attached CEs, even when RSVP isn't enabled on those links 💜. Heads up: the Router Alert Option in some RSVP messages can make them get forwarded outside the normal forwarding path, but this guidance still applies in that case ⚠️. Also, this guidance applies no matter whether RSVP-TE is used in some, all, or none of the L3VPN network 🌈.
7. Other RSVP Procedures 🧩
This section describes changes to other RSVP procedures that come with MPLS VPNs 💖.
7.1. Refresh Overhead Reduction
Here are the points to keep in mind about RSVP refresh overhead reduction [RFC2961] across an MPLS VPN 👀:
- The hop between the ingress and egress PE of a VPN should be treated as traversing one or more non-RSVP hops. So the procedures in Section 5.3 of [RFC2961] that relate to non-RSVP hops SHOULD be followed 🍓.
- The source IP address of an
SRefreshmessage MUST match the IPv4 address signaled in theRSVP_HOPobject in the corresponding Path or Resv message. The IPv4 address in any received VPN-IPv4RSVP_HOPobject MUST be used as the source address of that message for this purpose 🎀.
7.2. Cryptographic Authentication 🔐
Okay bestie, there are a few things to keep in mind about RSVP cryptographic authentication ([RFC2747]) when it's running across an MPLS VPN 💅
- Whatever IPv4 address shows up in a received VPN-IPv4 RSVP_HOP object MUST be used as the source address of that message when you're figuring out which security association it belongs to 🔑
- Forwarding of Challenge and Response messages MUST follow the same rules as the hop-by-hop messages we already talked about. Specifically, if the originator of a Challenge/Response message has received a VPN-IPv4 RSVP_HOP object from the corresponding neighbor, it MUST use the label associated with that VPN-IPv4 address in BGP to forward the Challenge/Response message 🎀
7.3. RSVP Aggregation ✨
Okay so [RFC3175] and [RFC4860] describe ways to bundle a bunch of individual RSVP reservations into one bigger reservation, based on a shared Differentiated Services Code Point/Per-Hop Behavior (DSCP/PHB) for traffic classification. It's giving efficiency 🍓 A few points to note here:
- The procedures in this section only apply when the Aggregator and Deaggregator nodes are C/CE devices, and the entire MPLS VPN sits inside the Aggregation Region. The case where the PE is also an Aggregator/Deaggregator is way more complex and isn't covered in this document 🙈
- Support of Aggregate RSVP sessions is OPTIONAL. When it's supported:
- Aggregate RSVP sessions MUST be treated the same way as regular IPv4 RSVP sessions. To make that happen, all the procedures in Sections 3 and 4 MUST be followed for aggregate RSVP sessions. The new SESSION, SENDER_TEMPLATE, and FILTERSPEC objects that go with this are defined in Section 8 👑
- End-To-End (E2E) RSVP sessions get passed through the MPLS VPN unmodified 🦋 These RSVP messages SHOULD be identified by their IP protocol (RSVP-E2E-IGNORE, 134). When the ingress PE receives any RSVP message with this IP protocol, it MUST process the frame as if it's regular customer traffic and ignore any Router Alert Option. The appropriate VPN and transport labels get applied to the frame, and it's forwarded towards the remote CE. Note that this message won't be received or processed by any other P or PE node 🌸
- Any SESSION-OF-INTEREST object (defined in [RFC4860]) MUST be conveyed unmodified across the MPLS VPN 💜
7.4. Support for CE-CE RSVP-TE 🧚
[RFC5824] lays out a set of requirements for setting up CE-CE MPLS LSPs across networks that offer an L3VPN service. Those requirements are pretty similar to what this document handles, since both are about dealing with RSVP requests from customers in a VPN context. It's possible the solution described here could be adapted to meet the requirements of [RFC5824] ✨ As for the signaling extensions from [RFC3473] that have already been used for GMPLS/TE, we expect CE-CE RSVP/TE to be incremental work built on top of them. Those extensions will get their own separate document 💖
8. Object Definitions 🎀
8.1. VPN-IPv4 and VPN-IPv6 SESSION Objects 💅
So the VPN-IPv4 (or VPN-IPv6) SESSION object is used the way Sections 3.2 to 3.6 describe. It shows up in RSVP messages that would normally carry a SESSION object and that get sent between ingress PE and egress PE in either direction 🦋 The object MUST NOT be included in any RSVP messages sent outside of the provider's backbone. The one exception is the inter-AS Option-B and Option-C cases from above, where it may appear on inter-AS links 🌈
The VPN-IPv6 SESSION object is basically the same idea as the VPN-IPv4 SESSION object, just using a VPN-IPv6 address ([RFC4659]) instead of a VPN-IPv4 address ([RFC4364]) 💜
Here's how the objects are laid out:
- VPN-IPv4 SESSION object:
Class = 1, C-Type = 19
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 DestAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+- VPN-IPv6 SESSION object:
Class = 1, C-Type = 20
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 DestAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+The VPN-IPv4 DestAddress (or VPN-IPv6 DestAddress) field holds an address from the VPN-IPv4 (or VPN-IPv6) address family, encoded as specified in [RFC4364] (or [RFC4659]). Sections 3.2 and 3.3 talk more about what goes in this field 🌷
The protocol ID, flags, and DstPort are identical to the same fields in the IPv4 and IPv6 SESSION objects ([RFC2205]) ✨
8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE Objects 🍓
The VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object is used the way Sections 3.2 and 3.3 describe. It shows up in RSVP messages that would normally carry a SENDER_TEMPLATE object and that get sent between ingress PE and egress PE in either direction, like Path, PathError, and PathTear 🛸 The object MUST NOT be included in any RSVP messages sent outside of the provider's backbone. Same exception as before: the inter-AS Option-B and Option-C cases from above, where it may appear on inter-AS links 🫶 The layouts go like this:
- VPN-IPv4 SENDER_TEMPLATE object:
Class = 11, C-Type = 14
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 SrcAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | SrcPort |
+-------------+-------------+-------------+-------------+- VPN-IPv6 SENDER_TEMPLATE object:
Class = 11, C-Type = 15
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 SrcAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Reserved | SrcPort |
+-------------+-------------+-------------+-------------+The VPN-IPv4 SrcAddress (or VPN-IPv6 SrcAddress) field holds an address from the VPN-IPv4 (or VPN-IPv6) address family, encoded as specified in [RFC4364] (or [RFC4659]). Sections 3.2 and 3.3 cover the content of this field 💖
The SrcPort is identical to the SrcPort field in the IPv4 and IPv6 SENDER_TEMPLATE objects ([RFC2205]) 🌸
The Reserved field MUST be set to zero on transmit and ignored on receipt 🙈
8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC Objects 🦋
The VPN-IPv4 (or VPN-IPv6) FILTER_SPEC object is used the way Sections 3.4 and 3.5 describe. It shows up in RSVP messages that would normally carry a FILTER_SPEC object and that get sent between ingress PE and egress PE in either direction, like Resv, ResvError, and ResvTear 🌈 The object MUST NOT be included in any RSVP messages sent outside of the provider's backbone. The inter-AS Option-B and Option-C cases from above are the only exception, where it may appear on inter-AS links 💅
- VPN-IPv4 FILTER_SPEC object:
Class = 10, C-Type = 14. Definition same as VPN-IPv4 SENDER_TEMPLATE object. - VPN-IPv6 FILTER_SPEC object:
Class = 10, C-Type = 15. Definition same as VPN-IPv6 SENDER_TEMPLATE object.
The content of the VPN-IPv4 SrcAddress (or VPN-IPv6 SrcAddress) field is discussed in Sections 3.4 and 3.5 ✨
The SrcPort is identical to the SrcPort field in the IPv4 and IPv6 SENDER_TEMPLATE objects ([RFC2205]) 🎀
The Reserved field MUST be set to zero on transmit and ignored on receipt 🧚
8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP Objects ✨
Okay so, this is the RSVP_HOP sibling of everything we just did 💖 You can find how it's used in Sections 3.1 and 5.2.2. The VPN-IPv4 (or VPN-IPv6) RSVP_HOP object is what sets up signaling reachability between RSVP neighbors that are separated by one or more Option-B ASBRs 🦋 It can show up in RSVP messages that carry an RSVP_HOP object, as long as those messages are traveling between the ingress and egress PEs. It MUST NOT be included in any RSVP messages sent outside the provider's backbone (except in the inter-AS Option-B and Option-C cases from above, when it may appear on inter-AS links) 🙈 Here are the two formats:
- VPN-IPv4 RSVP_HOP object: Class = 3, C-Type = 5
+-------------+-------------+-------------+-------------+
| IPv4 Next/Previous Hop Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 Next/Previous Hop Address (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+- VPN-IPv6 RSVP_HOP object: Class = 3, C-Type = 6
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Next/Previous Hop Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 Next/Previous Hop Address (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+The IPv4 Next/Previous Hop Address, IPv6 Next/Previous Hop Address, and Logical Interface Handle fields are exactly the same as the ones in the RSVP_HOP object ([RFC2205]) 🧚
The VPN-IPv4 Next/Previous Hop Address field (or the VPN-IPv6 Next/Previous Hop Address field) holds an address from the VPN-IPv4 (or VPN-IPv6) address family, encoded the way [RFC4364] (or [RFC4659]) says. We get into what goes in there in Section 3.1 💅
8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION Objects 🎀
The Aggregated VPN-IPv4 (or VPN-IPv6) SESSION object is covered in Section 7.3, and it's giving main character energy ✨ The AGGREGATE-VPN-IPv4 (or AGGREGATE-VPN-IPv6) SESSION object shows up in RSVP messages that would normally carry an AGGREGATE-IPv4 (or AGGREGATE-IPv6) SESSION object from [RFC3175], and it goes between the ingress PE and the egress PE in either direction 🦋 The GENERIC-AGGREGATE-VPN-IPv4 (or AGGREGATE-VPN-IPv6) SESSION object should appear in every RSVP message that would normally carry a GENERIC-AGGREGATE-IPv4 (or GENERIC-AGGREGATE-IPv6) SESSION object from [RFC4860], again going between the ingress PE and egress PE in either direction. These objects MUST NOT be included in any RSVP messages sent outside the provider's backbone (except in the inter-AS Option-B and Option-C cases from above, when it may appear on inter-AS links) 🙈 Otherwise, the processing rules are identical to the VPN-IPv4 (or VPN-IPv6) SESSION object from Section 8.1, so no new drama there 💅 Here are the formats:
- AGGREGATE-VPN-IPv4 SESSION object: Class = 1, C-Type = 21
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 DestAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | Reserved | DSCP |
+-------------+-------------+-------------+-------------+- AGGREGATE-VPN-IPv6 SESSION object: Class = 1, C-Type = 22
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 DestAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | Reserved | DSCP |
+-------------+-------------+-------------+-------------+The VPN-IPv4 DestAddress field (or VPN-IPv6 DestAddress field) holds an address from the VPN-IPv4 (or VPN-IPv6) address family, encoded the way [RFC4364] (or [RFC4659]) describes. Sections 3.2 and 3.3 explain what goes in this field 🌸
The flags and DSCP are exactly the same as the matching fields in the AGGREGATE-IPv4 and AGGREGATE-IPv6 SESSION objects ([RFC3175]) 🍓
The Reserved field MUST be set to zero on transmit and ignored on receipt 💜
- GENERIC-AGGREGATE-VPN-IPv4 SESSION object: Class = 1, C-Type = 23
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 DestAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+- GENERIC-AGGREGATE-VPN-IPv6 SESSION object: Class = 1, C-Type = 24
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 DestAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+The VPN-IPv4 DestAddress field (or VPN-IPv6 DestAddress field) holds an address from the VPN-IPv4 (or VPN-IPv6) address family, encoded the way [RFC4364] (or [RFC4659]) describes. Sections 3.2 and 3.3 explain what goes in this field 🌈
The flags, PHB-ID, vDstPort, and Extended vDstPort are exactly the same as the matching fields in the GENERIC-AGGREGATE-IPv4 and GENERIC-AGGREGATE-IPv6 SESSION objects ([RFC4860]) ✨
The Reserved field MUST be set to zero on transmit and ignored on receipt 🫶
8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 SENDER_TEMPLATE Objects 💖
okay so the Aggregated VPN-IPv4 SENDER_TEMPLATE object is the one we talked about in Section 7.3 ✨. The AGGREGATE-VPN-IPv4 object shows up in RSVP messages that would normally carry an AGGREGATE-IPv4 SENDER_TEMPLATE object from [RFC3175] and [RFC4860], and it gets sent between the ingress PE and the egress PE in either direction. bestie, these objects MUST NOT go into any RSVP messages that leave the provider's backbone 🙅♀️ (the only exception is the inter-AS Option-B and Option-C stuff from above, where it may show up on inter-AS links). Otherwise the processing rules are basically the same as the VPN-IPv4 SENDER_TEMPLATE object from Section 8.2, so no need to relearn anything 🎀. Here's how the format looks:
- AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 16
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 AggregatorAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+- AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 17
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 AggregatorAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+The VPN-IPv4 AggregatorAddress field holds an address from the VPN-IPv4 address family, encoded the way [RFC4364] says. The VPN-IPv6 AggregatorAddress field does the same thing for VPN-IPv6, following [RFC4659] 🌸. The content and processing rules are similar to the VPN-IPv4 SENDER_TEMPLATE object from Section 8.2, so you're already halfway there 💅.
Also, the flags and DSCP are exactly the same as the matching fields in the AGGREGATE-IPv4 and AGGREGATE-IPv6 SESSION objects 🦋.
8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC Objects 🧚
the AGGREGATE-VPN-IPv4 FILTER_SPEC object is the filter version of the same idea (Section 7.3 again, we love consistency 🫶). It appears in RSVP messages that would normally have an AGGREGATE-IPv4 FILTER_SPEC object from [RFC3175] and [RFC4860], and it goes between ingress PE and egress PE in either direction. Same rule as before: these objects MUST NOT be in any RSVP messages that leave the provider's backbone 🚫. The one exception is the inter-AS Option-B and Option-C cases from above, where it may appear on inter-AS links.
The processing rules are otherwise identical to the VPN-IPv4 FILTER_SPEC object from Section 8.3, which is giving very copy-paste energy ✨. Here's the format:
- AGGREGATE-VPN-IPv4 FILTER_SPEC object: Class = 10, C-Type = 16
Definition same as AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object.
- AGGREGATE-VPN-IPv6 FILTER_SPEC object: Class = 10, C-Type = 17
Definition same as AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object.
9. IANA Considerations 📋
okay so Section 8 adds brand-new objects, which means IANA got to work updating a few registries 🎀. Here's what changed:
First up, IANA changed the RSVP parameters registry, the 'Class Names, Class Numbers, and Class Types' subregistry. They gave six new C-Types under the existing SESSION Class (Class number 1):
Class
Number Class Name Reference
------ ----------------------- ---------
1 SESSION [RFC2205]
Class Types or C-Types:
.. ... ...
19 VPN-IPv4 [RFC6016]
20 VPN-IPv6 [RFC6016]
21 AGGREGATE-VPN-IPv4 [RFC6016]
22 AGGREGATE-VPN-IPv6 [RFC6016]
23 GENERIC-AGGREGATE-VPN-IPv4 [RFC6016]
24 GENERIC-AGGREGATE-VPN-IPv6 [RFC6016]Next, four new C-Types went under the existing SENDER_TEMPLATE Class (Class number 11):
Class
Number Class Name Reference
------ ----------------------- ---------
11 SENDER_TEMPLATE [RFC2205]
Class Types or C-Types:
.. ... ...
14 VPN-IPv4 [RFC6016]
15 VPN-IPv6 [RFC6016]
16 AGGREGATE-VPN-IPv4 [RFC6016]
17 AGGREGATE-VPN-IPv6 [RFC6016]Then four more C-Types went under the existing FILTER_SPEC Class (Class number 10):
Class
Number Class Name Reference
------ ----------------------- ---------
10 FILTER_SPEC [RFC2205]
Class Types or C-Types:
.. ... ...
14 VPN-IPv4 [RFC6016]
15 VPN-IPv6 [RFC6016]
16 AGGREGATE-VPN-IPv4 [RFC6016]
17 AGGREGATE-VPN-IPv6 [RFC6016]And last for that registry, two new C-Types went under the existing RSVP_HOP Class (Class number 3):
Class
Number Class Name Reference
------ ----------------------- ---------
3 RSVP_HOP [RFC2205]
Class Types or C-Types:
.. ... ...
5 VPN-IPv4 [RFC6016]
6 VPN-IPv6 [RFC6016]One more thing, and it's a big one 😭. A new PathError code/value is needed to flag a signaling reachability failure, plus the need for a VPN-IPv4 or VPN-IPv6 RSVP_HOP object, as described in Section 5.2.2. So IANA also changed the RSVP parameters registry, the 'Error Codes and Globally-Defined Error Value Sub-Codes' subregistry, and assigned a new Error Code and sub-code:
37 RSVP over MPLS Problem [RFC6016]
This Error Code has the following globally-defined Error
Value sub-codes:
1 = RSVP_HOP not reachable across VPN [RFC6016]10. Security Considerations 🔒✨
okay bestie, security is SERIOUS 😭 [RFC4364] already covers security for BGP/MPLS VPNs in general, and general RSVP security lives in [RFC2205]. To keep RSVP's integrity safe, the RSVP Authentication mechanisms in [RFC2747] and [RFC3097] SHOULD be supported 🛡️. They protect RSVP message integrity hop-by-hop, give node authentication and replay protection, so corruption and spoofing of RSVP messages get blocked 🚫. [RSVP-KEYING] talks about which keying approaches fit RSVP Authentication 🔑. First, the group keying discussion for an intra-provider environment where RSVP hops aren't IP hops is relevant to securing RSVP among PEs of a Service Provider deploying this spec 🧠. RSVP signaling in an MPLS VPN will likely spread across multiple administrative domains (the provider running the VPN, plus the customers), so the inter-domain considerations in [RSVP-KEYING] are likely to apply too 🌍.
Since RSVP messages travel through the L3VPN cloud, addressed directly to PE or ASBR routers (without the IP Router Alert Option), P routers stay isolated from the RSVP messages signaling customer reservations 🙌. Providers MAY choose to block PEs from sending datagrams with the Router Alert Option to P routers as a security practice, and that won't impact the functionality described here 🧱.
Beyond those general issues, four specific issues are introduced by this document. We'll go through them in turn 🎀:
- resource usage on PEs
- resource usage in the provider backbone
- PE route advertisement outside the AS
- signaling exposure to ASBRs and PEs
First up, resource usage on PEs 💅. A customer reserving on the CE-PE links for their sites is only competing with themselves for link resources, same as standard RSVP. That's true in the common case where each CE-PE link is dedicated to a single customer 💖. So from the CE-PE link point of view, this document doesn't add any new security issues ✨. BUT a PE typically serves multiple customers, so a customer could try to hog computing resources on a PE (CPU cycles, memory, etc.) by sending huge numbers of RSVP messages to it 😤. In the extreme, that's a form of denial-of-service attack 💀. To prevent this, a PE SHOULD support mechanisms that limit the fraction of its processing resources that any one CE, or the set of CEs of a given customer, can consume 🛑. For example, a PE might implement a form of rate limiting on the RSVP messages it receives from each CE 🚦. We also observe that these risks and measures are very similar for any control-plane protocol operating between CE and PE, like RSVP, routing, or multicast 🔁.
Next, resource usage in the provider backbone 🌐. This second concern only shows up when the service provider chooses to offer resource reservation across the backbone, as described in Section 4. Then a single customer might try to reserve a large chunk of backbone capacity, maybe with a coordinated effort from several CEs, which would deny service to other customers using the same backbone 😱. [RFC4804] gives some guidance on security issues when RSVP reservations are aggregated onto MPLS tunnels, and those apply to this situation 📚. We note that a provider MAY use local policy to limit the amount of resources a given customer can reserve from a particular PE, and a policy server could be used to control a given customer's resource usage across multiple PEs if desired 🧠. It is RECOMMENDED that an implementation of this specification support local policy on the PE to control the amount of resources that can be reserved by a given customer/CE 💜.
Now, PE route advertisement outside the AS 🚨. Using the VPN-IPv4 RSVP_HOP object requires exporting a PE VPN-IPv4 route to another AS. If those routes were redistributed indiscriminately, it could allow unchecked access to remote PEs. BUT, as Section 3.1 describes, no route that isn't within a customer's VPN should EVER be advertised to (or be reachable from) that customer 🙅♀️. If a PE uses a local address that's already within a customer VRF (like a PE-CE link address), it MUST NOT send this address in any RSVP messages in a different customer VRF 🚫. A "control-plane" VPN MAY be created across PEs and ASBRs, and addresses in this VPN can be used to signal RSVP sessions for any customers. But these routes MUST NOT be advertised to, or made reachable from, any customer 🔐. An implementation of the present document MAY support such operation using a "control-plane" VPN 🧚. Alternatively, ASBRs MAY implement the signaling procedures described in Section 5.2.1, even if admission control is not required on the inter-AS link, since these procedures don't require any direct P/PE route advertisement out of the AS 🦋.
Last but definitely not least, signaling exposure to ASBRs and PEs 📮. Certain operations described in Section 3 require an ASBR or PE to receive and locally process a signaling packet addressed to the BGP next hop address that router advertised. This requirement does not strictly apply to MPLS/BGP VPNs [RFC4364]. It could be viewed as opening ASBRs and PEs up to being directly addressable by customer devices where they weren't before, and that could be considered a security issue 😬. If a provider wants to mitigate this, the implementation MAY support the "control protocol VPN" approach described above. Whenever a signaling message is to be sent to a PE or ASBR, the address of that router would be looked up in the "control protocol VPN", and the message would then be sent on the LSP found as a result of that lookup 🛤️. This makes sure the router address is not reachable by customer devices 🙈.
[RFC4364] mentions the use of IPsec on both a CE-CE basis and a PE-PE basis 🔐. Here's what it says:
Cryptographic privacy is not provided by this architecture, nor by
Frame Relay or ATM VPNs. These architectures are all compatible
with the use of cryptography on a CE-CE basis, if that is desired.
The use of cryptography on a PE-PE basis is for further study.The procedures in this document for admission control on the PE-CE links (Section 3) are compatible with the use of IPsec on a PE-PE basis ✅. The optional procedures for admission control in the Service Provider's backbone (Section 4) are not compatible with IPsec on a PE-PE basis 💔, since those procedures depend on PE-PE MPLS TE Tunnels to perform aggregate reservations through the Service Provider's backbone.
[RFC4923] describes a model for RSVP operation through IPsec Gateways 🧩. In a nutshell, it uses a form of hierarchical RSVP reservation: an RSVP reservation is made for the IPsec tunnel, and then individual RSVP reservations are admitted/aggregated over that tunnel reservation 🪆. This model applies when IPsec is used on a CE-CE basis. In that situation, the procedures defined in this document would simply apply "as is" to the reservation established for the IPsec tunnel(s) 💖.
11. Acknowledgments 🫶
Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric Rosen, Dan Tappan, and Lou Berger for their many contributions to solving the problems described in this document 👑. Thanks to Ferit Yegenoglu for his useful comments 🌸. We also thank Stefan Santesson, Vijay Gurbani, and Alexey Melnikov for their review comments 💜. We thank Richard Woundy for his very thorough review and comments, including those that resulted in additional text discussing scenarios of admission control reject in the MPLS VPN cloud 🙌. Also, we thank Adrian Farrel for his detailed review and contributions ⭐.
Appendix A. Alternatives Considered 🦋
At this stage, a number of alternatives to the approach described above have been considered. We document some of them here to assist future discussion 📝. None of these have been shown to improve upon the approach described above, and the first two seem to have significant drawbacks relative to it 😬.
Appendix A.1. GMPLS UNI Approach
[RFC4208] defines the GMPLS UNI. In Section 7, the operation of the GMPLS UNI in a VPN context is briefly described. This is somewhat similar to the problem tackled in the current document. The main difference is that the GMPLS UNI is primarily aimed at allowing a CE device to request the establishment of a Label Switched Path (LSP) across the network on the other side of the UNI 🛤️. So the procedures in [RFC4208] would lead to the establishment of an LSP across the VPN provider's network for every RSVP request received, which is not desired in this case 🙅♀️.
To the extent possible, the approach described in this document is consistent with [RFC4208], while filling in more of the details and avoiding the problem noted above ✨.
Appendix A.2. Label Switching Approach
Implementations that always look at IP headers inside the MPLS label on the egress PE can intercept Path messages and determine the correct VRF and RSVP state by using a combination of the encapsulating VPN label and the IP header 🔍. In our view, this is an undesirable approach for two reasons 💀. Firstly, it imposes a new MPLS forwarding requirement for all data packets on the egress PE. Secondly, it requires using the encapsulating MPLS label to identify RSVP state, which runs counter to existing RSVP principle and practice, where all information used to identify RSVP state is included within RSVP objects. RSVP extensions such as COPS/RSVP [RFC2749], which re-encapsulate RSVP messages, are incompatible with this change 🚫.
Appendix A.3. VRF Label Approach
Another approach to solving the problems described here involves the use of label switching to ensure that Path, Resv, and other RSVP messages are directed to the appropriate VRF on the next RSVP hop (e.g., egress PE). One challenge with such an approach is that [RFC4364] does not require labels to be allocated for VRFs, only for customer prefixes, and there is no simple, existing method for advertising the fact that a label is bound to a VRF 🏷️. If, for example, an ingress PE sent a Path message labelled with a VPN label that was advertised by the egress PE for the prefix that matches the destination address in the Path, there is a risk that the egress PE would simply label-switch the Path directly on to the CE without performing RSVP processing 😱.
A second challenge with this approach is that an IP address needs to be associated with a VRF and used as the PHOP address for the Path message sent from ingress PE to egress PE. That address needs to be reachable from the egress PE, and to exist in the VRF at the ingress PE. Such an address is not always available in today's deployments, so this represents at least a change to existing deployment practices 🌈.
Appendix A.4. VRF Label Plus VRF Address Approach ✨
okay so this one is giving "fix the last approach but make it cute" 💅 It's totally possible to build something off the previous section that actually tackles its main problems 🫶 The basic plan has two parts: (a) make a brand new BGP Extended Community to tag a route (and its associated MPLS label) as pointing to a VRF 🏷️, and (b) give each VRF its own "dummy" address 🎀, used only for routing RSVP messages. That dummy address could be literally anything, like a loopback of the associated PE 🧚, and it would be the PHOP for Path messages and the destination for Resv messages. It would never get imported into the VRFs of any other PE 🔒 bestie, the whole point is that it stays in its own lane.
References ✨
Okay, here's the reference squad, all of them, no cap 💖
Normative References
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert
Option", RFC 2711, October 1999.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B.
Davie, "Aggregation of RSVP for IPv4 and IPv6
Reservations", RFC 3175, September 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.
[RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation
Protocol (RSVP) Reservations over MPLS TE/DS-TE
Tunnels", RFC 4804, February 2007.Informative References
[ALERT-USAGE] Le Faucheur, F., Ed., "IP Router Alert Considerations
and Usage", Work in Progress, July 2010.
[LER-OPTIONS] Smith, D., Mullooly, J., Jaeger, W., and T. Scholl,
"Requirements for Label Edge Router Forwarding of IPv4
Option Packets", Work in Progress, May 2010.
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) -- Version 1 Message Processing
Rules", RFC 2209, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
[RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan,
R., and A. Sastry, "The COPS (Common Open Policy
Service) Protocol", RFC 2748, January 2000.
[RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan,
R., and A. Sastry, "COPS usage for RSVP", RFC 2749,
January 2000.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
F., and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value",
RFC 3097, April 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
October 2005.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI): Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Support for the
Overlay Model", RFC 4208, October 2005.
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C.,
and M. Davenport, "Generic Aggregate Resource
ReSerVation Protocol (RSVP) Reservations", RFC 4860,
May 2007.
[RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS)
Signaling in a Nested Virtual Private Network",
RFC 4923, August 2007.
[RFC5824] Kumaki, K., 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.
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General
Internet Signalling Transport", RFC 5971,
October 2010.
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS
Signaling Layer Protocol (NSLP) for Quality-of-Service
Signaling", RFC 5974, October 2010.
[RSVP-KEYING] Behringer, M., Faucheur, F., and B. Weis,
"Applicability of Keying Methods for RSVP Security",
Work in Progress, September 2010.Authors' Addresses ✨
Meet the brains behind it 🌸
Bruce Davie
Cisco Systems, Inc.
1414 Mass. Ave.
Boxborough, MA 01719
USA
EMail: bsd@cisco.com
Francois Le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
Biot Sophia-Antipolis 06410
France
EMail: flefauch@cisco.com
Ashok Narayanan
Cisco Systems, Inc.
1414 Mass. Ave.
Boxborough, MA 01719
USA
EMail: ashokn@cisco.com📦 where this page comes from
- ietf: rfc6016 2010-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms