RFC 5824
Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN
Okay bestie, let's get into RFC 5824 🎀
This one is an Informational doc from the IETF stream, with ISSN 2070-1721, dated April 2010. K. Kumaki (KDDI Corporation) is the editor, and R. Zhang (BT) and Y. Kamite (NTT Communications Corporation) are also on the author list 💅. The title is "Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN" ✨. The header doesn't list anything it obsoletes or updates, so it stands on its own 🦋.
Abstract
Customers are obsessed with running triple-play services through BGP/MPLS IP-VPNs right now 📺☎️. Some service providers want to offer services that ask for Quality of Service (QoS) guarantees from a local Customer Edge (CE) all the way to a remote CE across the network. So the application needs, like end-to-end QoS and reserving an adequate bandwidth for voice, video, or a bandwidth-guaranteed data pipe, just keep climbing 🔥.
Providers can use both an MPLS and an MPLS Traffic Engineering (MPLS-TE) Label Switched Path (LSP) to hit their service goals 🎯. This document lays out what service providers need in order to support a customer Resource ReSerVation Protocol (RSVP) and RSVP-TE over a BGP/MPLS IP-VPN 🫶.
Status of This Memo
Ngl this part is a lot, but it matters 🥹. This document is not an Internet Standards Track specification. It's published for informational purposes 🌸.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 💜. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that 📚.
For the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc5824 🔗.
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 they stand on the publication date. Please read them carefully, because they explain your rights and restrictions for this document 👀. Code Components pulled out of 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 granted the IETF Trust the right to allow changes outside the IETF Standards Process 😤. So unless you get an adequate license from those copyright holders, this document can't be modified outside the IETF Standards Process, and derivative works of it can't be created outside the IETF Standards Process either. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍.
Table of Contents
1. Introduction ....................................................4
2. Requirements Language ...........................................4
3. Terminology .....................................................5
4. Problem Statement ...............................................5
5. Application Scenarios ...........................................7
5.1. Scenario I: Fast Recovery over BGP/MPLS IP-VPNs ............8
5.2. Scenario II: Strict C-TE LSP QoS Guarantees ................8
5.3. Scenario III: Load Balance of CE-to-CE Traffic .............9
5.4. Scenario IV: RSVP Aggregation over MPLS-TE Tunnels ........11
5.5. Scenario V: RSVP over Non-TE LSPs .........................12
5.6. Scenario VI: RSVP-TE over Non-TE LSPs .....................13
6. Detailed Requirements for C-TE LSP Model .......................14
6.1. Selective P-TE LSPs .......................................14
6.2. Graceful Restart Support for C-TE LSPs ....................14
6.3. Rerouting Support for C-TE LSPs ...........................15
6.4. FRR Support for C-TE LSPs .................................15
6.5. Admission Control Support on P-TE LSP Head-Ends ...........15
6.6. Admission Control Support for C-TE LSPs in
LDP-Based Core Networks ...................................16
6.7. Policy Control Support for C-TE LSPs ......................16
6.8. PCE Features Support for C-TE LSPs ........................16
6.9. Diversely Routed C-TE LSP Support .........................16
6.10. Optimal Path Support for C-TE LSPs .......................17
6.11. Reoptimization Support for C-TE LSPs .....................17
6.12. DS-TE Support for C-TE LSPs ..............................17
7. Detailed Requirements for C-RSVP Path Model ....................18
7.1. Admission Control between PE-CE for C-RSVP Paths ..........18
7.2. Aggregation of C-RSVP Paths by P-TE LSPs ..................18
7.3. Non-TE LSP Support for C-RSVP Paths .......................18
7.4. Transparency of C-RSVP Paths ..............................18
8. Commonly Detailed Requirements for Two Models ..................18
8.1. CE-PE Routing .............................................18
8.2. Complexity and Risks ......................................19
8.3. Backward Compatibility ....................................19
8.4. Scalability Considerations ................................19
8.5. Performance Considerations ................................19
8.6. Management Considerations .................................20
9. Security Considerations ........................................20
10. References ....................................................21
10.1. Normative References .....................................21
10.2. Informative References ...................................22
Acknowledgments....................................................23
Appendix A. Reference Model........................................24
A.1 End-to-End C-RSVP Path Model................................24
A.2 End-to-End C-TE LSP Model...................................251. Introduction ✨
Some service providers want to build a service that guarantees Quality of Service (QoS) and a bandwidth from a local Customer Edge (CE) to a remote CE through the network 🚀. A CE is the network client equipment owned and operated by the service provider. Heads up though: the CE might not be part of the MPLS provider network 👀.
Customers expect triple-play services like Internet access, telephone, and television through BGP/MPLS IP-VPNs [RFC4364] 📞📺🌐.
As these services evolve, the requirements for end-to-end QoS to meet application needs keep growing too 📈. Depending on the application (voice, video, a bandwidth-guaranteed data pipe, and so on), you might need a native IP using RSVP, or an end-to-end constrained MPLS Traffic Engineering (MPLS-TE) Label Switched Path (LSP), or both 🧩. The RSVP path can provide QoS guarantees and reserve an adequate bandwidth for the data 💖. An end-to-end MPLS-TE LSP can guarantee bandwidth too, and it unlocks extra stuff like MPLS fast reroute (FRR) [RFC4090]. That keeps the service going around node and link failures, including failures on the CE-PE link 🛟. It's worth noting that an RSVP session between two CEs can also be mapped and tunneled into an MPLS-TE LSP across an MPLS provider network 🦋.
This model has a couple of perks. First, customers can use these network services while using both private addresses and global addresses 🌸. Second, the traffic gets tunneled through the service-provider backbone, so customer traffic and route confidentiality are maintained 🔐.
This document defines a reference model, example application scenarios, and detailed requirements for a solution that supports a customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN 🎀.
A specification for a solution is out of scope in this document 🙅♀️.
2. Requirements Language
Okay, the key words in this doc are the important ones 🔑. "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119] 💅.
3. Terminology
The BGP/MPLS IP-VPN terms come from [RFC4364], and the Path Computation Element (PCE) terms come from [RFC4655] 🧠. Here's the glossary, bestie 📝:
TE LSP: Traffic Engineering Label Switched PathMPLS-TE LSP: Multiprotocol Label Switching TE LSPC-RSVP path: Customer RSVP path: a native RSVP path with the bandwidth reservation of X for customers 🌷C-TE LSP: Customer Traffic Engineering Label Switched Path: an end-to-end MPLS-TE LSP for customers 💜P-TE LSP: Provider Traffic Engineering Label Switched Path: a transport TE LSP between two Provider Edges (PEs) 🧚LSR: a Label Switched RouterHead-end LSR: an ingress LSRTail-end LSR: an egress LSR
4. Problem Statement ✨
okay so service providers want to deliver triple-play services with QoS guarantees to their customers 💖 There are a few ways to pull that off. Some providers want to offer fancy advanced services using RSVP signaling for native IP flows (C-RSVP), or RSVP-TE signaling for Customer TE LSPs (C-TE LSPs) over BGP/MPLS IP-VPNs 🎀
here's how each method works:
A C-RSVP path with a bandwidth reservation of X can be used to carry voice traffic 📞 To get recovery in under 50 ms during link, node, and Shared Risk Link Group (SRLG) failures, and to provide strict QoS guarantees, a C-TE LSP with bandwidth X between data centers or customer sites can carry voice and video traffic 🦋 So service providers or customers can pick a C-RSVP path or a C-TE LSP, whichever one meets their requirements 💅
when service providers offer a C-RSVP path between hosts or CEs over BGP/MPLS IP-VPNs, the CE/host asks for an end-to-end C-RSVP path with the bandwidth reservation of X to the remote CE/host. but if C-RSVP signaling is sent within a VPN, the service-provider network is going to hit scalability issues, because routers need to keep the RSVP state for each customer 😭 so to fix the scalability problem, multiple C-RSVP reservations can be aggregated at a PE, where a P-TE LSP head-end can perform admission control using the aggregated C-RSVP reservations 🧚 The method described in [RFC4804] can be considered a useful approach. In this case, a reservation request from within the context of a Virtual Routing and Forwarding (VRF) instance can get aggregated onto a P-TE LSP. The P-TE LSP can be pre-established, resized based on the request, or triggered by the request. Service providers, however, cannot provide a C-RSVP path over the VRF instance as defined in [RFC4364]. The current BGP/MPLS IP-VPN architecture also doesn't support an RSVP instance running in the context of a VRF to process RSVP messages and integrated services (int-serv) ([RFC1633], [RFC2210]) 🙈 One solution is described in [RSVP-L3VPN].
if service providers offer a C-TE LSP from a CE to a CE over the BGP/MPLS IP-VPN, they need an MPLS-TE LSP from a local CE to a remote CE to be established. but if C-TE LSP signaling is sent within the VPN, the service-provider network may face these scalability issues:
- A C-TE LSP can be aggregated by a P-TE LSP at a PE (i.e., hierarchical LSPs). In this case, only a PE maintains the state of customer RSVP sessions.
- A C-TE LSP cannot be aggregated by a P-TE LSP at a PE, depending on some policies (i.e., continuous LSPs). In this case, both Ps and PEs maintain the state of customer RSVP sessions.
- A C-TE LSP can be aggregated by the non-TE LSP (i.e., LDP). In this case, only a PE maintains the state of customer RSVP-TE sessions. Note that it is assumed that there is always enough bandwidth available in the service-provider core network.
and wait, it gets worse 😩 if service providers provide the C-TE LSP over the BGP/MPLS IP-VPN, they currently can't provide it over the VRF instance as defined in [RFC4364]. Specifically, the current BGP/MPLS IP-VPN architecture doesn't support the RSVP-TE instance running in the context of a VRF to process RSVP messages and trigger the establishment of the C-TE LSP over the service-provider core network. If every C-TE LSP triggers the establishment or resizing of a P-TE LSP, the service-provider network will also face scalability issues from maintaining a large number of P-TE LSPs and/or the dynamic signaling of these P-TE LSPs. Section 8.4 of this document, "Scalability Considerations", provides detailed scalability requirements 📚
so we've got two different models. the differences between C-RSVP paths and C-TE LSPs are:
- C-RSVP path model: data packets among CEs are forwarded by "native IP packets" (i.e., not labeled packets).
- C-TE LSP model: data packets among CEs are forwarded by "labeled IP packets".
depending on the service level and the need to meet specific requirements, service providers should be able to choose P-TE LSPs or non-TE LSPs in the backbone network 🌸 The selection may depend on the service provider's policy and the node's capability to support the mechanisms described.
the items listed below are selectively required to support C-RSVP paths and C-TE LSPs over BGP/MPLS IP-VPNs, based on the service level. For example, some service providers need all of the following items to provide a service, and some only need some of them. It depends on the service level and policy of the service provider. Detailed requirements are described in Sections 6, 7, and 8.
- C-RSVP path QoS guarantees.
- Fast recovery over the BGP/MPLS IP-VPN to protect traffic for the C-TE LSP against CE-PE link failure and PE node failure.
- Strict C-TE LSP bandwidth and QoS guarantees.
- Resource optimization for C-RSVP paths and C-TE LSPs.
- Scalability for C-RSVP paths and C-TE LSPs.
5. Application Scenarios 🌈
the next sections walk through a few application scenarios for C-RSVP paths and C-TE LSPs in BGP/MPLS IP-VPN environments 🦋 Appendix A, "Reference Model", describes a C-RSVP path, a C-TE LSP, and a P-TE LSP.
in every scenario, it's the service provider's job to make sure there's enough bandwidth to meet the customers' application requirements 💖
5.1. Scenario I: Fast Recovery over BGP/MPLS IP-VPNs
in this scenario (see Figure 1), a customer uses a VoIP application between its sites (i.e., between CE1 and CE2). H0 and H1 are the voice equipment 📞
here the customer sets up C-TE LSP1 as the primary path and C-TE LSP2 as the backup path. If the link between PE1 and CE1 or the node PE1 fails, C-TE LSP1 needs C-TE LSP2 as a path protection 🛟
generally speaking, customers use C-RSVP paths, and service providers use P-TE LSPs 👑
C-TE LSP1
<---------------------------------------------->
P-TE LSP1
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H0 | |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |H1 |.
. --- --- . --- --- --- --- . --- --- .
.........|... --- --- --- --- ...|.........
+-------|PE3|----|P3 |-----|P4 |----|PE4|-------+
--- --- --- ---
<--------------------------->
P-TE LSP2
<---------------------------------------------->
C-TE LSP2
<--customer--> <--------BGP/MPLS IP-VPN-------> <--customer->
network networkFigure 1. Scenario I
5.2. Scenario II: Strict C-TE LSP QoS Guarantees
in this scenario (see Figure 2), service provider B (SP B) carries voice and video traffic between its sites (i.e., between CE1 and CE2) 🎬 Here SP B sets up C-TE LSP1 with preemption priority 0 and 100-Mbps bandwidth for the voice traffic, and C-TE LSP2 with preemption priority 1 and 200-Mbps bandwidth for the unicast video traffic. Meanwhile, service provider A (SP A) also pre-establishes P-TE LSP1 with preemption priority 0 and 1-Gbps bandwidth for the voice traffic, and P-TE LSP2 with preemption priority 1 and 2-Gbps bandwidth for the video traffic. In this scenario, P-TE LSP1 and P-TE LSP2 should support Diffserv-aware MPLS Traffic Engineering (DS-TE) [RFC4124] 🔥
PE1 and PE3 should choose an appropriate P-TE LSP based on the preemption priority. In this case, C-TE LSP1 must be associated with P-TE LSP1 at PE1, and C-TE LSP2 must be associated with P-TE LSP2 at PE3 💜
also, PE1 and PE3 head-ends should control the bandwidth of C-TE LSPs. In this case, PE1 and PE3 can choose C-TE LSPs by the amount of maximum available bandwidth for each P-TE LSP, respectively ✨
C-TE LSP1
<---------------------------------------------->
P-TE LSP1
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|CE0| |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |CE3|.
. --- --- . --- --- --- --- . --- --- .
.........|... --- --- --- --- ...|.........
+-------|PE3|----|P3 |-----|P4 |----|PE4|-------+
--- --- --- ---
<--------------------------->
P-TE LSP2
<---------------------------------------------->
C-TE LSP2
<---SP B----> <--------BGP/MPLS IP-VPN-------> <---SP B--->
network SP A network networkFigure 2. Scenario II
it's possible that the customer and the service provider have different preemption priorities. In this case, the PE policy overrides the customer's. If the service provider doesn't support preemption priorities, then those priorities should be ignored 🙈
5.3. Scenario III: Load Balance of CE-to-CE Traffic 🎀
okay bestie, scenario III is giving full load-balancing main character energy 💅✨ here service provider C (SP C) is sending voice and video traffic between its sites, so CE0, CE2, CE5, and CE7 are all talking to each other 🌸 H0 and H1 are the voice and video equipment (H0 = voice, H1 = video, iykyk 🎧). SP C sets up C-TE LSP1, C-TE LSP3, C-TE LSP5, and C-TE LSP7 with preemption priority 0 and 100-Mbps bandwidth for the voice traffic 🍓, then sets up C-TE LSP2, C-TE LSP4, C-TE LSP6, and C-TE LSP8 with preemption priority 1 and 200-Mbps bandwidth for the video traffic 🎥
meanwhile SP A pre-establishes P-TE LSP1 and P-TE LSP3 with preemption priority 0 and 1-Gbps bandwidth for the voice traffic, plus P-TE LSP2 and P-TE LSP4 with preemption priority 1 and 2-Gbps bandwidth for the video traffic 🧚 and in this scenario, all four of those P-TE LSPs should support DS-TE [RFC4124] 🔥
every PE should choose an appropriate P-TE LSP based on the preemption priority 👑 and to keep traffic from getting wrecked by one single network failure, the C-TE LSPs are set up as diversely routed paths 🦋 in this case the FRR [RFC4090] is not necessarily required, so no need to panic about it 🙈
unconstrained TE LSPs (aka C-TE LSPs/P-TE LSPs with 0 bandwidth) [RFC5330] are applicable here too 💜
and lowkey the best part: load balancing for any communication between H0 and H1 can be done by setting up full-mesh C-TE LSPs between CE0/CE2 and CE5/CE7 🫶
C-TE LSP1(P=0),2(P=1) (CE0->CE1->...->CE4->CE5)
(CE0<-CE1<-...<-CE4<-CE5)
<---------------------------------------------->
C-TE LSP3(P=0),4(P=1) (CE2->CE1->...->CE4->CE7)
(CE2<-CE1<-...<-CE4<-CE7)
<---------------------------------------------->
P-TE LSP1 (p=0)
<-------------------->
P-TE LSP2 (p=1)
<-------------------->
.................. ..................
. --- --- . --- --- --- --- . --- --- .
. |CE0|-|CE1|--|PE1|--|P1 |---|P2 |--|PE2|--|CE4|-|CE5| .
. --- /--- --- . --- --- --- --- . --- ---\ --- .
.|H0 | + . + . + |H1 |.
. --- \--- --- . --- --- --- --- . --- ---/ --- .
. |CE2|-|CE3|--|PE3|--|P3 |---|P4 |--|PE4|--|CE6|-|CE7| .
. --- --- . --- --- --- --- . --- --- .
.................. ..................
<-------------------->
P-TE LSP3 (p=0)
<-------------------->
P-TE LSP4 (p=1)
<---------------------------------------------->
C-TE LSP5(P=0),6(P=1) (CE0->CE3->...->CE6->CE5)
(CE0<-CE3<-...<-CE6<-CE5)
<---------------------------------------------->
C-TE LSP7(P=0),8(P=1) (CE2->CE3->...->CE6->CE7)
(CE2<-CE3<-...<-CE6<-CE7)
<-----SP C-----> <----BGP/MPLS IP-VPN----> <-----SP C----->
network SP A network network
Figure 3. Scenario III5.4. Scenario IV: RSVP Aggregation over MPLS-TE Tunnels 🌈
in scenario IV (see Figure 4), the customer has two hosts 💻 one is hooked up to CE1 and the other to CE2, and those CEs are connected to PE1 and PE2 inside a VRF instance that belongs to the same VPN ✨ the requesting host (H1) can ask H2 for an RSVP path with a bandwidth reservation of X 🫶
that reservation request, coming from inside the VRF context, gets aggregated onto a pre-established P-TE/DS-TE LSP, following procedures that are similar to [RFC4804] 🦋 just like with [RFC4804], there may be multiple P-TE LSPs belonging to different DS-TE class-types 👑 local policies can be used to map the incoming RSVP path request from H1 to the P-TE LSP with the right class-type, so it's all very customizable 💅
pls note that the end-to-end (e2e) RSVP path request may also be initiated by the CE devices themselves 🙈
C-RSVP path
<----------------------------------------------------->
P-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H1 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H2 |.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
<-customer-> <--------BGP/MPLS IP-VPN-------> <-customer->
network network
Figure 4. Scenario IV5.5. Scenario V: RSVP over Non-TE LSPs 🧚
scenario V (see Figure 5) is a customer with two hosts again 💖 CE1 and CE2 connect to PE1 and PE2, which sit inside a VRF instance belonging to the same VPN 🌸 H1 can request an RSVP path from H2 with a bandwidth reservation of X, same energy as before 🎀 this time a non-TE LSP (i.e., LDP, etc.) is provided between the PEs, and it has LDP, which supports MPLS Diffserv [RFC3270] 🔥
heads up though, this one only gives you Diffserv 🙈 it does NOT give you the bandwidth reservation that RSVP-TE does, so don't mix those up bestie 💀
local policies can be implemented to map the customer's reserved flow to the LSP with the appropriate Traffic Class [RFC5462] at PE1 ✨
C-RSVP path
<------------------------------------------>
Non-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H1 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H2 |.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
<-customer-> <-------BGP/MPLS IP-VPN-------> <-customer->
network network
Figure 5. Scenario V5.6. Scenario VI: RSVP-TE over Non-TE LSPs 📞
in scenario VI (see Figure 6), a customer is using a VoIP app between its sites, specifically between CE1 and CE2 🎧 H0 and H1 are the voice equipment 🍓 here a non-TE LSP means LDP, and the customer sets up C-TE LSP1 as the primary path and C-TE LSP2 as the backup path 🦋
if the link between PE1 and CE1 goes down, or PE1 itself fails, then C-TE LSP1 needs C-TE LSP2 as path protection 😭 that's the glow-up backup plan 💅
C-TE LSP1
<----------------------------------------->
Non-TE LSP
<-------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H0 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H1 |.
. --- --- . --- --- --- --- . --- --- .
.........|... --- --- --- --- ...|.........
+-----|PE3|----|P3 |-----|P4 |----|PE4|-----+
--- --- --- ---
<-------------------------->
Non-TE LSP
<----------------------------------------->
C-TE LSP2
<-customer-> <------BGP/MPLS IP-VPN------> <-customer->
network network
Figure 6. Scenario VI6. Detailed Requirements for the C-TE LSP Model 📋
this section is where the actual rules live, so let's get into it 🫶 it describes detailed requirements for C-TE LSPs in BGP/MPLS IP-VPN environments 💜
6.1. Selective P-TE LSPs 🍓
the solution MUST provide the ability to decide which P-TE LSPs a PE uses for a C-RSVP path and a C-TE LSP 👑 when a PE receives a native RSVP and/or a path message from a CE, it MUST be able to decide which P-TE LSPs it uses 🔥 there are various kinds of P-TE LSPs in the service-provider network, so the PE MUST choose an appropriate P-TE LSP based on local policies such as:
- preemption priority
- affinity
- class-type
- on the data plane: (Differentiated Services Code Point (DSCP) or Traffic Class bits)
6.2. Graceful Restart Support for C-TE LSPs ✨
the solution SHOULD support the graceful restart capability, where the C-TE LSP traffic keeps getting forwarded during a PE graceful restart 🦋 graceful restart mechanisms related to this architecture are described in [RFC3473], [RFC3623], and [RFC4781] 📚
6.3. Rerouting Support for C-TE LSPs 🔄
the solution MUST provide the rerouting of a C-TE LSP in case of link, node, and SRLG failures, or in case of preemption 😤 that rerouting may be controlled by a CE or by a PE, depending on the failure 🧚 in a dual-homed environment, the ability to perform rerouting MUST be provided against a CE-PE link failure or a PE failure, if another CE-PE link or PE is available between the head-end and the tail-end of the C-TE LSP 🌸
6.4. FRR Support for C-TE LSPs 🛡️
the solution MUST support FRR [RFC4090] features for a C-TE LSP over a VRF instance 💅
in BGP/MPLS IP-VPN environments, a C-TE LSP from a CE traverses multiple PEs and Ps, albeit tunneled over a P-TE LSP 🌈 to avoid PE-CE link/PE node/SRLG failures, a CE (a customer's head-end router) needs to support link protection or node protection 🫶
the following protection MUST be supported:
- CE link protection
- PE node protection
- CE node protection
6.5. Admission Control Support on P-TE LSP Head-Ends 🚦
the solution MUST support admission control on a P-TE LSP tunnel head-end for C-TE LSPs 🔥 C-TE LSPs may potentially try to reserve more bandwidth than the P-TE LSP has, so the P-TE LSP tunnel head-end SHOULD control the number of C-TE LSPs and/or the bandwidth of C-TE LSPs 👑 for example, the transport TE LSP head-end SHOULD have a configurable limit on the maximum number of C-TE LSPs that it can admit from a CE 💖 as for the amount of bandwidth that C-TE LSPs can reserve, there could be two situations:
- Let the P-TE LSP do its natural bandwidth admission
- Set a cap on the amount of bandwidth, and have the configuration option to:
- a. Reserve the minimum cap bandwidth or the C-TE LSP bandwidth on the P-TE LSP if the required bandwidth is available
- b. Reject the C-TE LSP if the required bandwidth by the C-TE LSP is not available
6.6. Admission Control Support for C-TE LSPs in LDP-Based Core Networks 🌸
the solution MUST support admission control for a C-TE LSP at a PE in the LDP-based core network 💜 specifically, PEs MUST have a configurable limit on the maximum amount of bandwidth that C-TE LSPs can reserve for a given VRF instance (i.e., for a given customer) 🎀 also, a PE SHOULD have a configurable limit on the total amount of bandwidth that C-TE LSPs can reserve between PEs ✨
6.7. Policy Control Support for C-TE LSPs 🎀
Okay bestie, policy control is the bouncer at the club 💅 The solution MUST support the policy control for a C-TE LSP at a PE.
The PE MUST be able to do all of this:
- Limit the rate of RSVP messages per CE link.
- Accept and map, or reject, requests for a given affinity.
- Accept and map, or reject, requests with a specified setup and/or preemption priorities.
- Accept or reject requests for fast reroutes.
- Ignore the requested setup and/or preemption priorities, and select a P-TE LSP based on a local policy that applies to the CE-PE link or the VRF.
- Ignore the requested affinity, and select a P-TE LSP based on a local policy that applies to the CE-PE link or the VRF.
- Perform mapping in the data plane between customer Traffic Class bits and transport P-TE LSP Traffic Class bits, as signaled per [RFC3270]. 🧚
6.8. PCE Features Support for C-TE LSPs 🦋
Now the PCE stuff 🫶 The solution SHOULD support the PCE architecture for a C-TE LSP establishment in the context of a VRF instance. When a C-TE LSP is provided, CEs, PEs, and Ps may support PCE features ([RFC4655], [RFC5440]).
So in this setup, CE routers or PE routers may be Path Computation Clients (PCCs), and PE routers and/or P routers may be PCEs. Furthermore, the solution SHOULD support a mechanism for dynamic PCE discovery. Specifically, not all PCEs are necessarily discovered automatically, and only specific PCEs that know VPN routes should be discovered automatically. It's giving selective 👑
6.9. Diversely Routed C-TE LSP Support 🌈
The solution MUST provide for setting up diversely routed C-TE LSPs over the VRF instance. These diverse C-TE LSPs MAY be traversing over two different P-TE LSPs that are fully disjoint within a service-provider network. When a single CE has multiple uplinks that connect to different PEs, it is desirable that multiple C-TE LSPs over the VRF instance be established between a pair of LSRs. When two CEs have multiple uplinks that connect to different PEs, it is desirable that multiple C-TE LSPs over the VRF instance be established between two different pairs of LSRs. In these cases, for example, the following points will be beneficial to customers. 💖
- Load balance of the CE-to-CE traffic across diverse C-TE LSPs so as to minimize the traffic disruption in case of a single network element failure.
- Path protection (e.g., 1:1, 1:N).
6.10. Optimal Path Support for C-TE LSPs ⭐
The solution MUST support the optimal path for a C-TE LSP over the VRF instance. Depending on the application (e.g., voice and video), an optimal path is needed for a C-TE LSP over the VRF instance. For a TE LSP, an optimal route may be the shortest path based on the TE metric applied. For a non-TE LSP using LDP, the IGP metric may be used to compute optimal paths. Main character energy for the routes, obviously 🍓
6.11. Reoptimization Support for C-TE LSPs 🔥
The solution MUST support the reoptimization of a C-TE LSP over the VRF instance. These LSPs MUST be reoptimized using "make-before-break" [RFC3209].
In this case, it is desirable for a CE to be configured with regard to the timer-based or event-driven reoptimization. Furthermore, customers SHOULD be able to reoptimize a C-TE LSP manually. For delay-sensitive or jitter-sensitive traffic (i.e., voice traffic), C-TE LSP path computation and route selection are expected to be optimal for the specific application. Voice calls deserve the VIP treatment 🎧
6.12. DS-TE Support for C-TE LSPs 💜
The solution MUST support DS-TE [RFC4124] for a C-TE LSP over the VRF instance. In the event that the service provider and the customer have differing bandwidth constraint models, then only the service-provider bandwidth model should be supported.
Applications with different traffic characteristics are used in BGP/MPLS IP-VPN environments, so it's giving variety 🌸 Service providers try to achieve fine-grained optimization of transmission resources, efficiency, and further-enhanced network performance. It may be desirable to perform TE at a per-class level.
By mapping the traffic from a given Diffserv class of service onto a separate C-TE LSP, DS-TE lets that traffic use the resources available to the given class on both shortest paths and non-shortest paths. It can also follow paths that meet TE constraints specific to that class. Organized, iconic, no notes 💅
7. Detailed Requirements for the C-RSVP Path Model 🦋
This section describes detailed requirements for C-RSVP paths in BGP/MPLS IP-VPN environments. Let's get into it ✨
7.1. Admission Control between PE and CE for C-RSVP Paths 🎀
The solution MUST support admission control at the ingress PE. PEs MUST control RSVP messages per a VRF instance. The bouncer is literally at the door 🚪
7.2. Aggregation of C-RSVP Paths by P-TE LSPs 🧚
The solution SHOULD support C-RSVP paths aggregated by P-TE LSPs. P-TE LSPs SHOULD be pre-established manually or dynamically by operators and MAY be established if triggered by C-RSVP messages. Also, the P-TE LSP SHOULD support DS-TE. Group-project energy between the operators and the tunnels 🫶
7.3. Non-TE LSP Support for C-RSVP Paths 🌈
The solution SHOULD support non-TE LSPs (i.e., LDP-based LSP, etc.). Non-TE LSPs are established by LDP [RFC5036] between PEs and support MPLS Diffserv [RFC3270]. The solution MAY support local policies to map the customer's reserved flow to the LSP with the appropriate Traffic Class at the PE. Plain LSPs can still be cute, no cap 🍓
7.4. Transparency of C-RSVP Paths 💖
The solution SHOULD NOT change RSVP messages from the local CE to the remote CE (Path, Resv, Path Error, Resv Error, etc.). The solution SHOULD allow customers to receive RSVP messages transparently between CE sites. Hands off the messages, bestie 🙈
8. Commonly Detailed Requirements for Two Models 👑
This section describes commonly detailed requirements for C-TE LSPs and C-RSVP paths in BGP/MPLS IP-VPN environments. Both models, one set of vibes ✨
8.1. CE-PE Routing 🌸
The solution SHOULD support the following routing configuration on the CE-PE links with either RSVP or RSVP-TE on the CE-PE link:
- Static routing
- BGP routing
- OSPF
- OSPF-TE (RSVP-TE case only)
8.2. Complexity and Risks 💀
The solution SHOULD avoid introducing unnecessary complexity to the current operating network to such a degree that it would affect the stability and diminish the benefits of deploying such a solution over SP networks. Don't overcomplicate it, babe 🙃
8.3. Backward Compatibility 🦋
The deployment of C-RSVP paths and C-TE LSPs SHOULD avoid impacting existing RSVP and MPLS-TE mechanisms, respectively, but should allow for a smooth migration or co-existence. Old friends and new friends can hang out 🫶
8.4. Scalability Considerations 🔥
The solution SHOULD minimize the impact on network scalability from a C-RSVP path and a C-TE LSP over the VRF instance. As identified in earlier sections, PCE provides a method for offloading computation of C-TE LSPs and helps with the solution scalability.
The solution MUST address the scalability of C-RSVP paths and C-TE LSPs for the following protocols:
- RSVP (e.g., number of RSVP messages, retained state, etc.).
- RSVP-TE (e.g., number of RSVP control messages, retained state, message size, etc.).
- BGP (e.g., number of routes, flaps, overload events, etc.).
8.5. Performance Considerations ⭐
The solution SHOULD be evaluated with regard to the following criteria:
- Degree of path optimality of the C-TE LSP.
- TE LSP setup time.
- Failure and restoration time.
- Impact and scalability of the control plane due to added overhead.
- Impact and scalability of the data/forwarding plane due to added overhead.
8.6. Management Considerations 🎀
The solution MUST address the manageability of C-RSVP paths and C-TE LSPs for the following considerations:
- Need for a MIB module for the control plane (including mapping of P-TE LSPs and C-TE LSPs) and bandwidth monitoring.
- Need for diagnostic tools (this includes traceroute and Ping).
The solution MUST allow routers to support the MIB module for C-RSVP paths and C-TE LSPs per a VRF instance. If a CE is managed by service providers, the solution MUST allow service providers to collect MIB information for C-RSVP paths and C-TE LSPs from the CE per a customer.
Diagnostic tools can detect failures of the control plane and data plane for general MPLS-TE LSPs [RFC4379]. The solution MUST allow routers to be able to detect failures of the control plane and the data plane for C-TE LSPs over a VRF instance.
MPLS Operations, Administration, and Maintenance (OAM) for C-TE LSPs MUST be supported within the context of VRF, except for the above. Monitoring is the whole vibe 🫶
9. Security Considerations 🔒
Any solution should consider the following general security requirements:
- The solution SHOULD NOT divulge the service-provider topology information to the customer network.
- The solution SHOULD minimize the service-provider network's vulnerability to Denial of Service (DoS) attacks.
- The solution SHOULD minimize the misconfiguration of DSCP marking, preemption, and holding priorities of the customer traffic.
The following additional security issues for C-TE LSPs relate to both the control plane and the data plane.
Okay, this part is seriously important 😭 Security is not the place for vibes-only energy.
In terms of the control plane, in both the C-RSVP path and C-TE LSP models, a PE receives IPv4 or IPv6 RSVP control packets from a CE. If the CE is a router that is not trusted by service providers, the PE MUST be able to limit the rate and number of IPv4 or IPv6 RSVP control packets.
In terms of the data plane, in the C-TE LSP model, a PE receives labeled IPv4 or IPv6 data packets from a CE. If the CE is a router that is not trusted by service providers, the PE MUST be able to limit the rate of labeled IPv4 or IPv6 data packets. If the CE is a trusted router for service providers, the PE MAY be able to limit the rate of labeled IPv4 or IPv6 data packets. Specifically, the PE must drop MPLS-labeled packets if the MPLS label was not assigned over the PE-CE link on which the packet was received. The PE must also be able to police traffic to the traffic profile associated with the LSP on which traffic is received on the PE-CE link.
Moreover, flooding RSVP/RSVP-TE control packets from malicious customers must be avoided. Therefore, a PE MUST isolate the impact of such customers' RSVP/RSVP-TE packets from other customers. Nobody gets to spam the whole network 💅
In the event that C-TE LSPs are diversely routed over VRF instances, the VRF should indicate to the CE how such diversity was provided. Transparency is everything 🦋
10. References ✨
10.1. Normative References
- [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. 🦋
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 💅
- [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 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. 🎀
- [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002. 💜
- [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 🧚
- [RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003. 🌈
- [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. ⭐
- [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005. 🍓
- [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. 👑
- [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 🔥
- [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. 🫶
- [RFC4781] Rekhter, Y. and R. Aggarwal, "Graceful Restart Mechanism for BGP with MPLS", RFC 4781, January 2007. ✨
- [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007. 🌸
- [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009. 💖
10.2. Informative References
- [RSVP-L3VPN] Davie, B., Le Faucheur, F., and A. Narayanan, "Support for RSVP in Layer 3 VPNs", Work in Progress, November 2009. 🦋
- [RFC4804] Le Faucheur, F., Ed., "Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", RFC 4804, February 2007. 🎀
- [RFC5330] Vasseur, JP., Ed., Meyer, M., Kumaki, K., and A. Bonda, "A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link", RFC 5330, October 2008. 💅
- [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. 🌈
11. Acknowledgments 🫶
Big thank-you bestie moment 💖 The authors want to shout out Nabil Bitar, David McDysan, and Daniel King for their super helpful and useful comments and feedback. They made this so much better ✨
Appendix A. Reference Model 🧚
In this appendix, we get into the C-RSVP path, the C-TE LSP, and the P-TE LSP, so you can see how they all fit together 👀
Before we start, every scenario in this appendix assumes the following:
- A P-TE LSP is established between PE1 and PE2. This LSP is used by the VRF instance to forward customer packets within a BGP/MPLS IP-VPN. 🎀
- The service provider has ensured that enough bandwidth is available to meet the service requirements. 💅
A.1. End-to-End C-RSVP Path Model
Okay so, a C-RSVP path and a P-TE LSP are shown in Figure 7, in the context of a BGP/MPLS IP-VPN. A P-TE LSP may be a non-TE LSP (i.e., LDP) in some cases. Ngl, with a non-TE mechanism it can be tricky to guarantee an end-to-end bandwidth, because resources are shared 😭
CE0/CE1 asks for an e2e C-RSVP path to CE3/CE2 with a bandwidth reservation of X. At PE1, that reservation request, received in the context of a VRF, gets aggregated onto a pre-established P-TE LSP, or it triggers the establishment of a new P-TE LSP. Also, C-RSVP sessions across different BGP/MPLS IP-VPNs can be aggregated onto the same P-TE LSP between the same PE pair, which is seriously scalable 🔥 [RFC4804] defines this scenario in more detail.
The RSVP control messages (for example, an RSVP PATH message and an RSVP RESV message) that get exchanged among CEs are forwarded by IP packets through the BGP/MPLS IP-VPN. Once CE0 and/or CE1 receive a reservation message from CE2 and/or CE3, CE0/CE1 establishes a C-RSVP path through the BGP/MPLS IP-VPN. Iconic 🌸
C-RSVP path
<------------------------------------------>
P-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|CE0| |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |CE3|.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
<-customer-> <------BGP/MPLS IP-VPN------> <-customer->
network network
or or
another another
service-provider service-provider
network network
Figure 7. e2e C-RSVP Path ModelA.2. End-to-End C-TE LSP Model
Now, a C-TE LSP and a P-TE LSP are shown in Figure 8, in the context of a BGP/MPLS IP-VPN. A P-TE LSP may be a non-TE LSP (i.e., LDP) in some cases. Like we just covered, it can be hard to guarantee an end-to-end QoS in some cases 🥺
CE0/CE1 asks for an e2e TE LSP path to CE3/CE2 with a bandwidth reservation of X. At PE1, that reservation request, received in the context of a VRF, gets aggregated onto a pre-established P-TE LSP, or it triggers the establishment of a new P-TE LSP. C-TE LSPs across different BGP/MPLS IP-VPNs can also be aggregated onto the same P-TE LSP between the same PE pair, for even more scalability 💜
The RSVP-TE control messages (for example, an RSVP PATH message and an RSVP RESV message) that get exchanged among CEs are forwarded by a labeled packet through the BGP/MPLS IP-VPN. After CE0 and/or CE1 receive a reservation message from CE2 and/or CE3, CE0/CE1 establishes a C-TE LSP through the BGP/MPLS IP-VPN.
And finally, a P-TE LSP is established between PE1 and PE2. This LSP is used by the VRF instance to forward customer packets within the BGP/MPLS IP-VPN. 🌈
C-TE LSP
<------------------------------------------------------->
or
C-TE LSP
<----------------------------------------->
P-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|CE0| |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |CE3|.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
<-customer-> <-------BGP/MPLS IP-VPN-------> <-customer->
network network
or or
another another
service-provider service-provider
network network
Figure 8. e2e C-TE LSP ModelAuthors' Addresses 🦋
Kenji Kumaki (Editor)
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku
Tokyo 102-8460, JAPAN
EMail: ke-kumaki@kddi.com
Raymond Zhang
BT
Farady Building, PP1.21
1 Knightrider Street
London EC4V 5BT
UK
EMail: raymond.zhang@bt.com
Yuji Kamite
NTT Communications Corporation
Granpark Tower
3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
EMail: y.kamite@ntt.comThat's the whole RFC, bestie! 🌈💖 Every single detail is still here, and that's a wrap 💅✨
📦 where this page comes from
- ietf: rfc5824 2010-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms