Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs
Extracted elements (28)
Path messages sent between PEs are addressed directly to the egress PE's loopback address and sent without the IP Router Alert Option (RAO), rather than using the receiver's address. This avoids requiring egress PEs to inspect IP headers inside MPLS-encapsulated packets ('pop and go' behavior) and eliminates dependency on RAO processing in the backbone.
The 'Label Switching Approach' alternative (intercepting Path messages by inspecting IP headers inside MPLS labels at egress PE) was rejected because it imposes new MPLS forwarding requirements on all data packets and requires using encapsulating labels to identify RSVP state, which is incompatible with COPS/RSVP extensions that re-encapsulate RSVP messages.
VPN-IPv4 (and VPN-IPv6) addresses are embedded directly into RSVP SESSION, SENDER_TEMPLATE, FILTER_SPEC, and RSVP_HOP objects rather than relying on MPLS VPN labels to identify the VPN context. This preserves the RSVP principle that all session-identifying information is contained within RSVP objects, ensuring compatibility with protocols like COPS/RSVP that re-encapsulate RSVP messages.
For RSVP cryptographic authentication (RFC 2747), the IPv4 address field of any received VPN-IPv4 RSVP_HOP object MUST be used as the source address for identifying the security association. Challenge and Response messages MUST be forwarded using the same MPLS label lookup as other RSVP messages.
When RSVP aggregation (RFC 3175 / RFC 4860) is used, it applies only when Aggregator and Deaggregator nodes are CE devices and the entire MPLS VPN lies within the Aggregation Region. Aggregate RSVP sessions MUST be treated identically to regular IPv4 sessions with the corresponding VPN-typed objects. End-To-End RSVP messages (IP protocol 134, RSVP-E2E-IGNORE) MUST be passed through as regular customer traffic, ignoring the Router Alert Option.
A PE SHOULD NOT discard or modify RSVP messages received from a CE or destined for a CE when RSVP is not enabled on the PE-CE links; such messages should be forwarded transparently as regular IP datagrams.
An Option-B ASBR that receives a Path message with an IPv4 RSVP_HOP and does not wish to install local state MUST NOT forward the Path message, and SHOULD send a PathError with Error Code 'RSVP over MPLS Problem' and Error Value 'RSVP_HOP not reachable across VPN'.
For PathError, PathTear, ResvError, ResvTear, and ResvConf messages sent within the VPN, the SESSION/SENDER_TEMPLATE/FILTER_SPEC objects MUST be converted between IPv4 and VPN-IPv4 form, the appropriate RSVP_HOP type MUST be used, messages MUST be MPLS or IP encapsulated based on the received RSVP_HOP type, and messages MUST be addressed directly to the appropriate PE without using the Router Alert Option.
For SRefresh messages (RFC 2961 refresh overhead reduction), the source IP address MUST match the IPv4 address signaled in the RSVP_HOP object of the corresponding Path or Resv message; the IPv4 address field of a received VPN-IPv4 RSVP_HOP MUST be used as the source address for this matching.
In Inter-AS Option A, the new VPN-IPv4/IPv6 objects defined in this document MUST NOT be sent in any RSVP message between two Option-A ASBRs; each ASBR operates as a PE and inter-ASBR links are treated as PE-CE links.
In Inter-AS Option B where ASBRs do not perform admission control, the use of the VPN-IPv4 RSVP_HOP object is REQUIRED so that adjacent PEs can send RSVP messages directly to each other via MPLS encapsulation, bypassing stateless ASBRs.
The ingress PE MUST recognize the IP Router Alert Option in Path messages arriving from a CE and intercept those messages for RSVP processing. This is the only point in the L3VPN where RAO processing is required.
The VPN-IPv4 address carried in a VPN-IPv4 RSVP_HOP object MUST be advertised by the sender into BGP with an associated locally allocated label, and that advertisement MUST be propagated throughout the VPN. Frames received with that label MUST be given to the local control plane for RSVP processing.
VPN-IPv4/IPv6 SESSION, SENDER_TEMPLATE, FILTER_SPEC, and RSVP_HOP objects MUST NOT be included in any RSVP messages sent outside of the provider's backbone, except on inter-AS links in Option-B and Option-C deployments.
When a neighboring RSVP hop receives a message containing a VPN-IPv4 RSVP_HOP object, it MUST encapsulate any reply message with the BGP label associated with the VPN-IPv4 address and forward it via MPLS to the BGP next hop. If the received RSVP_HOP is a plain IPv4 object, the reply is IP-encapsulated instead.
Backbone admission control is achieved by establishing MPLS-TE tunnels between ingress and egress PEs (per RFC 4804), treating each tunnel as a virtual link with a capacity. Individual per-customer reservations are mapped onto aggregate tunnel reservations; packets subject to backbone admission control are distinguished by a specific MPLS EXP value.
The VPN-IPv4 RSVP_HOP object (Class=3, C-Type=5) carries both a standard IPv4 next/previous hop address and a VPN-IPv4 address (12 bytes). The sender MUST advertise the VPN-IPv4 address into BGP with an associated label; a receiving RSVP neighbor uses that label to MPLS-encapsulate reply messages, enabling reachability between PEs separated by Option-B ASBRs without requiring direct IP reachability.
IANA assigned new C-Types in the RSVP parameters registry: SESSION class (1) gets C-Types 19–24 (VPN-IPv4, VPN-IPv6, AGGREGATE-VPN-IPv4, AGGREGATE-VPN-IPv6, GENERIC-AGGREGATE-VPN-IPv4, GENERIC-AGGREGATE-VPN-IPv6); SENDER_TEMPLATE class (11) and FILTER_SPEC class (10) each get C-Types 14–17; RSVP_HOP class (3) gets C-Types 5–6 (VPN-IPv4, VPN-IPv6).
IANA assigned PathError Code 37 ('RSVP over MPLS Problem') with sub-code value 1 ('RSVP_HOP not reachable across VPN'), used by Option-B ASBRs to signal that a received IPv4 RSVP_HOP object cannot provide reachability across the VPN.
A PE SHOULD support mechanisms to rate-limit the fraction of its CPU and memory resources consumed by RSVP messages from any single CE or customer, to prevent a denial-of-service attack where a malicious customer overwhelms the PE with excessive RSVP signaling.
It is RECOMMENDED that PE implementations support local policy to limit the total backbone resources reservable by a given customer or CE. A VPN-IPv4 RSVP_HOP address used for RSVP signaling MUST NOT be redistributed to or made reachable by any CE; a dedicated 'control-plane VPN' carrying route targets not imported into customer VRFs is one way to ensure isolation.
The backbone admission control procedures in Section 4 (using PE-PE MPLS TE tunnels) are incompatible with PE-PE IPsec, because they depend on PE-PE MPLS TE tunnels for aggregate reservations. The PE-CE admission control procedures in Section 3 are compatible with PE-PE IPsec. CE-CE IPsec is handled via RFC 4923 hierarchical RSVP reservation over IPsec tunnels.
Path message processing at egress PE: (1) message arrives addressed to PE itself; (2) extract RD and IPv4 address from VPN-IPv4 SESSION to determine local VRF; (3) store incoming message and VRF as Path state; (4) reconstruct Path with original IPv4 destination, plain IPv4 SESSION/SENDER_TEMPLATE (RD stripped), and standard RSVP_HOP with PE outgoing interface address; (5) forward with Router Alert Option toward receiver.
Path message processing at ingress PE: (1) identify VRF from incoming interface; (2) store Path state associated with VRF; (3) look up receiver address in VRF to find egress PE (BGP next hop); (4) construct new VPN-IPv4 SESSION (with RD from VPN-IPv4 route) and VPN-IPv4 SENDER_TEMPLATE; (5) send new Path addressed to egress PE loopback, without Router Alert Option, with VPN-IPv4 RSVP_HOP.
AGGREGATE-VPN-IPv4 SESSION object (Class=1, C-Type=21): 12-byte VPN-IPv4 DestAddress, Reserved (1 byte), Flags (1 byte), Reserved (1 byte), and DSCP (1 byte). GENERIC-AGGREGATE-VPN-IPv4 (C-Type=23) additionally carries PHB-ID (2 bytes), vDstPort (2 bytes), and Extended vDstPort (4 bytes).
VPN-IPv4 RSVP_HOP object (Class=3, C-Type=5): 4-byte IPv4 Next/Previous Hop Address, 12-byte VPN-IPv4 Next/Previous Hop Address, and 4-byte Logical Interface Handle. VPN-IPv6 RSVP_HOP (C-Type=6) uses a 16-byte IPv6 address followed by a 24-byte VPN-IPv6 address plus 4-byte LIH.
VPN-IPv4 SENDER_TEMPLATE and FILTER_SPEC objects (Class=11/10, C-Type=14): 12-byte VPN-IPv4 SrcAddress, 2-byte Reserved (MUST be zero on transmit, ignored on receipt), and 2-byte SrcPort. VPN-IPv6 variants (C-Type=15) use a 24-byte VPN-IPv6 SrcAddress.
VPN-IPv4 SESSION object (Class=1, C-Type=19): 12-byte VPN-IPv4 DestAddress (8-byte Route Distinguisher + 4-byte IPv4 address per RFC 4364), followed by Protocol ID (1 byte), Flags (1 byte), and DstPort (2 bytes). VPN-IPv6 SESSION (C-Type=20) uses a 24-byte VPN-IPv6 DestAddress.