[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 6601

Network Working Group                                             G. Ash
Internet Draft                                                      AT&T
Intended status: Experimental                                 D. McDysan
<draft-ash-gcac-algorithm-spec-04.txt>                           Verizon
Expires: August, 2012                                  February 24, 2012


               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, as
   one motivational 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 August 24, 2012.

Copyright Notice

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 1]

Internet Draft        GCAC Algorithm Specification       February 2012


   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, 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  . . . . . . . . . . . . . . . . . . . 6
      2.2 MPLS GCAC Algorithm Summary  . . . . . . . . . . . . . . . 6
   3. MPLS GCAC Algorithm  . . . . . . . . . . . . . . . . . . . . . 9
      3.1 Bandwidth Allocation Parameters  . . . . . . . . . . . . . 10
      3.2 GCAC Algorithm . . . . . . . . . . . . . . . . . . . . . . 12
   4. Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   5. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   7. Normative References . . . . . . . . . . . . . . . . . . . . . 17
   8. Informative References . . . . . . . . . . . . . . . . . . . . 17
   9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
   Appendix A: Example MPLS GCAC Implementation Including Path
               Selection, Bandwidth Management, QoS Signaling, &
               Queuing . . . . . . . . . . . . . . . . . . . . . . . 19
      A.1 Example of Path Selection & Bandwidth Management
          Implementation . . . . . . . . . . . . . . . . . . . . . . 20
      A.2 Example of QoS Signaling Implementation  . . . . . . . . . 26
      A.3 Example of Queuing Implementation  . . . . . . . . . . . . 27

1. Introduction

   This document presents a generic connection admission control (GCAC)
   reference model and algorithm for IP/MPLS-based networks.  Service

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 2]

Internet Draft        GCAC Algorithm Specification       February 2012


   provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, as one
   motivational 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.  That is, they should first experiment
   with the GCAC algorithm in their laboratories and test networks. When
   testing in live networks, they should install the GCAC algorithm on
   selected routers in only part of their network, and they should
   carefully monitor the effects.  The installation should be managed
   such that the routers can quickly be switched back to normal
   operation if any problem is seen.

   Since application of GCAC is most likely in Enterprise VPNs and/or
   internal TE infrastucture, it is RECOMMENDED that the experiment be
   conducted in such applications and it is NOT RECOMMENDED that the
   experiment be conducted in the Internet.  If possible the

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 3]

Internet Draft        GCAC Algorithm Specification       February 2012


   experimental configuration will address interoperability issues, such
   as, for example, use of different constraint models across different
   traffic domains.

   The experiment can monitor various measures of quality of service,
   before and after deployment of GCAC, particularly when the
   experimental network is under stress during an overload or failure
   condition.  These quality-of-service measures might include, for
   example, dropped packet rate and end-to-end packet delay.  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 as described above, and should only be carried out after
   successful simulation and experimentation in test environments.
   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  |

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 4]

Internet Draft        GCAC Algorithm Specification       February 2012


      |    |     |      |==========================>| 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
   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.


Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 5]

Internet Draft        GCAC Algorithm Specification       February 2012


   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
   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

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 6]

Internet Draft        GCAC Algorithm Specification       February 2012



   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
   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

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 7]

Internet Draft        GCAC Algorithm Specification       February 2012


   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
   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.

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 8]

Internet Draft        GCAC Algorithm Specification       February 2012



   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 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
   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.

   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.  Such advertisements should not require nodes to
   expose detailed and up-to-date CAC information, which may result in
   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.


Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 9]

Internet Draft        GCAC Algorithm Specification       February 2012


   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 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].

   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

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 10]

Internet Draft        GCAC Algorithm Specification       February 2012


          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,
         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

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 11]

Internet Draft        GCAC Algorithm Specification       February 2012


   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

   UBWLcl unreserved bandwidth for CTc on LSP l

3.2 GCAC Algorithm

   The assumption behind the MPLS GCAC is that the ratio between the
   bandwidth margin the node is putting above the sustained bandwidth
   and the standard deviation of the sustained bandwidth 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

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 12]

Internet Draft        GCAC Algorithm Specification       February 2012


   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
   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 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, 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

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 13]

Internet Draft        GCAC Algorithm Specification       February 2012


   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)

   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)



Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 14]

