RFC 6601
Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks
RFC 6601: Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks ✨
Okay bestie, this is RFC 6601 🎀 It's an Experimental document from April 2012, written by G. Ash, Ed. (AT&T) and D. McDysan (Verizon). It's published under ISSN 2070-1721. The title block doesn't list any RFCs that it obsoletes or updates, so it's a standalone experiment 🦋 It's about getting networks to say "no" to new calls before they wreck the calls that are already happening 💅
Abstract
Okay so this document lays out a generic connection admission control (GCAC) reference model and algorithm for IP-/MPLS-based networks 🌸 Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, and the main example is rejecting Voice over IP (VoIP) calls when adding one more call would hurt the calls already going on 📞 Without MPLS GCAC, connections on congested links get degraded quality, and that's giving bad vibes 😭
Vendors can implement the MPLS GCAC algorithm optionally, and service providers can deploy it 🧚 It works between vendor equipment and across multiple service provider domains 🫶 It uses existing mechanisms for MPLS-based networks, like RSVP, Diffserv-aware MPLS Traffic Engineering (DS-TE), Path Computation Element (PCE), Next Steps in Signaling (NSIS), Diffserv, and OSPF ✨ It does not include the parts of CAC that vendors might treat as proprietary, such as detailed path selection mechanisms 🔒
The functions are distributed across the network to deliver the objective Quality of Service (QoS) for specified QoS constraints 💜 The goal is that the source can compute a source route that very likely gets admitted by the via-elements along the selected path 👑 In some cases, like when multiple Autonomous Systems (ASes) are involved, that goal can't always be met, but this document summarizes methods that partially meet it 🥹 MPLS GCAC applies to any service or flow that needs an objective QoS (delay, jitter, packet loss rate) for a specified quantity of traffic 🌈
Status of This Memo ✨
This document is not an Internet Standards Track specification 🙈 It's published for examination, experimental implementation, and evaluation.
It defines an Experimental Protocol for the Internet community 🦋 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) 💅 Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 📚
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6601 🌸
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 💖
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document 📜 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided 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 person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, 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, except to format it for publication as an RFC or to translate it into languages other than English 🌈
Table of Contents 🧾
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................5
2. MPLS GCAC Reference Model and Algorithm Summary .................6
2.1. Inputs to MPLS GCAC ........................................8
2.2. MPLS GCAC Algorithm Summary ................................9
3. MPLS GCAC Algorithm ............................................12
3.1. Bandwidth Allocation Parameters ...........................12
3.2. GCAC Algorithm ............................................15
4. Security Considerations ........................................18
5. Acknowledgements ...............................................20
6. Normative References ...........................................20
7. Informative References .........................................21
Appendix A: Example MPLS GCAC Implementation Including Path
Selection, Bandwidth Management, QoS Signaling, and
Queuing ...............................................24
A.1 Example of Path Selection and Bandwidth Management
Implementation .............................................26
A.2 Example of QoS Signaling Implementation ....................32
A.3 Example of Queuing Implementation ..........................341. Introduction ✨
Okay so this is the same big-picture idea as the abstract: a generic connection admission control (GCAC) reference model and algorithm for IP-/MPLS-based networks 💅 Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism. As one motivating example, it lets them reject Voice over IP (VoIP) calls when extra calls would hurt calls already in progress 📞 Without MPLS GCAC, connections on congested links suffer degraded quality 😭 Given the capital constraints in some SP networks, over-provisioning is not acceptable 💸 MPLS GCAC supports all access technologies, protocols, and services while meeting performance objectives with a cost-effective solution, and it works across routing areas, autonomous systems, and service provider boundaries 🦋
This document defines an MPLS GCAC reference model, algorithm, and functions. They're implemented in one or more types of network elements in different domains, and they work together in a distributed way to deliver the objective QoS for specified QoS constraints, such as bandwidth 🧚 With MPLS GCAC, the source router/server can compute a source route that very likely gets admitted by the via-elements along the selected path 👑 MPLS GCAC includes nested CAC actions, like RSVP aggregation, nested RSVP - Traffic Engineering (RSVP-TE) for scaling between provider edge (PE) routers, and pseudowire (PW) CAC inside traffic-engineered tunnels 🌸 It focuses on MPLS and PW-level CAC functions, not application-level CAC functions 🎀
MPLS GCAC applies to any service or flow that needs an objective QoS (latency, delay variation, loss) for a specified quantity of traffic 🌈 That includes most real-time/RTP services, like voice and video, plus some non-real-time services 📹 Real-time/RTP services are usually interactive, fairly persistent traffic flows 💜 Other services that can use MPLS GCAC include manually provisioned label switched paths (LSPs) or PWs, and automatic bandwidth assignment for applications that automatically build LSP meshes among PE routers 🫶 It works for both access and backbone networks, like slow-speed access networks and broadband DSL, cable, and fiber access networks 🍓
This document is Experimental, and the idea is that service providers and vendors try out the GCAC concept and the algorithm in a controlled way to find out whether the mechanism actually helps 🧪 The careful move is to try it in their labs and test networks first 🔬 When they test in live networks, they should install the GCAC algorithm on selected routers in only part of the network, and they should watch the effects closely 👀 The rollout should be managed so the routers can be switched back to normal operation quickly if any problem shows up 🚨
Since GCAC is most likely to be used in Enterprise VPNs and/or internal TE infrastructure, it is RECOMMENDED that the experiment be conducted in those settings. It is NOT RECOMMENDED that the experiment be conducted in the Internet. If possible, the experimental configuration will address interoperability issues, such as the use of different constraint models across different traffic domains 🙅♀️
The experiment can monitor various quality of service measures before and after GCAC is deployed, especially when the experimental network is under stress during an overload or failure 💥 Those measures might include the dropped packet rate and end-to-end packet delay 📉 The results may be fed back to the IETF community to refine this document and move it to the Standards Track (probably within the MPLS working group), but only if the experimental results are positive 🤞
Here's the real talk 🫣 The algorithm might have negative effects on live deployments if the experiment fails. Those effects might include blocking traffic that would normally be handled, or congestion from letting too much traffic onto a link 😬 For that reason, experimenting in production networks needs to be handled with caution, as described above, and it should only happen after successful simulation and experimentation in test environments 💅 Section 2 describes the MPLS GCAC reference model, and Section 3 specifies the MPLS GCAC algorithm based on the principles in the reference model and requirements 📚 Appendix A gives an example implementation covering path selection, bandwidth management, QoS signaling, and queuing 🎀
1.1. Conventions Used in This Document 🧠
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. These are the official requirement words, so they're capitalized on purpose and mean exactly what RFC 2119 says 💜
2. MPLS GCAC Reference Model and Algorithm Summary ✨
Okay bestie, let's look at the big picture first. Figure 1 shows the reference model for the MPLS GCAC algorithm 🦋
,-. ,-.
,--+ `--+--'- --'\
+----+_____+------+ { +----+ +----+ `. +------+
|GEF1| | |______| P |___| P |______| |
| |-----| PE1 | { +----+ +----+ /+| PE2 |
| | | |==========================>| ASBR |
+-:--+ | |<==========================| |
_|..__ +------+ { DS-TE/MAR Tunnels ; +------+
_,' \-| ./ -'._ !|
| Access \ / +----+ \, !|
| Network | \_ | P | | !|
| / `| +----+ / !|
`--. ,.__,| | IP/MPLS Network / !|
'`' '' ' .._,,'`.__ _/ '---' !|
| '`''' !|
C1 !|
,-. ,-. !|
,--+ `--+--'- --'\ !|
+----+_____+------+ { +----+ +----+ `. +------+
|GEF2| | |______| P |___| P |______| |
| |-----| PE4 | { +----+ +----+ /+| PE3 |
| | | |==========================>| ASBR |
+-:--+ | |<==========================| |
_|..__ +------+ { DS-TE/MAM Tunnels ; +------+
_,' \-| ./ -'._
| Access \ / +----+ \,
| Network | \_ | P | |
| / `| +----+ /
`--. ,.__,| | IP/MPLS Network /
'`' '' ' .._,,'`.__ _/ '---'
| '`'''
C2
CUSTOMER I/F PARAMETERS: BW, QoS, CoS, priority
NOTE: PE, P, ASBR, GEF elements all support GCFs
LEGEND:
---------
ASBR: Autonomous System Border Router
BW: bandwidth
CoS: class of service
DS-TE: Diffserv-aware MPLS Traffic Engineering
GCAC: generic connection admission control
GCF: GCAC core function
GEF: GCAC edge function
I/F: interface
MAM: Maximum Allocation Model
MAR: Maximum Allocation with Reservation
P: provider router
PE: provider edge router
--- connection signaling
___ bearer/media flows
Figure 1: MPLS GCAC Reference ModelMPLS GCAC is applicable to any service or flow that needs MPLS GCAC to meet a given QoS 💅. So the reference model fits most real-time/RTP services (voice, video, etc.) and some non-real-time ones too 📞. Real-time/RTP services are usually interactive, fairly persistent flows, which is very on-brand for them 🌸. Non-real-time apps that can use MPLS GCAC include, for example, manually provisioned LSPs or PWs, plus automatic bandwidth assignment for apps that build LSP meshes among PE routers automatically 🧚. The model also covers MPLS GCAC when MPLS runs in access networks, like slow-speed access networks and broadband DSL, cable, and fiber access networks 🌈. The endpoints are IP/PBXs (Private Branch Exchanges) and individual-usage SIP/RTP end devices (hard and soft SIP phones, Integrated Access Devices (IADs)) 💜. This traffic enters and leaves the core through access networks that may be bandwidth-constrained 🍓. Those access networks may also be MPLS aware, but they may use some other admission control technology too 🫶.
The basic elements in the reference model are the MPLS GCAC edge function (GEF), the GCAC core functions (GCFs), the PE routers, Autonomous System Border Routers (ASBRs), and provider (P) routers ⭐. As Figure 1 shows, the GEF talks to the application at the source and destination PE, and the GCF lives at the PE, P, and ASBR routers 🦋. The GEF has an end-to-end focus: it decides whether individual connection requests fit within an MPLS tunnel 🎀. The GCF has a hop-by-hop focus: it decides whether an MPLS tunnel can be established across specific core network elements on a path 🔥. The GEF functionality may be implemented in the PE, the ASBR, or a stand-alone network element ✨. The source/destination routers (or external devices through a router interface) support both GEF and GCF, while internal routers (or external devices through a router interface) support GCF 👑. In Figure 1, the GEF handles both signaling and bearer control 💖.
2.1. Inputs to MPLS GCAC 🎀
Okay, now the inputs! 🧁 Inputs to the GEF and GCF include the following. Most of them are inputs to both the GEF and the GCF, except where noted. Most of the parameters apply to the specific flow/LSP being calculated, but some, like request type, apply to the calculation method itself 💅. Required inputs are marked with *, and everything else is optional 🫶.
Traffic Description
*Bandwidth per DS-TE class type [RFC4124] (GEF, GCF)*Bandwidth for LSP from [RFC3270] (GEF, GCF)*Aggregated RSVP bandwidth requirements from [RFC4804] (GEF)- Variance Factor (GEF, GCF)
Class of Service (CoS) and Quality of Service (QoS)
*Class Type (CT) from [RFC4124] (GEF, GCF)
Priority
- Admission priority (high, normal, best effort) from NSIS/Y.1541 [RFC5971][RFC5974][RFC5975][RFC5976] (GEF, GCF)
- Preemption priority from [RFC4124] (GEF, GCF)
Request type
- Primary tunnel (GEF, GCF)
- Backup tunnel and fraction of capacity reserved for backup (GEF, GCF)
Oversubscription method (see [RFC3270])
- Over/undersubscribe requested capacity (GEF, GCF)
- Over/undersubscribe available bandwidth (GEF, GCF)
These inputs can come in from a signaling interface (like SIP or H.323), from RSVP, or from an NMS 🌸. They can also be derived from measured traffic levels or from somewhere else entirely 💜.
2.2. MPLS GCAC Algorithm Summary ✨
Okay bestie, Figure 1 is the reference model for MPLS GCAC, and it shows the GEF to GEF MPLS GCAC algorithm that works out whether there's enough bandwidth to finish a connection 💅. The originating GEF gets a connection request with all the input parameters from above over the input interface, for example through an RSVP bandwidth request as specified in [RFC4804]. Then the GEF does three things 🫶:
- a) It figures out whether there's enough bandwidth on the route between the originating and terminating GEFs, by talking through routing and signaling with the GCFs at the P, PE, and ASBR network elements along the path so the connection fits.
- b) It communicates the accept/reject decision on the input interface for the connection request.
- c) It keeps account of network resource allocations by tracking bandwidth use and allocations per CoS.
Optionally, the GEF can dynamically adjust the tunnel size by signaling with the GCFs at nodes along the candidate paths 🦋. For example, the GEF could:
- a) maintain per-CoS tunnel capacity based on aggregated connection requests, and respond on a connection-by-connection basis based on the available capacity,
- b) periodically adjust the tunnel capacity upward when needed, and downward when spare capacity exists in the tunnel, and
- c) use a 'make before break' mechanism to adjust tunnel capacity, so the bearer traffic gets disrupted as little as possible 🌸.
In the reference model, DS-TE [RFC4124] tunnels are configured between the GEFs based on the traffic forecast and current network utilization 🧚. These guaranteed bandwidth DS-TE tunnels are created using RSVP-TE [RFC3209]. DS-TE bandwidth constraints models get applied uniformly within each domain, such as the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model [RFC4126], the Maximum Allocation Model (MAM) [RFC4125], and the Russian Dolls Model (RDM) [RFC4127]. An IGP such as OSPF or IS-IS is used to advertise bandwidth availability by CT, so the GCF can work out MPLS tunnel bandwidth allocation and admission on core (backbone) links. These DS-TE tunnels are configured based on the forecasted traffic load, and when needed, LSPs for different CTs can take different paths 🍓.
As described in Section 3, the unreserved link bandwidth on CTc on link k (ULBCck) is the only bandwidth allocation parameter that must be available to the MPLS GCAC algorithm 👑. Now, if a connection gets set up across multiple service provider networks, meaning across multiple routing domains/autonomous systems (ASes), there are several options for implementing MPLS GCAC 🌈:
- Use [OIF-E-NNI] to advertise
ULBCckparameters to the originating GEF, for the full topology of adjacent domains/areas/ASes, as described in Section 3.3.2.1.2 of [OIF-E-NNI]. Note that the option of abstract node summarization described in [OIF-E-NNI] will not suffice, because summarizing results in loss of topology and capacity usage information 🙈. This way, the originating GEF can implement the MPLS GCAC algorithm described in Section 3 across multiple domains/areas/ASes. - Use [BGP-TE] to advertise
ULBCckparameters via BGP to the originating GEF for the full topology of adjacent domains/areas/ASes. This way, the originating GEF can implement the MPLS GCAC algorithm described in Section 3 across multiple domains/areas/ASes. However, network providers may be reluctant to divulge full topology and capacity usage information to other providers. Furthermore, [BGP-TE] was never intended to provide full TE topology distribution across ASBRs. Such a mechanism would be neither stable nor scalable 💀. - Use individual AS control and MPLS crankback [RFC4920] to retain originating GEF control. For example, in Figure 1, if a connection crosses the two ASes shown (call them AS1 and AS2), the source GEF1 applies the GCAC algorithm described in Section 3 to the links in AS1, that is, between PE1 and PE2/ASBR in Figure 1. Then, in AS2, the GCF in PE3/ASBR applies the MPLS GCAC algorithm to the links in AS2, that is, between PE3 and PE4 in Figure 1. If the flow is rejected in AS2, crankback signaling is used to inform GEF1. When routing a connection across multiple ASes, e.g., across
AS1-->AS2-->AS3, if the flow is rejected, say in AS2, the originating GEF1 can seek an alternate route, perhapsAS1-->AS4-->AS3. This option does not achieve full originating GEF control with the desired full topology visibility across ASes, but it avoids possible issues with obtaining full topology visibility across ASes 🎀. - Use Path Computation Elements (PCEs) [RFC4655] across multiple ASes. PCEs could potentially execute the GCAC algorithm within each AS and communicate/interwork across domains to determine which high-level path can supply the requested bandwidth ✨.
In the reference model, the GEFs implement RSVP aggregation [RFC4804] for scalability 💜. The GEF RSVP aggregator keeps a running total of bandwidth usage on the DS-TE tunnel, adding the bandwidth requirements during connection setup and subtracting them during connection teardown. The aggregator determines whether or not there is sufficient bandwidth for the connection from that originating GEF to the destination GEF. The destination GEF also checks whether there is enough bandwidth on the DS-TE tunnel from the destination GEF to the originating GEF. The aggregate bandwidth usage on the DS-TE tunnel is also available to the DS-TE bandwidth constraints model 🔥.
If the available bandwidth is insufficient, the GEF sends a PATH message through the tunnel to the other end, requesting bandwidth using GCFs. If that's successful, the source then completes a new explicit route with a PATH message along the path with increased bandwidth, again invoking GCFs on the path. If the size of the DS-TE tunnel cannot be increased on the primary and alternate LSPs, then when the DS-TE tunnel bandwidth is exhausted, the GEF aggregator sends a message to the endpoint denying the reservation. If the DS-TE tunnels are underutilized, the tunnel bandwidth may be reduced periodically to an appropriate level 🌸. In the case of a basic single class TE scenario, there is a single TE tunnel rather than multiple-CT DS-TE tunnels; otherwise, the above GCAC functions remain the same.
Optionally, the reference model implements separate queues with Diffserv based on Traffic Class (TC) bits [RFC5462] 🦋. For example, these queues may include two Expedited Forwarding (EF) priority queues, with the highest priority assigned to Emergency Telecommunications Service (ETS) traffic and the second priority assigned to normal-priority real-time traffic (alternatively, there could be a single EF queue with dual policers [RFC5865]). Several Assured Forwarding (AF) queues may be used for various data traffic, for example, premium private data traffic and premium public data traffic. A separate best-effort queue may be used for the best-effort traffic. Several DS-TE tunnels may share the same physical link and therefore share the same queue.
The MPLS GCAC algorithm increases the likelihood that the route selected by the GEF will succeed, even when the LSP traverses multiple service provider networks 👑.
Path computation is not part of the GCAC algorithm 🙈. Instead, it's considered a vendor proprietary function, although standard IP/MPLS functions may be included in path computation, such as the following:
- a) Path Computation Element (PCE) [RFC4655][RFC4657][RFC5440] to implement inter-area/inter-AS/inter-SP path selection algorithms, including alternate path selection, path reoptimization, backup path computation to protect DS-TE tunnels, and inter-area/inter-AS/inter-SP traffic engineering.
- b) Backward-Recursive PCE-Based Computation (BRPC) [RFC5441].
- c) Per-Domain Path Computation [RFC5152].
- d) MPLS fast reroute [RFC4090] to protect DS-TE LSPs against failure.
- e) MPLS crankback [RFC4920] to trigger alternate path selection and enable explicit source routing.
3. MPLS GCAC Algorithm 🎀
MPLS GCAC is performed at the GEF during the connection setup attempt phase, to determine if a connection request can be accepted without violating existing connections' QoS and throughput requirements 💖. To enable routing to produce paths that will likely be accepted, nodes need to advertise some information about their internal CAC states. Those advertisements should not require nodes to expose detailed and up-to-date CAC information, because that could cause an unacceptably high rate of routing updates 😭. MPLS GCAC advertises CAC information that is generic (e.g., independent of the actual path selection algorithms used) and rich enough to support any CAC ✨.
MPLS GCAC defines a set of parameters to be advertised, plus a common admission interpretation of those parameters 🧚. This common interpretation takes the form of an MPLS GCAC algorithm that runs during MPLS LSP path selection, to determine if a link or node can be included for consideration. The algorithm uses the advertised MPLS GCAC parameters (available from the topology database) and the characteristics of the connection being requested (available from QoS signaling) to determine if a link/node will likely accept or reject the connection. A link/node is included if the MPLS GCAC algorithm determines that it will likely accept the connection, and excluded otherwise 🌈.
3.1. Bandwidth Allocation Parameters 🎀
okay so bestie, first things first: the bandwidth allocation parameters for each DS-TE CT come from DS-TE [RFC4126], the OSPF-TE extensions [RFC4203], and the IS-IS-TE extensions [RFC5307]. The GEF and GCF [RFC4124] can use these parameters, which are available from the DS-TE/TE extensions and advertised by the IGP. Also, the approach in this section is adapted from [PNNI], Appendix B. So it's not just us being original, it's a whole legacy thing 🧚
Here are the main parameters you need to know:
MRBkis the maximum reservable bandwidth on link k. It's the max that can be reserved, and it can be greater than the maximum link bandwidth, which means the link may be oversubscribed. Wild, right? 😭BWCckis the bandwidth constraint for CTc on link k, which is the allocated (minimum guaranteed) bandwidth for CTc on link k. 💖ULBCckis the unreserved link bandwidth on CTc on link k. It's the amount of bandwidth not yet reserved for CTc.
Lowkey, BWCck and ULBCck are the only DS-TE parameters the IGP floods 🌊 ([RFC4124][RFC4203][RFC5307]). When bandwidth reservation is used [RFC4126], ULBCck gets calculated and flooded by the IGP like this, with a threshold called RBTk (the reservation bandwidth threshold for link k) in the mix:
ULBCck = ULBk - delta0/1(CTck) * RBTk
where
delta0/1(CTck) = 0 if RBWck < BWCck
delta0/1(CTck) = 1 if RBWck >= BWCckRBTkis the reservation bandwidth threshold for link k. 🍓ULBCckis the unreserved link bandwidth on CTc on link k, takingRBTkinto account.
The GEF and GCF can also derive MRBCck, the maximum reservable link bandwidth for CTc. When bandwidth reservation is used [RFC4126], it's calculated like this:
MRBCck = MRBk - delta0/1(CTck) * RBTk
where
delta0/1(CTck) = 0 if RBWck < BWCck
delta0/1(CTck) = 1 if RBWck >= BWCckMRBCckis the maximum reservable link bandwidth for CTc on link k. The spec describes it as specifying the amount of bandwidth not yet reserved for CTc, so that's the wording we're keeping.
Real talk, these bandwidth parameters must be configured in a consistent way within domains and across domains. 🫶 GEF routing of LSPs is based on ULBCck, where ULBk is available, and RBTk can be accounted for by configuration. For example, RBTk typically = .05 * MRBk. Obsessed with how simple that is 🔥
Also available are the administrative weight (denoted as "link cost" in [RFC2328]), the TE metric [RFC3630], and the administrative group (also called color) 4-octet mask [RFC3630]. ✨
The following quantities can be derived from info the IGP advertises and that the GEF and GCF already have:
RBWckis the reserved bandwidth on CTc on link k, where 0 <= c <= MaxCT-1. It's the total amount of bandwidth reserved by all established LSPs that belong to CTc, and it works out to:
RBWck = total amount of bandwidth reserved by all established
LSPs that belong to CTc
RBWck = BWCck - ULBCckULBkis the unreserved link bandwidth on link k. It's the amount of bandwidth not yet reserved for any CT:
ULBk = MRBk - sum [RBWck (0 <= c <= MaxCT-1)]Okay now the drama 💅 The GCAC algorithm assumes that one DS-TE bandwidth constraints model is used uniformly within each domain. The options are MAR [RFC4126], MAM [RFC4125], or RDM [RFC4127]. But the European Advanced Networking Test Center (EANTC) testing [EANTC] showed that interoperability is problematic when different DS-TE bandwidth constraints models are used by different network elements within a domain. Specific testing of MAM and RDM across different vendor equipment showed the incompatibility. 💀 The three models are super different, but it's still necessary to specify interworking between them, even though it could be complex. 🙈
The following parameters are also defined and available to the GCF. They're assumed to be locally configured to a consistent value across all nodes and domain(s):
SBWckis the sustained bandwidth for CTc on link k, which is the aggregate of existing connections. It's calculated as:
SBWck = factor * RBWckwhere factor is configured based on standard 'demand overbooking' factors.
VFckis the variance factor for CTc on link k. It'sBWMcknormalized by the variance ofSBWck, and it's configured based on typical traffic variability statistics. 🦋
Quick PNNI tea ☕ In many implementations of the Private Network-Network Interface (PNNI) GCAC algorithm, the variance factor is not included. Or, equivalently, VFck is assumed to be zero. A simplified MPLS GCAC algorithm is also derived assuming VFck = 0.
Also, different demand overbooking factors can be specified for each CT. For example, no overbooking might be used for constant bitrate services, while a large overbooking factor might be used for bursty variable bitrate services. 🌈 We specify demand overbooking rather than link overbooking for the GCAC algorithm. One advantage is that demand overbooking is compatible with the source routing used by the GCAC algorithm. Smart, right? 🧠
Last but not least, we also define:
BWMckis the bandwidth margin for CTc on link k:
BWMck = RBWck - SBWckGEF uses BWCck, RBWck, ULBCck, SBWck, BWMck, and VFck for LSP/IGP routing. The GEF also needs to track per-CT LSP bandwidth allocation and reserved bandwidth parameters, which are defined as follows:
RBWLclis the reserved bandwidth for CTc on LSP l.UBWLclis the unreserved bandwidth for CTc on LSP l.
3.2. GCAC Algorithm ✨
okay bestie, time for the MPLS GCAC algorithm 💅 The big assumption is that the ratio between the bandwidth margin the node keeps above the sustained bandwidth and the standard deviation of the sustained bandwidth doesn't change much when one new aggregate flow gets added to the link 🦋 Once you buy that, any ingress node doing path selection can work out the new standard deviation of the aggregate rate (from the old value plus the new flow's traffic descriptors) and estimate the new BWMck. From there it can figure out how much extra bandwidth the new aggregate flow needs and compare that to BWCck 🫶
okay so let's define a few things 🎀 RBWck is the reserved bandwidth capacity, which is how much bandwidth has been handed out to existing aggregate flows for CTc on link k by the actual CAC running in the node. BWMck is the difference between RBWck and the aggregate sustained bandwidth (SBWck) of those existing flows. SBWck can be either the sum of each existing flow's declared sustainable bandwidth (SBWi for aggregate flow i), or a smaller value that's possibly measured or estimated 🌸 MRBCck is the maximum reservable bandwidth that aggregate flows for CTc on link k can actually use. Here's the picture:
|<-- BWMck-->|<----- ULBCck ----->|
|---------------|------------|--------------------|
0 SBWck RBWck MRBCckWait, I need to fix that diagram so it matches the original exactly. Here it is, verbatim:
|<-- BWMck-->|<----- ULBCck ----->|
|---------------|------------|--------------------|
0 SBWck RBWck MRBCckThe assumption is that BWMck is proportional to some measure of the burstiness of the traffic from the existing aggregate flows. That measure is the standard deviation of the aggregate traffic rate, defined as the square root of the sum of SBWi(PBWi - SBWi) over all existing aggregate flows, where SBWi and PBWi are the declared sustainable and peak bandwidth for aggregate flow i. The simple reasoning is that RBWck needs to sit some multiple of the standard deviation above the mean aggregate traffic rate so you get a certain packet loss ratio and packet queuing time 💀 Depending on the actual CAC, the BWMck-to-standard-deviation ratio may wobble as flows get set up and torn down. But with a sufficiently large RBWck, it shouldn't vary significantly, and that's the whole point 🙈 So a link can advertise its current BWMck-to-standard-deviation ratio (actually in the form of VF, which is the square of that number), and the MPLS GCAC algorithm uses that to estimate how much bandwidth an additional aggregate flow needs 👑
Following the derivation in [PNNI], Appendix B, the MPLS GCAC algorithm goes like this ✨ Say we have an aggregate flow bandwidth change request DBWi with peak bandwidth PBWi and sustainable bandwidth SBWi, plus a link with these MPLS GCAC parameters: ULBCck, BWMck, and VFck for CTc and link k. VARk is the variance (the square of the standard deviation) of the aggregate traffic rate, and it's not advertised. The other unadvertised MPLS GCAC quantities are RBWck and SBWck. So:
VARk = SUM SBWi*(PBWi-SBWi) (1)
over existing
aggregate flows iand
BWMck**2
VFck = ---------- (2)
VARkUsing the above equation, VARk can be computed from the advertised VFck and BWMck as:
VARk = (BWMck**2)/VFck.Let DBWi be the additional bandwidth capacity needed to carry the flow within aggregate sustainable bandwidth SBWi. The MPLS GCAC algorithm basically computes DBWi from the advertised MPLS GCAC parameters and the new aggregate flow's traffic descriptors, then compares it with ULBCck. If ULBCck >= DBWi, then the link is included for path selection consideration. Otherwise it's excluded, like this:
If (ULBCck >= DBWi), then include link k; else exclude link k (3)Let BWMcknew denote the bandwidth margin if the new aggregate flow were accepted. Denote other 'new' quantities by RBWcknew, SBWcknew, and VARnew. Then:
DBWi = BWMcknew - BWMck + SBWi (4)since BWMcknew = RBWcknew - SBWcknew, BWMck = RBWck - SBWck, and SBWcknew - SBWck = SBWi. Substituting (4) into (3), rearranging terms, and squaring both sides yields:
If ((ULBCck+BWMck-SBWck)**2 >= BWMcknew**2), then include link k;
else exclude link k (5)Using the MPLS GCAC assumption made earlier, BWMcknew**2 can be computed as:
BWMcknew**2 = VFck * VARnew, (6)Where
VARnew = VARk + SBWck * (PBWi-SBWi). (7)Substituting (2), (6) and (7) into (5) yields:
If ((ULBCck+BWMck-SBWi)**2 >= BWMck**2 + VFck*SBWi(PBWi-SBWi)),
then include link k;
else exclude link k (8)and moving BWMck**2 to the left-hand side and rearranging terms yields:
If ((ULBCck-SBWi) * (ULBCck-SBWi+2*BWMck) >= VFck*SBWi(PBWi-SBWi),
then include link k;
else exclude link k (9)Equation (9) is the Constrained Shortest Path First (CSPF) method that most vendors implement and most service providers deploy in MPLS networks. 🔥 In general, DBWi is between SBWi and PBWi. So the above test isn't necessary for the cases ULBCck >= PBWi and ULBCck < SBWi. In the former case the link is included, and in the latter case it's excluded:
Exclude Include
|<--- link ---->|<-- Test (9)-->|<--- link ----->|
|---------------|---------------|----------------| ULBCck
SBWi PBWiNote that VF and BWM are frequently not implemented. Equivalently, these quantities are assumed to be zero, in which case Equation (9) becomes:
If (ULBCck >= SBWi), then include link k; else exclude link k (10) Exclude Include
|<--- link ---->|<--- link ----->|
|---------------|----------------| ULBCck
SBWi PBWiPNNI GCAC implementations often don't incorporate the variance factor VF, in which case Equation (10) is used 🧚
Now for best-effort flows 🍓 MPLS GCAC must not reject a best-effort (BE, unassigned bandwidth) aggregate flow request based on bandwidth availability, but it may reject based on other reasons, such as the number of BE flows going past a chosen threshold. MPLS GCAC only defines one parameter for the BE service category, which is maximum bandwidth (MBW). Advertising it is twofold: MBW can be used for path optimization, and MBW = 0 is used to indicate that a link is not accepting any (additional) BE flows 💜
Demand overbooking of LSP bandwidth is employed, and it must be compliant with [RFC4124] and [RFC3270] to over-/undersubscribe requested capacity. It's simplest to use only one oversubscription method, so the GCAC algorithm assumes oversubscription of demands per CT, both within domains and for interworking between domains. The motivation is that interworking may be infeasible between domains if different overbooking models are used. Note that the same assumption was made for DS-TE bandwidth constraints models, where the GCAC algorithm assumes a consistent DS-TE bandwidth constraints model is used within each domain and interoperability of bandwidth constraints models across domains 🌈
4. Security Considerations 🔒
Okay bestie, this section is a little spicy 🌶️ but it's important! Every router has its own local, implementation-specific rules (or algorithms) for deciding what happens to traffic that goes over capacity and how new flows get admitted. If those rules are badly designed or have defects, the network can start showing problems 😬. The algorithms also give attackers a way to mess with how traffic gets delivered. That's why routers and their software usually get extensively tested before they ship, router vendors get a degree of trust, and a "compromised router" (aka one where an attacker has installed their own code) is treated as a weak spot 💀. And ngl, a compromised router can do way more problematic stuff than just tweaking the admission control algorithm 🙈. Implementers are RECOMMENDED to make sure software modifications to routers are fully secured, and operators are RECOMMENDED to use security measures (outside the scope of this document) to prevent unauthorized router software updates. Nothing in this document changes normal software security practices 🫶.
The GCAC priority parameter opens the door to theft-of-service attacks 😤. Users could claim an emergency priority for their flows when they don't actually need it, which could block real emergency calls from getting through. Here are some ways to counter these user attacks at the user interface:
- Only some user groups (e.g., police) are authorized to set the emergency priority bit, using a policy applied to RSVP-TE signaling.
- Any user is authorized to use the emergency priority bit for particular destination addresses (e.g., police), using a policy applied to RSVP-TE signaling.
- If an attack happens, log the user/group and the actions taken so the attack can be traced.
- [RFC5069] identifies a bunch of security threats against emergency call marking and mapping. Section 6 of [RFC5069] lists security requirements to counter these threats, and implementations of this document should follow those requirements.
- The security requirements listed in Section 11 of [RFC4412] should be followed. These apply to the Communications Resource Priority Header for the Session Initiation Protocol (SIP) and cover authentication and authorization, confidentiality and privacy, protection against denial-of-service attacks, and anonymity 🎀.
Inside the network, the policy and integrity mechanisms already in RSVP-TE [RFC3209] can make sure the MPLS LSP has the right policy and security credentials to take on the signaled priority and bandwidth 👑. More on this for signaling priority levels using RSVP is in [RFC6401]. There are also some similarities to the security issues around placing emergency calls in Internet multimedia systems [RFC5069], though the concepts only line up at the very highest levels 🌸.
Like any algorithm, the one specified here works on data supplied as input parameters. That data is assumed to be collected and stored locally (i.e., on the router running the algorithm). It's a fundamental assumption of secure router operation that the data stored on the router can't be modified from outside 🔐. For this algorithm, it's especially important that an outside party can't influence the input parameters. So, just like with all configuration parameters on a router, the implementer MUST supply, and the operator is RECOMMENDED to use security mechanisms to protect writes to the configuration parameters for this algorithm 💅.
5. Acknowledgements 🧚
The authors really appreciate Adrian Farrel for sponsoring this document as the Area Director and for his valuable comments and suggestions 👑. They also appreciate Young Lee, who served as the document shepherd, for his valuable comments and suggestions 🫶. And finally, Robert Sparks' thorough review and helpful suggestions are sincerely appreciated 💜.
6. Normative References 📚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031,
January 2001.
[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.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support
of Diffserv-aware MPLS Traffic Engineering", RFC 4124,
June 2005.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005.
[RFC4804] Le Faucheur, F., Ed., "Aggregation of Resource
ReSerVation Protocol (RSVP) Reservations over MPLS
TE/DS-TE Tunnels", RFC 4804, February 2007.
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita,
N., and G. Ash, "Crankback Signaling Extensions for MPLS
and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 5307, October 2008.7. Informative References 🦋
[BGP-TE] Gredler, H., Farrel, A., Medved, J., and S. Previdi,
"North-Bound Distribution of Link-State and TE
Information using BGP", Work in Progress, March 2012.
[EANTC] "Multi-vendor Carrier Ethernet Interoperability Event",
Carrier Ethernet World Congress 2006, Madrid Spain,
September 2006.
[FEEDBACK] Ashwood-Smith, P., Jamoussi, B., Fedyk, D., and D.
Skalecki, "Improving Topology Data Base Accuracy with
Label Switched Path Feedback in Constraint Based Label
Distribution Protocol", Work in Progress, June 2003.
[OIF-E-NNI] Optical Interworking Forum (OIF), "External Network-
Network Interface (E-NNI) OSPFv2-based Routing - 2.0
(Intra-Carrier) Implementation Agreement", IA # OIF-
ENNI-OSPF-02.0, July 13, 2011.
[PNNI] ATM Forum Technical Committee, "Private Network-Network
Interface Specification Version 1.1 (PNNI 1.1)",
af-pnni-0055.002, April 2002.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le
Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC
4090, May 2005.
[RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation
Bandwidth Constraints Model for Diffserv-aware MPLS
Traffic Engineering", RFC 4125, June 2005.
[RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic
Engineering & Performance Comparisons", RFC 4126, June
2005.
[RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic
Engineering", RFC 4127, June 2005.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)", RFC
4412, February 2006.
[RFC4655] Farrel, A., Vasseur, JP., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC4657] Ash, J., Ed., and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, September 2006.
[RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M.
Shanmugam, "Security Threats and Requirements for
Emergency Call Marking and Mapping", RFC 5069, January
2008.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
Per-Domain Path Computation Method for Establishing
Inter-Domain Traffic Engineering (TE) Label Switched
Paths (LSPs)", RFC 5152, February 2008.
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path
Computation Element (PCE) Communication Protocol
(PCEP)", RFC 5440, March 2009.
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le
Roux, "A Backward-Recursive PCE-Based Computation (BRPC)
Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Paths", RFC 5441,
April 2009.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label
Switching (MPLS) Label Stack Entry: "EXP" Field Renamed
to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted
Traffic", RFC 5865, May 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.
[RFC5975] Ash, G., Ed., Bader, A., Ed., Kappler, C., Ed., and D.
Oran, Ed., "QSPEC Template for the Quality-of-Service
NSIS Signaling Layer Protocol (NSLP)", RFC 5975, October
2010.
[RFC5976] Ash, G., Morton, A., Dolly, M., Tarapore, P., Dvorak,
C., and Y. El Mghazli, "Y.1541-QOSM: Model for Networks
Using Y.1541 Quality-of-Service Classes", RFC 5976,
October 2010.
[RFC6401] Le Faucheur, F., Polk, J., and K. Carlberg, "RSVP
Extensions for Admission Priority", RFC 6401, October
2011.
[TQO] Ash, G., "Traffic Engineering and QoS Optimization of
Integrated Voice and Data Networks", Elsevier, 2006.Appendix A: Example MPLS GCAC Implementation Including Path Selection, Bandwidth Management, QoS Signaling, and Queuing ✨
okay bestie, let's talk about the example that ties the whole thing together 🎀 Figure 2 shows the integrated voice/data MPLS GCAC method, where bandwidth gets handed out on an aggregated basis to each individual DS-TE CT. So the CTs come with different priorities: high-priority, normal-priority, and best-effort-priority service CTs 💅 Each CT's bandwidth is protected by bandwidth reservation methods where needed, but otherwise the CTs just share the leftover bandwidth. It's giving teamwork 🫶
Each originating GEF keeps an eye on CT bandwidth use on every MPLS LSP [RFC3031] for each CT, and decides when a CT LSP needs more or less bandwidth 👀 In Figure 2, the GEFs make those calls based on the overall aggregated bandwidth demand for CT capacity, not on a per-connection/per-flow demand basis. So they're not watching individual calls, they're watching the whole vibe 🌈 Based on that aggregated demand, the GEFs make periodic discrete changes to bandwidth allocation. That means they either increase or decrease the bandwidth on the LSPs that make up the CT bandwidth capacity.
Here's an example. If aggregate flow requests want more CT LSP bandwidth than the current DS-TE tunnel bandwidth allocation, the GEF starts a bandwidth modification request on the right LSP(s) 🦋 This may mean increasing the current LSP bandwidth allocation by a discrete increment called DBW, where DBW is the extra amount the current aggregate flow request needs. Then the GCF runs bandwidth admission control on each link in the path, based on the link's status, using the bandwidth allocation procedure described below. That's where the different parameters come in, like the reserved bandwidth threshold RBT shown in Figure 2, and we'll break down their role in the admission control procedure. Also, the GEF keeps checking LSP bandwidth use, and if usage drops below the current LSP allocation, it starts a bandwidth modification request to shrink the LSP allocation down to the current level of utilization 🧚
HIGH-PRIORITY-CT LSP
+----+======================+----+======================+----+
|GEF1|NORMAL-PRIORITY-CT LSP| VN | |GEF2|
| |======================| |======================| |
| |LOW-PRIORITY/BE-CT LSP| | | |
+----+======================+----+======================+----+LEGEND
BE- Best EffortCT- Class TypeGEF- GCAC Edge FunctionLSP- Label Switched PathVN- Via Node
Here's the vibe for Figure 2 🍓
- Distributed bandwidth allocation method applied on a per-class-type (CT) LSP basis
- GEF allocates bandwidth to each CTc LSP based on demand
- GEF decides CTc LSP bandwidth increase based on
- aggregate flow sustained bandwidth (SBWi) and variance factor VFck
- routing priority (high, normal, best effort)
- CTc reserved bandwidth (RBWck) and bandwidth constraint (BWCck)
- link reserved bandwidth threshold (RBTk) and unreserved bandwidth (ULBk)
- GEF periodically decreases CTc LSP bandwidth allocation based on bandwidth use
- GEF decides CTc LSP bandwidth increase based on
- VNs send crankback messages to GEF if DS-TE/MAR bandwidth allocation rules not met
- Link(s) not meeting request excluded from TE topology database before attempting another explicit route computation
Figure 2: Per-Class-Type (CT) LSP Bandwidth Management
So the GEF uses SBWi, VFck, RBWck, BWCck, RBTk, and ULBk for LSP bandwidth allocation decisions and IGP routing, and it uses RBWcl and UBWcl to track per-CT LSP bandwidth allocation and reserved bandwidth 📊 When it changes a CT bandwidth allocation, the GEF looks at the CT priority (high, normal, or best effort), the CT bandwidth-in-use, and the CT bandwidth allocation thresholds. Those parameters decide whether there's enough network capacity for the CT bandwidth modification request 💖
A.1. Example of Path Selection and Bandwidth Management Implementation
okay now the routing drama 🎭 In OSPF, link-state flooding is how status updates get shared. This is a state-dependent routing (SDR) method, where CSPF is typically used to change LSP routing based on the network's state. Generally, SDR methods work out a path cost for each connection request using things like the load state or congestion state of the links 📉 The example MPLS GCAC algorithm is different, though. It uses event-dependent routing (EDR), where LSP routing gets updated locally based on whether connections succeed or fail on a given path choice. In the EDR learning approaches, the path that was last tried successfully gets tried again until it's congested. At that point, another path is picked at random and tried on the next connection request. EDR path choices can also shift over time as traffic load patterns change ✨
Now meet Success-to-the-top (STT) EDR path selection, shown in Figure 3 🏆 It uses a simplified decentralized learning method to get flexible adaptive routing. The primary path (path-p) gets used first if it's available, and a currently successful alternate path (path-s) gets used until it's congested. If path-s is congested (for example, bandwidth isn't available on one or more links), a new alternate path (path-n) is picked at random as the alternate path choice for the next connection request overflow from the primary path. Bandwidth reservation kicks in under congestion conditions to protect traffic on the primary path 🛡️ STT-EDR uses crankback when an alternate path is congested at a via node, and then the connection request moves on to a new random path choice. In STT-EDR, a single connection request can try many path choices before it gets rejected 💀
Figure 3 shows the example MPLS GCAC operation of STT-EDR path selection and admission control, combined with per-CT bandwidth allocation 🎀 GEF A keeps tabs on CT bandwidth use on each CT LSP and decides when a CT LSP needs more or less bandwidth. Based on the bandwidth demand, GEF A makes periodic discrete changes to bandwidth allocation, so it either increases or decreases the bandwidth on the LSPs that make up the CT bandwidth capacity. If aggregate flow requests want more CT LSP bandwidth than the current LSP bandwidth allocation, GEF A starts a bandwidth modification request on the appropriate LSP(s) 🦋
|<----- ULBk <= RBTk ---->|
LSP-p |------------------------|-------------------------|
A B E
|<-- ULBk <= RBTk -->|
LSP-s |---------------|--------------------|-------------|
A C D EExample of STT-EDR routing method:
- If node A to node E bandwidth needs to be modified (say increased by DBW), primary LSP-p (e.g., LSP A-B-E) is tried first.
- Available bandwidth is tested locally on each link in LSP-p. If bandwidth isn't available (e.g., unreserved bandwidth on link BE is less than the reserved bandwidth threshold and this CT is above its bandwidth allocation), crankback to node A.
- If DBW isn't available on one or more links of LSP-p, then the currently successful LSP-s (e.g., LSP A-C-D-E) is tried next.
- If DBW isn't available on one or more links of LSP-s, then a new LSP gets searched for by trying additional candidate paths until a new successful LSP-n is found or the candidate paths run out.
- LSP-n then gets marked as the currently successful path for the next time bandwidth needs to be modified.
Figure 3: STT-EDR Path Selection and Per-CT Bandwidth Allocation
Let's walk through it with Figure 3 🌸 If the LSR-A to LSR-E bandwidth needs to be modified, say increased by DBW, the primary LSP-p (A-B-E) gets tried first. The bandwidth admission control for each link in the path runs based on the link's status, using the bandwidth allocation procedure described below. We'll also explain the role of the reserved bandwidth RBWck shown in Figure 3 in that admission control procedure. If the first choice LSP can't admit the bandwidth change, node A may then try an alternate LSP. If DBW isn't available on one or more links of LSP-p, then the currently successful LSP-s A-C-D-E (the 'STT path') gets tried next. If DBW isn't available on one or more links of LSP-s, then a new LSP gets searched for by trying additional candidate paths (not shown) until a new successful LSP-n is found or all of the candidate paths held in the cache run out. LSP-n then gets marked as the currently successful path for the next time bandwidth needs to be modified. DBW gets set to the additional amount of bandwidth the aggregate flow request needs 🧁
If every cached candidate path gets tried without success, the search then generates a new CSPF path. If a new CSPF calculation finds a new path, that path becomes the stored path, and the bottom cached path falls off the list. If all cached paths fail and a new CSPF path can't be found, then the original stored LSP is kept. New requests go through the same routing algorithm again, since available bandwidth and other conditions have changed, and new requests might get admitted 🔄 Also, GEF A periodically checks LSP bandwidth use (for example, once each 2-minute interval). If usage drops below the current LSP allocation, the GEF starts a bandwidth modification request to shrink the LSP bandwidth allocation down to the currently used bandwidth level. Bandwidth reservation happens in STT-EDR with PATH/RESV messages, per application of [RFC4804] 📩
In the STT-EDR computation, most of the time the primary path and stored path succeed, so no CSPF calculation needs to be done. That's why the STT-EDR algorithm gets good throughput performance while significantly reducing link-state flooding control load [TQO] 🚀 An analogous method was proposed in the MPLS working group [FEEDBACK], where feedback from failed path routing attempts is kept in the TE database and used when running CSPF.
In the example GCAC method, bandwidth allocation to the primary and alternate LSPs uses the MAR bandwidth allocation procedure, described below. Path selection uses a topology database that includes available bandwidth on each link. From the topology database, pruned of links that don't meet the bandwidth constraint, the GEF determines a list of shortest paths using a shortest path algorithm (for example, Bellman-Ford or Dijkstra methods). This path list is determined based on the administrative weights of each link, which are communicated to all nodes within the routing domain. The example formula is administrative weight = 1 + e x distance, where e is a factor giving a relatively smaller weight to the distance compared to the hop count. Analysis and simulation studies of a large national network model show that 6 or more primary and alternate cached paths provide the best overall performance 🌈👑
PCE [RFC4655][RFC4657][RFC5440] is what we use to run the inter-area/inter-AS/inter-SP path selection algorithms 🗺️✨ like alternate path selection, path reoptimization, backup path computation to protect DS-TE tunnels, and inter-area/inter-AS/inter-SP traffic engineering. So much going on 💅 The DS-TE tunnels get protected against failure with MPLS Fast Reroute [RFC4090], and the OSPF TE extensions [RFC4203] support the TE database (TED) that all those PCE path selection methods need 🦋
The example MPLS GCAC method uses the MAR bandwidth constraint model [RFC4126] inside DS-TE [RFC4124] 🌈 In DS-TE/MAR, a small amount of reserved bandwidth RBTk controls admission control on link k. Every CTc on link k gets its own allocated bandwidth constraint BWCck, which governs bandwidth allocation and protection. The reservation bandwidth on a link, RBTk, can be accessed when a given CTc has reserved bandwidth RBWck below its allocated bandwidth constraint BWCck. But if RBWck goes over its allocated bandwidth constraint BWCck, then RBTk is off-limits 🔒 So bandwidth can be fully shared among CTs when it's free, but it's otherwise protected by reservation methods. 🫶 Bandwidth can be accessed for a bandwidth request DBW for CTc on a given link k using these rules:
For an LSP on a high-priority or normal-priority CTc:
If RBWck = BWCc, admit if DBW = ULBk
If RBWck > BWCc, admit if DBW = ULBk - RBTk;or, equivalently:
If DBW = ULBCck, admit the LSP.where
ULBCck = idle link bandwidth on link k for CTc = ULBk -
delta0/1(CTck) x RBWk
delta0/1(CTck) = 0 if RBWck < BWCck
delta0/1(CTck) = 1 if RBWck = BWCckFor an LSP on a best-effort-priority CTc:
allocated bandwidth BWCc = 0;Diffserv queuing only serves best-effort packets if there's available link bandwidth 🍓
When setting the bandwidth constraints for CTck, for a normal-priority CTc, the bandwidth constraints (BWCck) on link k get set by splitting the maximum reservable link bandwidth (MRBk) in proportion to the forecast or measured traffic load bandwidth TRAF_LOAD_BWck for CTc on link k. That looks like this:
PROPORTIONAL_ BWck =
TRAF_LOAD_ BWck/[S (c) {TRAF_LOAD_ BWck, c=0, MaxCT-1}] x MRBkFor a normal-priority CTc:
BWCck = PROPORTIONAL_ BWckFor a high-priority CT, the bandwidth constraint BWCck is set to a multiple of the proportional bandwidth, like this:
BWCck = FACTOR * PROPORTIONAL_ BWckwhere FACTOR is set to a multiple of the proportional bandwidth (e.g., FACTOR = 2 or 3 is typical). This results in some over-allocation ('overbooking') of the link bandwidth and gives priority to the high-priority CTs 👑 Normally, the bandwidth allocated to high-priority CTs should be a relatively small fraction of the total link bandwidth, with a maximum of 10-15 percent being a reasonable guideline.
As we said above, the bandwidth allocated to a best-effort-priority CTc is set to zero, so:
BWCck = 0Analysis and simulation studies show that the level of reserved capacity RBTk in the range of 3-5% of link capacity gives the best overall performance. 💖
We have a simple example of the MAR bandwidth allocation method 🧁 Say there are two class types, CT0 and CT1, and a particular link with:
MRB = 100
BWC0 = 30
BWC1 = 50These bandwidth constraints are based on the forecasted traffic loads, as discussed above. Either CT is allowed to go over its bandwidth constraint BWCc as long a there is at least RBW units of spare bandwidth left. Assume RBT = 10. So under overload, if:
RBW0 = 20
RBW1 = 70then, for this loading:
UBW = 100 - 20 - 70 = 10If a bandwidth increase request DBW = 5 arrives for Class Type 0 (CT0), then accept it for CT0, since RBW0 < BWC0 and DBW (= 5) < ILBW (= 10).
If a bandwidth increase request DBW = 5 arrives for Class Type 1 (CT1), then reject it for CT1, since RBW1 > BC1 and DBW (= 5) > ILBW - RBT = 10 - 10 = 0.
So CT0 can grab the extra bandwidth (up to 10 units) if the demand shows up, since it's still below its BWC value 🙌 CT1, however, can't increase its bandwidth on the link anymore, since it's above its BWC1 value and only RBT=10 units of idle bandwidth are left on the link. If best effort traffic is around, it can always seize whatever idle bandwidth is free at the moment, but it can get lost at the queues in favor of higher-priority traffic 🫠
Now, if a request arrives to increase bandwidth for CT1 by 5 units (i.e., DBW = 5), we have to decide whether to admit it. Since for CT1:
RBW1 > BWC1 (70 > 50), and
DBW > UBW - RBT (i.e., 5 > 10 - 10)the bandwidth request gets rejected by the bandwidth allocation rules above 💀 Next, say a request arrives to increase bandwidth for CT0 by 5 units (i.e., DBW = 5). We have to decide whether to admit this one too. Since for CT0:
RBW0 < BWC0 (20 < 30), and
DBW < UBW (i.e., 5 < 10)This example shows that with the current state of the link and the current CT loading, CT1 can't increase its bandwidth on the link, since it's above BWC1 and there's only RBW=10 units of spare bandwidth left. But CT0 can take the extra bandwidth (up to 10 units) if the demand arrives, since it's below its BWC0 value 🦋
For the example GCAC, here's how bandwidth additions and deletions to LSPs work. The bandwidth constraint parameters defined in the MAR method [RFC4126] don't change based on traffic conditions. In particular, these parameters defined in [RFC4126], as described above, are configured and don't change until reconfigured: MRBk, BWCck, and RBTk. The reserved bandwidth variables do change based on traffic, though: RBWck, ULBk, and ULBCck. The RBWck and the bandwidth allocated to each DS-TE/MAR tunnel get dynamically changed based on traffic: it goes up when traffic demand increases (using RSVP aggregation), and it goes down periodically when traffic demand decreases 📉 Also, if tunnel bandwidth can't be increased on the primary path, an alternate LSP path gets tried. When LSP tunnel bandwidth needs to go up to fit a given aggregate flow request, the bandwidth increases by the amount of the needed additional bandwidth, if possible. The tunnel bandwidth quickly rises to the currently needed maximum bandwidth level, where no further requests to increase bandwidth are made, since departing flows leave a constant amount of available or spare bandwidth in the tunnel for new requests ✨ Tunnel bandwidth gets reduced every 120 seconds by 0.5 times the difference between the allocated tunnel bandwidth and the current level of actually utilized bandwidth (i.e., the current level of spare bandwidth). Analysis and simulation modeling results show these parameters give the best performance across a number of overload and failure scenarios 🌸
A.2. Example of QoS Signaling Implementation 🎀
The example GCAC method uses Next Steps in Signaling (NSIS) algorithms to signal the MPLS GCAC QoS requirements of individual flows. NSIS QoS signaling was specified by the IETF NSIS working group, and it extends RSVP signaling by defining a two-layer QoS signaling model:
- NSIS Transport Layer Protocol (NTLP) [RFC5971]
- NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling [RFC5974]
[RFC5975] defines a QoS specification (QSPEC) object, which holds the QoS parameters required by a QoS model (QOSM) [RFC5976]. A QOSM specifies the QoS parameters and procedures that govern the resource management functions in a QoS-aware router. Multiple QOSMs can be supported by the QoS-NSLP, and the QoS-NSLP allows stacking of QSPEC parameters so different QOSMs can be used in different domains 🌐 That means NSIS gives you a mechanism for interdomain QoS signaling and interworking 💜
The QSPEC parameters defined in [RFC5975] include, among others:
TRAFFIC DESCRIPTION Parameters:
<Traffic Model>Parameters
CONSTRAINTS Parameters:
<Path Latency>,<Path Jitter>,<Path PLR>, and<Path PER>Parameters<PHB Class>Parameter<DSTE Class Type>Parameter<Y.1541 QoS Class>Parameter<Reservation Priority>Parameter<Preemption Priority>and<Defending Priority>Parameters
Being able to get end-to-end QoS across multiple Internet domains is also a big deal 🌈 MPLS GCAC end-to-end QoS signaling makes sure end-to-end QoS gets met by applying the Y.1541-QOSM [RFC5976], like so:
The QoS GEF starts an end-to-end, inter-domain QoS RESERVE message with the QoS parameters, including for example, <Traffic Model>, <Y.1541 QoS Class>, <Reservation Priority>, and maybe other parameters for the flow. The RESERVE message may cross multiple domains. Each node on the data path checks resource availability and accumulates the delay, delay variation, and loss ratio parameters, as described below. If an intermediate node can't accommodate the new request, the reservation is denied. If no intermediate node has denied the reservation, the RESERVE message is forwarded to the next domain. If any node can't meet the requirements the RESERVE message designates for a QoS parameter (for example, it can't support accumulating end-to-end delay with the <Path Latency> parameter), that node sets a flag that denies the reservation 🚫 Parameter negotiation can also happen, for example by setting the <Y.1541 QoS Class> to a lower class than the one specified in the RESERVE message. When the available <Y.1541 QoS Class> has to drop from the desired <Y.1541 QoS Class>, say because the delay objective was exceeded, there's an incentive to respond to the QoS GEF with an available value for delay in the <Path Latency> parameter 🧚 For example, if the available <Path Latency> is 150 ms (still useful for many applications) and the desired QoS is 100 ms (according to the desired <Y.1541 QoS Class> Class 0), then the response is that Class 0 can't be achieved and Class 1 is available (with its 400 ms objective). The response also includes an available <Path Latency> = 150 ms, which makes accepting the available <Y.1541 QoS Class> more likely 🎉
A.3. Example of Queuing Implementation ✨
okay so this one is my favorite 🎀 the queuing example uses Diffserv mechanisms, and it sorts traffic into separate queues based on the Traffic Class (TC)/CoS bits 💅 there are 3 levels of priority: high, normal, and best effort. the high-priority side is giving two EF priority queues [RFC3246][RFC5865]. the top spot goes to emergency traffic (GETS/ETS/E911) 🚨, and the second spot goes to normal-priority real-time traffic, like VoIP 📞
then there are separate AF queues [RFC2597] for data services, like premium private data and premium public data traffic 💜 and a separate best-effort queue for the best-effort traffic 🍓
every queue gets a static bandwidth allocation limit, based on how much traffic is forecast on each link 🧚 the limits are set so they won't be exceeded under normal conditions, but there's still some room for a bit of overload. lowkey so smart 🙈
here's the big picture: in the MPLS GCAC method, high-priority, normal-priority, and best-effort traffic all share the same network 🌈 when there's congestion, the Diffserv priority-queuing mechanisms push out the best-effort traffic at the queues. that way the normal-priority and high-priority traffic can still get through on the MPLS-allocated LSP bandwidth 👑 iconic, periodt 💖
Authors' Addresses 🦋
Gerald Ash (editor)
AT&T
EMail: gash5107@yahoo.com
Dave McDysan
Verizon
22001 Loudoun County Pkwy
Ashburn, VA 20147
EMail: dave.mcdysan@verizon.com📦 where this page comes from
- ietf: rfc6601 2012-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms