Network Working Group G. Ash Internet Draft AT&T Intended status: Experimental D. McDysan Verizon Expires: May, 2012 December 5, 2011 Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks Abstract This document presents 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, for example, to reject voice over Internet Protocol (VoIP) calls when additional calls would adversely affect calls already in progress. Without MPLS GCAC, connections on congested links will suffer degraded quality. The MPLS GCAC algorithm can be optionally implemented in vendor equipment and deployed by service providers. MPLS GCAC interoperates between vendor equipment and across multiple service provider domains. The MPLS GCAC algorithm uses available standard mechanisms for MPLS based networks, such as RSVP, DSTE, PCE, NSIS, DiffServ, and OSPF. The MPLS GCAC algorithm does not include aspects of CAC that might be considered vendor proprietary implementations, such as detailed path selection mechanisms. MPLS GCAC functions are implemented in a distributed manner to deliver the objective QoS for specified QoS constraints. The objective is that the source is able to compute a source route with high likelihood that MPLS GCAC via elements along the selected path will in fact admit the request. In some cases (e.g., multiple AS) this objective cannot always be met, but the document summarizes methods that partially meet this objective. MPLS GCAC is applicable to any service or flow that must meet an objective QoS (delay, jitter, packet loss rate) for a specified quantity of traffic. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 20, 2012. Ash, McDysan [Page 1] Internet Draft GCAC Algorithm Specification December 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. MPLS GCAC Reference Model & Algorithm Summary . . . . . . . . 4 2.1 Inputs to MPLS GCAC . . . . . . . . . . . . . . . . . . . 5 2.2 MPLS GCAC Algorithm Summary . . . . . . . . . . . . . . . 6 3. MPLS GCAC Algorithm . . . . . . . . . . . . . . . . . . . . . 9 3.1 Bandwidth Allocation Parameters . . . . . . . . . . . . . 9 3.2 GCAC Algorithm . . . . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 7. Normative References . . . . . . . . . . . . . . . . . . . . . 15 8. Informative References . . . . . . . . . . . . . . . . . . . . 16 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Appendix A: Example MPLS GCAC Implementation Including Path Selection, Bandwidth Management, QoS Signaling, & Queuing . . . . . . . . . . . . . . . . . . . . . . . 17 A.1 Example of Path Selection & Bandwidth Management Implementation . . . . . . . . . . . . . . . . . . . . . . 19 A.2 Example of QoS Signaling Implementation . . . . . . . . . 24 A.3 Example of Queuing Implementation . . . . . . . . . . . . 26 1. Introduction Ash, McDysan [Page 2] Internet Draft GCAC Algorithm Specification December 2011 This document presents 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, for example, to reject voice over Internet Protocol (VoIP) calls when additional calls would adversely affect calls already in progress. Without MPLS GCAC, connections on congested links will 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 operates across routing areas, autonomous systems, and service provider boundaries. This document defines an MPLS GCAC reference model, algorithm, and functions implemented in one or more types of network elements in different domains that operate together in a distributed manner to deliver the objective QoS for specified QoS constraints, such as bandwidth. With MPLS GCAC the source router/server is able to compute a source route with high likelihood that MPLS GCAC via elements along the selected path will in fact admit the request. MPLS GCAC includes nested CAC actions, such as RSVP aggregation, nested RSVP-TE for scaling between provider edge (PE) routers, and pseudowire (PW) CAC within traffic engineered tunnels. MPLS GCAC focuses on MPLS and PW level CAC functions, rather than application level CAC functions. MPLS GCAC is applicable to any service or flow that must meet an objective QoS (latency, delay variation, loss) for a specified quantity of traffic. This would include, for example, most real-time/RTP services (voice, video, etc.) as well as some non-real-time services. Real-time/RTP services are typically interactive, relatively persistent traffic flows. Other services subject to MPLS GCAC could include, for example, manually provisioned label switched paths (LSPs) or PWs, automatic bandwidth assignment for applications that automatically build LSP meshes among PE routers. MPLS GCAC is applicable to both access and backbone networks, for example, to slow speed access networks and to broadband DSL, cable, and fiber access networks. This document is Experimental. It is intended that service providers and vendors experiment with the GCAC concept and the algorithm described in this document in a controlled manner to determine the benefits of such a mechanism. The results of such experiments may be fed back to the IETF community to refine this document and to move it to the Standards Track (probably within the MPLS working group) if the experimental results are positive. It should be noted that the algorithm might have negative effects on live deployments if the experiment is a failure. Effects might include blocking traffic that would normally be handled, or congestion caused by allowing excessive traffic on a link. For these reasons, experimentation in production networks needs to be treated with caution. Ash, McDysan [Page 3] Internet Draft GCAC Algorithm Specification December 2011 In Section 2 we describe the MPLS GCAC reference model, and in Section 3 we specify the MPLS GCAC algorithm based on the principles in the reference model and requirements. Appendix A gives an example of MPLS GCAC implementation including path selection, bandwidth management, QoS signaling, and queuing implementation. 2. MPLS GCAC Reference Model & Algorithm Summary Figure 1 illustrates the reference model for the MPLS GCAC algorithm: ,-. ,-. ,--+ `--+--'- --'\ +----+_____+------+ { +----+ +----+ `. +------+ |GEF1| | |______| P |___| P |______| | | |-----| PE1 | { +----+ +----+ /+| PE2 | | | | |==========================>| ASBR | +-:--+ | |<==========================| | _|..__ +------+ { DSTE/MAR Tunnels ; +------+ _,' \-| ./ -'._ !| | Access \ / +----+ \, !| | Network | \_ | P | | !| | / `| +----+ / !| `--. ,.__,| | IP/MPLS Network / !| '`' '' ' .._,,'`.__ _/ '---' !| | '`''' !| C1 !| ,-. ,-. !| ,--+ `--+--'- --'\ !| +----+_____+------+ { +----+ +----+ `. +------+ |GEF2| | |______| P |___| P |______| | | |-----| PE4 | { +----+ +----+ /+| PE3 | | | | |==========================>| ASBR | +-:--+ | |<==========================| | _|..__ +------+ { DSTE/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 GCF functions LEGEND: --------- ASBR: autonomous system border router BW: bandwidth Ash, McDysan [Page 4] Internet Draft GCAC Algorithm Specification December 2011 COS: class of service DSTE: 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 Model MPLS GCAC is applicable to any service or flow for which MPLS GCAC is required to meet a given QoS. As such, the reference model applies to most real-time/RTP services (voice, video, etc.) as well as some non-real-time services. Real-time/RTP services are typically interactive, relatively persistent traffic flows. Non-real-time applications subject to MPLS GCAC could include, for example, manually provisioned LSPs or PWs, and automatic bandwidth assignment for applications that automatically build LSP meshes among PE routers. The reference model also applies to MPLS GCAC when MPLS is used in access networks, which include, for example, slow speed access networks and broadband DSL, cable, and fiber access networks. Endpoints will be IP/PBXs and individual-usage SIP/RTP end devices (hard and soft SIP phones, IADs), and this traffic will enter and leave the core via possibly bandwidth-constrained access networks, which may also be MPLS aware, but may use some other admission control technology. The basic elements considered in the reference model are the MPLS GCAC edge function (GEF), GCAC core functions (GCF), the PE routers, autonomous system border routers (ASBR), and provider (P) routers. As illustrated in Figure 1, the GEF interfaces to the application at the source and destination PE, and the GCF exist at the PE, P and ASBR routers. GEF has an end-to-end focus and deals with whether individual connection requests fit within an MPLS tunnel, and GCF has a hop-by-hop focus and deals with whether an MPLS tunnel can be established across specific core network elements on a path. The GEF functionality may be implemented in the PE, ASBR, or in 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 Inputs to the GEF and GCF include the following, where most are inputs to both GEF and GCF except as noted. Most of the parameters apply to the specific flow/LSP being calculated, while Ash, McDysan [Page 5] Internet Draft GCAC Algorithm Specification December 2011 some parameters, such as request type, apply to the calculation method. Required inputs are marked with (*); all other inputs are optional: Traffic Description * Bandwidth per DSTE class type [RFC4124] (GEF, GCF) * Bandwidth for LSP from [RFC3270] (GEF, GCF) * Aggregated RSVP bandwidth requirements from [RFC4804] (GEF) Variance Factor (GEF, GCF) Service Class/CoS & QoS * Class Type (CT) from [RFC4124] (GEF, GCF) Signaled or configured TC-PHB mapping from [RFC3270] (GEF, GCF) Signaled or configured PHB from [RFC3270] (GEF, GCF) QoS requirements from NSIS/Y.1541 [RFC5971, RFC5974, RFC5975, RFC5976] (GEF) 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/under-subscribe requested capacity (GEF, GCF) Over/under-subscribe available bandwidth (GEF, GCF) These inputs can be received by the GEF and GCF from a signaling interface, such as SIP or H.323, RSVP, from an NMS, be derived from measured traffic levels, or from elsewhere. 2.2 MPLS GCAC Algorithm Summary Figure 1 is a reference model for MPLS GCAC and illustrates the GEF to GEF MPLS GCAC algorithm to determine whether there is sufficient bandwidth to complete a connection. The originating GEF receives a connection request including the above input parameters over the input interface, for example, via an RSVP bandwidth request as specified in [RFC4804]. The GEF a) determines whether there is enough bandwidth on the route between the originating and terminating GEFs via routing and signaling communication with the GCF functions at the P, PE and ASBR network elements along the path to accommodate the connection, b) communicates the accept/reject decision on the input interface for the connection request, and c) keeps account of network resource allocations by tracking bandwidth use and allocations per COS. Optionally, the GEF may dynamically adjust the tunnel size by signaling communication with the GCF functions 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 Ash, McDysan [Page 6] Internet Draft GCAC Algorithm Specification December 2011 tunnel, and c) use a 'make before break' mechanism to adjust tunnel capacity in order to minimize disruption to the bearer traffic. In the reference model, DSTE [RFC4124] tunnels are configured between the GEFs based on the traffic forecast and current network utilization. These guaranteed bandwidth DSTE tunnels are created using RSVP-TE [RFC3209]. DSTE bandwidth constraints models are applied uniformly within each domain, such as the maximum allocation with reservation bandwidth constraints model (MAR) [RFC4126], maximum allocation bandwidth constraints model (MAM) [RFC4125], and the Russian dolls bandwidth constraints model (RDM) [RFC4127]. An IGP such as OSPF or ISIS is used to advertise bandwidth availability by CT for use by the GCF to determine MPLS tunnel bandwidth allocation and admission on core (backbone) links. These DSTE 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. In the case that a connection is set up across multiple service provider networks, i.e., across multiple routing domains/autonomous systems (AS's), there are several options to enable MPLS GCAC to be implemented in this case: 1. Use [OIF E-NNI] to advertise ULBCck parameters to the originating GEF, for the full topology of adjacent domains/areas/AS's, 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 since the process of summarization results in loss of topology and capacity usage information. In this manner the originating GEF can implement the MPLS GCAC algorithm described in Section 3 across multiple domains/areas/AS's. 2. Use [BGP-TE] to advertise ULBCck parameters via BGP to the originating GEF for the full topology of adjacent domains/areas/AS's. In this manner the originating GEF can implement the MPLS GCAC algorithm described in Section 3 across multiple domains/areas/AS's. 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. 3. Use individual AS control and MPLS crankback [RFC4920] to retain originating GEF control. For example, in Figure 1 if a connection crosses the two AS's 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 function 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. In routing a connection across multiple AS's, e.g., across Ash, McDysan [Page 7] Internet Draft GCAC Algorithm Specification December 2011 AS1-->AS2-->AS3, if the flow is rejected, say in AS2, the originating GEF1 can seek an alternate route perhaps through, say, AS1-->AS4-->AS3. This option does not achieve full originating GEF control with the desired full topology visibility across AS's, but avoids possible issues with obtaining full topology visibility across AS's. 4. Use path computation elements (PCEs) [RFC4655] across multiple ASs. 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 DSTE tunnel, adding the bandwidth requirements during connection setup and subtracting 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 DSTE tunnel from the destination GEF to the originating GEF. The aggregate bandwidth usage on the DSTE tunnel is also available to the DSTE bandwidth constraints model. If the available bandwidth is insufficient, then the GEF sends a PATH message through the tunnel to the other end, requesting bandwidth using GCF functions, and if successful the source would then complete a new explicit route with a PATH message along the path with increased bandwidth, again invoking GCF functions on the path. If the size of the DSTE tunnel cannot be increased on the primary and alternate LSPs, then when the DSTE tunnel bandwidth is exhausted, the GEF aggregator sends a message to the endpoint denying the reservation. If the DSTE 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 DSTE tunnels, otherwise the above GCAC functions remain the same. Optionally, the reference model implements separate queues with DiffServ based on TC bits. For example, these queues may include two expedited forwarding (EF) priority queues, with the highest priority assigned to emergency traffic (ETS) 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, premium public data traffic, and a separate best-effort queue is used for the best-effort traffic. Several DSTE 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. Ash, McDysan [Page 8] Internet Draft GCAC Algorithm Specification December 2011 Path computation is not part of the GCAC algorithm, rather it is considered as 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 DSTE tunnels, and inter-area/inter-AS/inter-SP traffic engineering. b) Backward recursive path computation (BRPC) [RFC5441]. c) Per domain path computation (PDPC) [RFC5152]. d) MPLS fast reroute (FRR) [RFC4090] to protect DSTE 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, it is necessary for nodes to advertise some information about their internal CAC states. Requiring nodes to expose detailed and up-to-date CAC information, however, may result in 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 and a common admission interpretation of these parameters. This common interpretation is in the form of an MPLS GCAC algorithm to be performed during MPLS LSP path selection to determine if a link or node can or cannot 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 MPLS GCAC bandwidth allocation parameters for each DSTE CT are as defined within DSTE [RFC4126], OSPF-TE extensions [RFC4203], and ISIS-TE extensions [RFC5307]. The following parameters are available from DSTE/TE extensions, advertised by the IGP, and available to the GEF and GCF [RFC4124]. Note that the approach presented in this section is adapted from PNNI Appendix B [PNNI]. Ash, McDysan [Page 9] Internet Draft GCAC Algorithm Specification December 2011 MRBk maximum reservable bandwidth on link k specifies the maximum bandwidth that may be reserved; this may be greater than the maximum link bandwidth, in which case the link may be oversubscribed. BWCck bandwidth constraint for CTc on link k = allocated (minimum guaranteed) bandwidth for CTc on link k. ULBCck unreserved link bandwidth on CTc on link k specifies the Amount of bandwidth not yet reserved for CTc Note that BWCck and ULBCck are the only DSTE parameters flooded by the IGP [RFC4124, RFC4203, RFC5307]. For example, when bandwidth reservation is used [RFC4126], ULBCck is calculated and flooded by the IGP as follows: RBTk reservation bandwidth threshold for link k. ULBCck unreserved link bandwidth on CTc on link k specifies the amount of bandwidth not yet reserved for CTc, taking account of RBTk, ULBCck = ULBk - delta0/1(CTck) * RBTk where delta0/1(CTck) = 0 if RBWck < BWCck delta0/1(CTck) = 1 if RBWck >= BWCck Also derivable at the GEF and GCF is MRBCck, the maximum reservable link bandwidth for CTc . For example, when bandwidth reservation is used [RFC4126], MRBCck is calculated as follows: MRBCck maximum reservable link bandwidth for CTc on link k specifies the amount of bandwidth not yet reserved for CTc, MRBCck = MRBk - delta0/1(CTck) * RBTk where delta0/1(CTck) = 0 if RBWck < BWCck delta0/1(CTck) = 1 if RBWck >= BWCck Note that 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, e.g., RBTk typically = .05 * MRBk. Also available are administrative weight [RFC2328], TE metric [RFC3630], and administrative group (also called color) 4-octet mask [RFC3630]. The following quantities can be derived from information advertised by the IGP and otherwise available to the GEF and GCF: RBWck reserved bandwidth on CTc on link k (0 <= c <= MaxCT-1), RBWck = total amount of bandwidth reserved by all established LSPs that belong to CTc, Ash, McDysan [Page 10] Internet Draft GCAC Algorithm Specification December 2011 RBWck = BWCck - ULBCck. ULBk unreserved link bandwidth on link k specifies the amount of bandwidth not yet reserved for any CT, ULBk = MRBk - sum [RBWck (0 <= c <= MaxCT-1)]. The GCAC algorithm assumes that a DSTE bandwidth constraints model is used uniformly within each domain (e.g., MAR [RFC4126], MAM [RFC4125], or RDM [RFC4127]). EANTC testing [EANTC] has shown that interoperability is problematic when different DSTE 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. However, while the characteristics of the 3 DSTE bandwidth constraints models are quite different, it is necessary to specify interworking between them even though it could be complex. The following parameters are also defined and available to GCF, and are assumed to be locally configured to be a consistent value across all nodes and domain(s): SBWck sustained bandwidth for CTc on link k (aggregate of existing connections); SBWck = factor * RBWck where factor is configured based on standard 'demand overbooking' factors. VFck variance factor for CTc on link k; VFck is BWMck normalized by variance of SBWck; VFck is configured based on typical traffic variability statistics. In many implementations of the 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. Note that different demand overbooking factors can be specified for each CT, e.g., no overbooking might be used for constant bit-rate services, while a large overbooking factor might be used for bursty variable bit-rate services. We specify demand overbooking rather than link overbooking for the GCAC algorithm; one advantage is the demand overbooking is compatible with source routing used by the GCAC algorithm. Also defined is BWMck bandwidth margin for CTc on link k; BWMck = RBWck - SBWck GEF uses BWCck, RBWck, ULBCck,, SBWck, BWMck, and VFck for LSP/IGP routing. GEF also needs to track per-CT LSP bandwidth allocation and reserved bandwidth parameters, which are defined as follows: RBWLcl reserved bandwidth for CTc on LSP l Ash, McDysan [Page 11] Internet Draft GCAC Algorithm Specification December 2011 UBWLcl unreserved bandwidth for CTc on LSP l 3.2 GCAC Algorithm The assumption behind the MPLS GCAC is that the ratio between BWMck, which represents the safety margin the node is putting above the SBWck, and the standard deviation of the SBWck defined below does not change significantly as one new aggregate flow is added on the link. Any ingress node doing path selection can then compute the new standard deviation of the aggregate rate (from the old value and the aggregate flow's traffic descriptors) and an estimate of the new BWMck. From this, the increase in bandwidth required to carry the new aggregate flow can be computed and compared to BWCck. To expand on the discussion above, let RBWck denote the reserved bandwidth capacity, i.e., the amount of bandwidth that has been allocated to existing aggregate flows for CT c on link k by the actual CAC used in the node. BWMck is the difference between RBWck and the aggregate sustained bandwidth (SBWck) of the existing aggregate flows. SBWck can be either the sum of existing aggregate flows' declared sustainable bandwidth (SBWi for aggregate flow i) or a smaller - possibly measured or estimated - value. Let MRBCck denote the maximum reservable bandwidth that is usable by aggregate flows for CTc on link k. The following diagram illustrates the relationship among MRBCck, RBWck, BWMck, SBWck and ULBCck: |<-- BWMck-->|<----- ULBCck ----->| |---------------|------------|--------------------| 0 SBWck RBWck MRBCck The assumption is that BWMck is proportional to some measure of the burstiness of the traffic generated by the existing aggregate flows, this measure being 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 declared sustainable and peak bandwidth for aggregate flow i, respectively. This assumption is based on the simple argument that RBWck needs to be some multiple of the standard deviation above the mean aggregate traffic rate to guarantee some levels of packet loss ratio and packet queuing time. Depending on the actual CAC used, the BWMck-to-standard-deviation ratio may vary as aggregate flows are established and taken down. It is reasonable to assume, however, that around some sufficiently large value of RBWck, this ratio will not vary significantly. What this means is a link can advertise its current BWMck-to-standard-deviation ratio (actually in the form of VF, which is the square of this number), and the MPLS GCAC algorithm can use this number to estimate how much bandwidth is required to carry an additional aggregate flow. Following the derivation given in [PNNI] Appendix B, the MPLS GCAC algorithm is derived as follows: Consider an aggregate flow bandwidth change request DBWi with peak bandwidth PBWi and Ash, McDysan [Page 12] Internet Draft GCAC Algorithm Specification December 2011 sustainable bandwidth SBWi, and a link with the following MPLS GCAC parameters: ULBCck, BWMck, and VFck for CT c and link k. Denote the variance (i.e., square of standard deviation) of the aggregate traffic rate by VARk (not advertised). Denote other unadvertised MPLS GCAC quantities by RBWck and SBWck. Then, VARk = SUM SBWi*(PBWi-SBWi) (1) over existing aggregate flows i and BWMck**2 VFck = ---------- (2) VARk Using 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 with aggregate bandwidth DBWi. The MPLS GCAC algorithm basically computes DBWi from the advertised MPLS GCAC parameters and the new aggregate flow's traffic descriptors, and compares it with ULBCck. If ULBCck >= DBWi then the link is included for path selection consideration; otherwise, it is excluded, i.e., 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 yield: 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) Ash, McDysan [Page 13] Internet Draft GCAC Algorithm Specification December 2011 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 yield If ((ULBCck-SBWi) * (ULBCck-SBWi+2*BWMck) >= VFck*SBWi(PBWi-SBWi) then include link k else exclude link k (9) Equation (9) represents the constrained shortest path first (CSPF) method implemented by most vendors and deployed by most service providers in MPLS networks. In general DBWi is between SBWi and PBWi. So the above test is not necessary for the cases ULBCck >= PBWi and ULBCck < SBWi. In the former case, the link is included; in the latter case, the link is excluded. Exclude Include |<--- link ---->|<-- Test (9)-->|<--- link ----->| |---------------|---------------|----------------| ULBCck SBWi PBWi Note 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 PBWi PNNI GCAC implementations often do not incorporate the variance factor VF, in which case Equation (10) is used. 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 number of BE flows exceeding a chosen threshold. MPLS GCAC defines only one parameter for BE service category - maximum bandwidth (MBW) - to advertise how much capacity is usable for BE flows. The purpose of advertising this parameter 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 must be compliant with [RFC4124] and [RFC3270] to over/under-subscribe requested capacity. It is simplest to use only one oversubscription method, i.e., the GCAC algorithm assumes oversubscription of demands per CT, Ash, McDysan [Page 14] Internet Draft GCAC Algorithm Specification December 2011 both within domains and for interworking between domains. The motivation is that interworking may be infeasible between domains if use different overbooking models are used. Note that the same assumption was made for DSTE bandwidth constraints models, in that the GCAC algorithm assumes a consistent DSTE bandwidth constraints model is used within each domain, and interoperability of bandwidth constraints models across domains. 4. Security Considerations Use of a GCAC priority parameter raises possibilities for theft-of-service attacks because users could claim an emergency priority for their flows without real need, thereby effectively preventing serious emergency calls to get through. Several options exist for countering such attacks, for example: - 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 employ the emergency priority bit for particular destination addresses (e.g., police) using a policy applied to RSVP-TE signaling 5. IANA Considerations There are no IANA Considerations. 6. Acknowledgements The authors greatly appreciate Adrian Farrel's support in serving as the sponsoring Area Director for this draft and for his valuable comments and suggestions on the document. The authors also greatly appreciate Young Lee's serving as the document shepherd and for his valuable comments and suggestions. 7. Normative References [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [RFC3031] Rosen, E., et al., "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3270] LeFaucheur, F., et al., "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002. [RFC3630] Katz, D., et al., "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4124] LeFaucheur, F., "Protocol Extensions for Support of Diffserv-Aware MPLS Traffic Engineering", RFC 4124, June 2005. [RFC4203] Kompella, K., Rekhter, Y., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC Ash, McDysan [Page 15] Internet Draft GCAC Algorithm Specification December 2011 4203, October 2005. [RFC4804] LeFaucheur, F., "Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", RFC 4804, February 2007. [RFC4920] Farrel, A., et al., "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, July 2007. [RFC5307] Kompella, K., Rekhter, Y., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008. 8. Informative References [BGP-TE] Gredler, H., et al., "North-Bound Distribution of Link-State and TE Information using BGP", work in progress. [EANTC] "Multi-vendor Carrier Ethernet Interoperability Event," Carrier Ethernet World Congress 2006, Madrid Spain, September 2006. [FEEDBACK] Ashwood-Smith, P., et al., "Improving Topology Data Base Accuracy with Label Switched Path Feedback in Constraint Based Label Distribution Protocol," IETF work in progress. [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., et al., "Assured Forwarding PHB Group", RFC 2597, June 1999. [RFC3246] Davie, B., et al., "An Expedited Forwarding PHB", RFC 3246, March 2002. [RFC4090] Pan, P., et al., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", May 2005. [RFC4125] LeFaucheur, F., Lai, W., "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] LeFaucheur, F., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005. [RFC4655] Farrel, A., et al., "A Path Computation Element (PCE)- Based Architecture", RFC 4655, August 2006. [RFC4657] Ash, J., Le Roux, J.L., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006. [RFC5152] Vasseur, JL., et al., "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008. Ash, McDysan [Page 16] Internet Draft GCAC Algorithm Specification December 2011 [RFC5440] Vasseur, JL., Le Roux, J. L., "Path Computation Element (PCE) Communication Protocol", RFC 5440, March 2009. [RFC5441] Vasseur, JP., et al., "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009. [RFC5865] Baker, F., et al., "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, May 2010. [RFC5971] Schulzrinne, H., Hancock, R., "GIST: General Internet Signalling Transport", RFC 5971, October 2010. [RFC5974] Manner, J., et al., "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010. [RFC5975] Ash, G., et al., "QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)", RFC 5975, October 2010. [RFC5976] Ash, G., et al., "Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes", RFC 5976, October 2010. [TQO] Ash, G., "Traffic Engineering & QoS Optimization of Integrated Voice & Data Networks," Elsevier, 2006. 9. 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 Appendix A: Example MPLS GCAC Implementation Including Path Selection, Bandwidth Management, QoS Signaling, & Queuing Figure 2 illustrates an example of the integrated voice/data MPLS GCAC method in which bandwidth is allocated on an aggregated basis to the individual DSTE CTs. In the example method, CTs have different priorities including high-priority, normal-priority, and best-effort priority services CTs. Bandwidth allocated to each CT is protected by bandwidth reservation methods, as needed, but bandwidth is otherwise shared among CTs. Each originating GEF monitors CT bandwidth use on each MPLS LSP [RFC3031] for each CT, and determines when CT LSP bandwidth needs to be increased or decreased. In Figure 2, changes in CT bandwidth capacity are determined by GEFs based on an overall aggregated bandwidth demand for CT capacity (not on a per-connection/per-flow demand basis). Based on the aggregated bandwidth demand, GEFs make periodic discrete changes in bandwidth allocation, that is, either increase or decrease bandwidth on the LSPs constituting the CT bandwidth capacity. For example, if aggregate flow requests are made for CT LSP bandwidth Ash, McDysan [Page 17] Internet Draft GCAC Algorithm Specification December 2011 that exceeds the current DSTE tunnel bandwidth allocation, the GEF initiates a bandwidth modification request on the appropriate LSP(s), which may entail increasing the current LSP bandwidth allocation by a discrete increment of bandwidth denoted here as DBW, where DBW is the additional amount needed by the current aggregate flow request. The bandwidth admission control for each link in the path is performed by the GCF function based on the status of the link using the bandwidth allocation procedure described below, where we further describe the role of the different parameters such as reserved bandwidth threshold RBT shown in Figure 2 in the admission control procedure. Also, the GEF periodically monitors LSP bandwidth use, and if bandwidth use falls below the current LSP allocation the GEF initiates a bandwidth modification request to decrease the LSP bandwidth allocation down to the current level of bandwidth utilization. HIGH-PRIORITY-CT LSP +----+======================+----+======================+----+ |GEF1|NORMAL-PRIORITY-CT LSP| VN | |GEF2| | |======================| |======================| | | |LOW-PRIORITY/BE-CT LSP| | | | +----+======================+----+======================+----+ LEGEND ------ BE - BEST EFFORT CT - CLASS TYPE GEF- GCAC EDGE FUNCTION LSP - LABEL SWITCHED PATH VN - VIA NODE o distributed bandwidth allocation method applied on a per-class-type (CT) LSP basis o GEF allocates bandwidth to each CTc LSP based on demand - GEF decides CTc LSP bandwidth increase based on + aggregate flow sustained bandwidth SBWi & variance factor VFck + routing priority (high, normal, best-effort) + CTc reserved bandwidth RBWck & bandwidth constraint BWCck + link reserved bandwidth threshold RBTk & unreserved bandwidth ULBk - GEF periodically decreases CTc LSP bandwidth allocation based on bandwidth use o VNs send crankback message to GEF if DSTE-MAR bandwidth allocation rules not met o 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 GEF uses SBWi, VFck, RBWck, BWCck, RBTk, and ULBk for LSP bandwidth allocation decisions and IGP routing, and uses RBWcl and UBWcl to track per-CT LSP bandwidth allocation and reserved bandwidth. In Ash, McDysan [Page 18] Internet Draft GCAC Algorithm Specification December 2011 making a CT bandwidth allocation modification, the GEF determines the CT priority (high, normal, or best-effort), CT bandwidth-in-use, and CT bandwidth allocation thresholds. These parameters are used to determine whether network capacity can be allocated for the CT bandwidth modification request. A.1 Example of Path Selection & Bandwidth Management Implementation In OSPF link-state flooding is used to make status updates. This is a state dependent routing (SDR) method where CSPF is typically used to alter LSP routing according to the state of the network. In general, SDR methods calculate a path cost for each connection request based on various factors such as the load-state or congestion state of the links in the network. In contrast, the example MPLS GCAC algorithm uses event dependent routing (EDR), where LSP routing is updated locally on the basis of whether connections succeed or fail on a given path choice. In the EDR learning approaches, the path last tried, which is also successful, is tried again until congested, at which time another path is selected at random and tried on the next connection request. EDR path choices can also be changed with time in accordance with changes in traffic load patterns. Success-to-the-top (STT) EDR path selection, illustrated in Figure 3, uses a simplified decentralized learning method to achieve flexible adaptive routing. The primary path path-p is used first if available, and a currently successful alternate path path-s is used until it is congested. In the case that path-s is congested (e.g., bandwidth is not available on one or more links), a new alternate path path-n is selected at random as the alternate path choice for the next connection request overflow from the primary path. Bandwidth reservation is used 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 the connection request advances to a new random path choice. In STT-EDR, many path choices can be tried by a given connection request before the request is rejected. Figure 3 illustrates the example MPLS GCAC operation of STT-EDR path selection and admission control combined with per-CT bandwidth allocation. GEF A monitors CT bandwidth use on each CT LSP, and determines when CT LSP bandwidth needs to be increased or decreased. Based on the bandwidth demand, GEF A makes periodic discrete changes in bandwidth allocation, that is, either increase or decrease bandwidth on the LSPs constituting the CT bandwidth capacity. If aggregate flow requests are made for CT LSP bandwidth that exceeds the current LSP bandwidth allocation, GEF A initiates a bandwidth modification request on the appropriate LSP(s). Ash, McDysan [Page 19] Internet Draft GCAC Algorithm Specification December 2011 |<----- ULBk <= RBTk ---->| LSP-p |------------------------|-------------------------| A B E |<-- ULBk <= RBTk -->| LSP-s |---------------|--------------------|-------------| A C D E Example of STT-EDR routing method: 1. 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 2. available bandwidth tested locally on each link in LSP-p, if bandwidth not available (e.g., unreserved bandwidth on link BE less than reserved bandwidth threshold & this CT is above its bandwidth allocation), crankback to node A 3. if DBW is not 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 4. if DBW is not available on one or more links of LSP-s, then a new LSP is searched by trying additional candidate paths until a new successful LSP-n is found or the candidate paths are exhausted 5. LSP-n is then marked as the currently successful path for the next time bandwidth needs to be modified Figure 3 STT-EDR Path Selection & Per-CT Bandwidth Allocation For example, in 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) is tried first. The bandwidth admission control for each link in the path is performed based on the status of the link using the bandwidth allocation procedure described below, where we further describe the role of the reserved bandwidth RBWck shown in Figure 3 in the admission control procedure. If the first choice LSP cannot admit the bandwidth change, node A may then try an alternate LSP. If DBW is not available on one or more links of LSP-p, then the currently successful LSP-s A-C-D-E (the 'STT path') is tried next. If DBW is not available on one or more links of LSP-s, then a new LSP is searched 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 are exhausted. LSP-n is then marked as the currently successful path for the next time bandwidth needs to be modified. DBW is set to the additional amount of bandwidth required by the aggregate flow request. If all cached candidate paths are tried without success, the search then generates a new CSPF path. If a new CSPF calculation succeeds in finding a new path, that path is made the stored path and the bottom cached path falls off the list. If all cached paths fail and a new CSPF path cannot be found, then the original stored LSP is retained. New requests go through the same routing algorithm again, since available bandwidth, etc. has changed and new requests might Ash, McDysan [Page 20] Internet Draft GCAC Algorithm Specification December 2011 be admitted. Also, GEF A periodically monitors LSP bandwidth use (e.g., once each 2 minute interval), and if bandwidth use falls below the current LSP allocation, the GEF initiates a bandwidth modification request to decrease the LSP bandwidth allocation down to the currently used bandwidth level. Bandwidth reservation occurs 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 will succeed and no CSPF calculation needs to be done. Therefore the STT-EDR algorithm achieves good throughput performance while significantly reducing link-state flooding control load [TQO]. An analogous method was proposed earlier in the MPLS working group [FEEDBACK], where feedback based on failed path routing attempts is kept by the TE data base and used when running CSPF. In the example GCAC method, bandwidth allocation to the primary and alternate LSPs uses the MAR bandwidth allocation procedure, as described below. Path selection uses a topology database that includes available bandwidth on each link. From the topology database pruned of links that do not meet the bandwidth constraint the GEF determines a list of shortest paths by using a shortest path algorithm (e.g., Bellman-Ford, Dijkstra methods). This path list is determined based on administrative weights of each link, which are communicated to all nodes within the routing domain (e.g. administrative weight = 1 + e x distance, where e is a factor giving a relatively smaller weight to the distance in comparison 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 used to implement inter-area/inter-AS/ inter-SP path selection algorithms, including alternate path selection, path reoptimization, backup path computation to protect DSTE tunnels, and inter-area/inter-AS/inter-SP traffic engineering. The DSTE tunnels are protected against failure by using MPLS Fast Reroute [RFC4090]. OSPF TE extensions [RFC4203] are used to support the TE database (TED) required for implementation of the above PCE path selection methods. The example MPLS GCAC method incorporates the MAR bandwidth constraint model [RFC4126] incorporated within DSTE [RFC4124]. In DSTE/MAR, a small amount of reserved bandwidth RBTk governs the admission control on link k. Associated with each CTc on link k are the allocated bandwidth constraints BWCck to govern 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. However, if RBWck exceeds its allocated bandwidth constraint BWCck, then the reservation bandwidth threshold RBTk cannot be accessed. In this way, bandwidth can be fully shared among CTs if available, but is Ash, McDysan [Page 21] Internet Draft GCAC Algorithm Specification December 2011 otherwise protected by bandwidth reservation methods. Therefore, bandwidth can be accessed for a bandwidth request = DBW for CTc on a given link k based on the following 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 = BWCck For an LSP on a best-effort priority CTc: allocated bandwidth BWCc = 0; DiffServ queuing serves best-effort packets only if there is available link bandwidth. In setting the bandwidth constraints for CTck, for a normal priority CTc, the bandwidth constraints BWCck on link k are set by allocating 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 is: PROPORTIONAL_ BWck = TRAF_LOAD_ BWck/[S (c) {TRAF_LOAD_ BWck, c=0, MaxCT-1}] x MRBk For normal priority CTc: BWCck = PROPORTIONAL_ BWck For a high priority CT, the bandwidth constraint BWCck is set to a multiple of the proportional bandwidth. That is: For high priority CTc: BWCck = FACTOR * PROPORTIONAL_ BWck where 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, a maximum of 10-15 percent being a reasonable guideline. Ash, McDysan [Page 22] Internet Draft GCAC Algorithm Specification December 2011 As stated above, the bandwidth allocated to a best-effort priority CTc is set to zero. That is: For best-effort priority CTc: BWCck = 0 Analysis and simulation studies show that the level of reserved capacity RBTk in the range of 3-5% of link capacity provides the best overall performance. We give a simple example of the MAR bandwidth allocation method. Assume that there are two class-types: CT0, CT1, and a particular link with MRB = 100 with the allocated bandwidth constraints set as follows: BWC0 = 30 BWC1 = 50 These bandwidth constraints are based on the forecast traffic loads, As discussed above. Either CT is allowed to exceed its bandwidth constraint BWCc as long a there is at least RBW units of spare bandwidth remaining. Assume RBT = 10. So under overload, if RBW0 = 20 RBW1 = 70 Then for this loading UBW = 100 - 20 - 70 = 10 If a bandwidth increase request = 5 = DBW arrives for Class Type 0 (CT0), then accept for CT0 since RBW0 < BWC0 and DBW (= 5) < ILBW (= 10). If a bandwidth increase request = 5 = DBW arrives for Class Type 1 (CT1), then reject for CT1 since RBW1 > BC1 and DBW (= 5) > ILBW - RBT = 10 - 10 = 0. Therefore CT0 can take the additional bandwidth (up to 10 units) if the demand arrives, since it is below its BWC value. CT1, however, can no longer increase its bandwidth on the link, since it is above its BWC value and there is only RBT=10 units of idle bandwidth left on the link. If best effort traffic is present, it can always seize whatever idle bandwidth is available on the link at the moment, but is subject to being lost at the queues in favor of the higher priority traffic. On the other hand, if a request arrives to increase bandwidth for CT1 by 5 units of bandwidth (i.e., DBW = 5). We need to decide Ash, McDysan [Page 23] Internet Draft GCAC Algorithm Specification December 2011 whether to admit this request or not. Since for CT1 RBW1 > BWC1 (70 > 50), and DBW > UBW - RBT (i.e., 5 > 10 - 10) the bandwidth request is rejected by the bandwidth allocation rules given above. Now let's say a request arrives to increase bandwidth for CT0 by 5 units of bandwidth (i.e., DBW = 5). We need to decide whether to admit this request or not. Since for CT0 RBW0 < BWC0 (20 < 30), and DBW < UBW (i.e., 5 < 10) The example illustrates that with the current state of the link and the current CT loading, CT1 can no longer increase its bandwidth on the link, since it is above its BWC1 value and there is only RBW=10 units of spare bandwidth left on the link. But CT0 can take the additional bandwidth (up to 10 units) if the demand arrives, since it is below its BWC0 value. For the example GCAC the method for bandwidth additions and deletions to LSPs in is as follows. The bandwidth constraint parameters defined in the MAR method [RFC4126] do not change based on traffic conditions. In particular, these parameters defined in [RFC4126], as described above, are configured and do not change until reconfigured: MRBk, BWCck, and RBTk. However, the reserved bandwidth variables change based on traffic: RBWck, ULBk, and ULBCck. The RBWck and bandwidth allocated to each DSTE/MAR tunnel is dynamically changed based on traffic: it is increased when the traffic demand increases (using RSVP aggregation) and it is periodically decreased when the traffic demand decreases. Furthermore, if tunnel bandwidth cannot be increased on the primary path, an alternate LSP path is tried. When LSP tunnel bandwidth needs to be increased to accommodate a given aggregate flow request, the bandwidth is increased by the amount of the needed additional bandwidth, if possible. The tunnel bandwidth quickly rises to the currently needed maximum bandwidth level, wherein no further requests are made to increase bandwidth, since departing flows leave a constant amount of available or spare bandwidth in the tunnel to use for new requests. Tunnel bandwidth is reduced every 120 seconds by 0.5 times the difference between the allocated tunnel bandwidth and the current level of the actually utilized bandwidth (i.e., the current level of spare bandwidth). Analysis and simulation modeling results show that these parameters provide 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 for signaling MPLS GCAC QoS requirements of individual flows. NSIS QoS signaling is being specified in the IETF NSIS working group, and extends RSVP signaling by defining a two-layer QoS Ash, McDysan [Page 24] Internet Draft GCAC Algorithm Specification December 2011 signaling model: o NSIS transport layer protocol (NTLP) [RFC5971] o NSIS QoS signaling layer protocol (QoS-NSLP) [RFC5974] [RFC5975] defines a QoS specification (QSPEC) object, which contains 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 to accommodate different QOSMs being used in different domains. As such, NSIS provides a mechanism for interdomain QoS signaling and interworking. The QSPEC parameters defined in [RFC5975] include, among others: TRAFFIC DESCRIPTION Parameters: o Parameters CONSTRAINTS Parameters: o , , , Parameters o Parameter o Parameter o Parameter o Parameter o & Parameters The ability to achieve end-to-end QoS through multiple Internet domains is also an important requirement. MPLS GCAC end-to-end QoS signaling ensures that end-to-end QoS is met by applying the Y.1541-QOSM [RFC5976], as now illustrated. The QoS GEF initiates an end-to-end, inter-domain QoS RESERVE message containing the QoS parameters, including for example, , , , and perhaps other parameters for the flow. The RESERVE message may cross multiple domains, each node on the data path checks the availability of resources and accumulating the delay, delay variation, and loss ratio parameters, as described below. If an intermediate node cannot 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 cannot meet the requirements designated by the RESERVE message to support a QoS parameter, for example, it cannot support the accumulation of end-to-end delay with the parameter, the node sets a flag that will deny the reservation. Also, parameter negotiation can be done, for example, by setting the to a lower class than specified in the RESERVE message. When the available must be reduced from the desired , say because the delay objective has Ash, McDysan [Page 25] Internet Draft GCAC Algorithm Specification December 2011 been exceeded, then there is an incentive to respond to the GEF with an available value for delay in the parameter. For example, if the available is 150 ms (still useful for many applications) and the desired QoS is 100 ms (according to the desired Class 0), then the response would be that Class 0 cannot be achieved and Class 1 is available (with its 400 ms objective). In addition, the response includes an available = 150 ms, making acceptance of the available more likely. A.3 Example of Queuing Implementation In this MPLS GCAC example queuing behaviors for the CT traffic priorities incorporates DiffServ mechanisms and assumes separate queues based on TC/COS bits. The queuing implementation assumes 3 levels of priority, high, normal, and best effort. These queues include two EF priority queues [RFC3246, RFC5865], with the highest priority assigned to emergency traffic (GETS/ETS/E911) and the second priority assigned to normal priority real-time (e.g., VoIP) traffic. Separate AF queues [RFC2597] are used for data services, such as premium private data and premium public data traffic, and a separate best-effort queue is assumed for the best-effort traffic. All queues have static bandwidth allocation limits applied based on the level of forecast traffic on each link, such that the bandwidth limits will not be exceeded under normal conditions, allowing for some traffic overload. In the MPLS GCAC method high-priority, normal-priority, and best-effort traffic share the same network, under congestion the DiffServ priority-queuing mechanisms push out the best-effort priority traffic at the queues so that the normal-priority and high-priority traffic can get through on the MPLS-allocated LSP bandwidth. Ash, McDysan [Page 26]