Internet Draft        GCAC Algorithm Specification       February 2012



          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,
   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

   It needs to be clearly understood that all routers contain local and
   implementation-specific rules (or algorithms) to help them determine
   what to do with traffic that exceeds capacity, and how to admit new
   flows. If these rules are poorly designed or implemented with
   defects, then problems may be observed in the network. Furthermore,
   the implementation of such algorithms provides a mechanism for
   attacking the delivery of traffic within the network. In view of
   this, routers and their software are usually extensively tested
   before deployment, router vendors are extended a degree of trust, and
   a "compromised router" (i.e. one on which an attacker has installed
   their own code) is considered a weak spot in the system. Note that if
   a router is compromised it can be made to do substantially more
   problematic things than simply modifying the admission control
   algorithm. Implementers are RECOMMENDED to ensure that software
   modifications to routers are fully secured, and operators are
   RECOMMENDED to apply security measures (that are outside the scope of
   this document) to prevent unauthorized updates to router software.
   Nothing in this document suggests any change to normal software
   security practices.

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 15]

Internet Draft        GCAC Algorithm Specification       February 2012



   The 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 user attacks at the interface to the user,
   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.

   - If an attack occurs the user/group and actions taken should be
     logged to trace the attack.

   Within the network the policy and integrity mechanisms already
   present in RSVP-TE [RFC3209] can be used to ensure that the MPLS LSP
   has the right policy and security credentials to assume the signaled
   priority and bandwidth. Further discussion of this topic for the
   signaling of priority levels using RSVP can be found in [RFC6401].
   Some similarities may also be drawn to the security issues
   surrounding the placement of emergency calls in Internet multimedia
   systems [RFC5069] although the concepts are only comparable at the
   highest levels.

   Like any algorithm, the algorithm specified in this document operates
   on data that is supplied as input parameters. That data is assumed to
   be collected and stored locally (i.e. on the router performing the
   algorithm). It is a fundamental assumption of the secure operation of
   any router that the data stored on that router cannot be externally
   modified. In this particular case, it is important that the input
   parameters to the algorithm cannot be influenced by an outside party.
   Thus, as with all configuration parameters on a router, the
   implementer MUST supply and the operator is RECOMMENDED to use
   security mechanisms to protect writing of the configuration
   parameters for this algorithm.

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.


Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 16]

Internet Draft        GCAC Algorithm Specification       February 2012


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
            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

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 17]

Internet Draft        GCAC Algorithm Specification       February 2012


             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.
   [RFC5069] Taylor, T., et al., "Security Threats and Requirements for
             Emergency Call Marking and Mapping", RFC 5069, January
             2008.
   [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.
   [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.
   [RFC6401] Le Faucheur, F., et al., "RSVP Extensions for Admission
             Priority", RFC 6401, October 2011.
   [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

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 18]

Internet Draft        GCAC Algorithm Specification       February 2012


   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
   that exceeds the current DSTE tunnel bandwidth allocation, the GEF
   initiates a bandwidth modification request on the appropriate LSP(s).
   This 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


Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 19]

Internet Draft        GCAC Algorithm Specification       February 2012


   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
   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

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 20]

Internet Draft        GCAC Algorithm Specification       February 2012


   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).

                                    |<----- 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

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 21]

Internet Draft        GCAC Algorithm Specification       February 2012


   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
   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].


Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 22]

Internet Draft        GCAC Algorithm Specification       February 2012


   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
   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

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 23]

Internet Draft        GCAC Algorithm Specification       February 2012



   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.

   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).


Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 24]

Internet Draft        GCAC Algorithm Specification       February 2012


   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
   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

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 25]

Internet Draft        GCAC Algorithm Specification       February 2012


   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 has been specified by the IETF NSIS
   working group, and extends RSVP signaling by defining a two-layer QoS
   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 <Traffic Model> Parameters

CONSTRAINTS Parameters:

   o <Path Latency>, <Path Jitter>, <Path PLR>, <Path PER> Parameters
   o <PHB Class> Parameter
   o <DSTE Class Type> Parameter
   o <Y.1541 QoS Class> Parameter
   o <Reservation Priority> Parameter
   o <Preemption Priority> & <Defending Priority> 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,
   <Traffic Model>, <Y.1541 QoS Class>, <Reservation Priority>, and

Ash, McDysan      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 26]

Internet Draft        GCAC Algorithm Specification       February 2012


   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 <Path Latency>
   parameter, the node sets a flag that will deny the reservation.
   Also, parameter negotiation can be done, for example, by setting the
   <Y.1541 QoS Class> to a lower class than specified in the RESERVE
   message.  When the available <Y.1541 QoS Class> must be reduced from
   the desired <Y.1541 QoS Class>, say because the delay objective has
   been exceeded, then there is an incentive to respond to the 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 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 <Path
   Latency> = 150 ms, making acceptance of the available <Y.1541 QoS
   Class> 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      <draft-ash-gcac-algorithm-spec-04.txt>      [Page 27]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/