Auto-bandwidth and admission control

Theoretical foundations and architecture

Real traffic changes over the day: the peak can be many times the night level. Static RSVP-TE reservations lead to over- or under-accounting of bandwidth. Auto-Bandwidth adjusts the reservation to the load. At a configured interval the head-end measures the tunnel traffic (the sampling interval, 300 s by default on Cisco and Junos) and, over the adjust-interval window (24 hours by default on both platforms), picks the maximum of the averaged samples. If it differs from the current reservation by more than the threshold and fits within min/max, the tunnel is re-signaled make-before-break: a new LSP is signaled with the same SESSION and a new LSP ID, traffic is switched and only then is the old LSP torn down. MBB reduces loss during the switchover but does not guarantee its absence. DS-TE divides link capacity into Class Types (for example CT1 for voice, CT0 for the rest) and lets bandwidth be reserved per class.

A reservation is not the load

Bandwidth in RSVP-TE is an accounting value in the control plane: it is subtracted from the unreserved bandwidth in the TED but restricts nothing in the data plane. An LSP with a 50 Mbit/s reservation can carry 400 Mbit/s, and the router will not drop a single packet on that basis; the only bottleneck will be the interface queue. Therefore a reservation makes sense in two cases only: when it reflects the real load and when all tunnels declare it honestly. Keeping this correspondence by hand is impossible: the load changes several times over during the day. This is what Auto-Bandwidth solves.

How Auto-Bandwidth works

The head-end periodically measures the volume of traffic entering the tunnel (the counters of the tunnel interface or the LSP) and uses them to adjust the reservation. Two intervals must not be confused:

• The sampling interval: how often the counter is read. Cisco sets it with mpls traffic-eng auto-bw timers frequency (300 s by default), Junos with statistics interval (300 s by default); statistics must also be enabled for auto-bandwidth.
• The adjust interval: the window over which the maximum of the averaged samples is chosen. On Cisco it is auto-bw frequency on the tunnel, on Junos adjust-interval; the default on both platforms is 24 hours (86400 s), typical production values range from tens of minutes to several hours.

At the end of the window the head-end compares the maximum averaged load with the current reservation. If the difference exceeds the threshold (Cisco adjustment-threshold, Junos adjust-threshold, in percent) and the new value fits within the minimum-maximum range (min-bw/max-bw, minimum-bandwidth/maximum-bandwidth), a re-signaling is started. For a quick reaction to a sharp increase an overflow counter is used: if several samples in a row (the overflow limit) exceed the threshold, the adjustment happens early, without waiting for the end of the window. The same works for decreases (underflow limit in Junos).

The collect-only mode (collect-bw on Cisco, monitor-bandwidth on Junos) gathers statistics without changing the reservation: useful for choosing thresholds before enabling the feature.

Make-before-break and bandwidth accounting

A reservation change is performed without a traffic break: the head-end signals a new LSP with the same SESSION and a new LSP ID, receives Resv, switches traffic and only then sends PathTear for the old one. The SE style lets the new and old LSP on shared links share a single reservation, so the bandwidth is counted as a maximum, not a sum: growing from 100 to 180 Mbit/s requires 180, not 280 Mbit/s, on the shared links. If the new path does not overlap the old one, the bandwidth of the new one is additionally occupied for the duration of the transition.

If the reservation does not fit, the adjustment fails: the old LSP keeps working with its previous bandwidth, and the head-end retries in the next interval. Meanwhile the real load is already above the reservation, and the other tunnels see only part of the link as occupied according to the TED. This is the main risk of Auto-Bandwidth: without monitoring of adjustment failures you get under-accounting and congestion. Monitor failed-resize events (syslog, SNMP) alongside interface utilization.

Side effects: every adjustment is signaling (Path/Resv and PathTear) and TE LSA flooding; with thousands of tunnels and a short interval an update storm appears. The same interval on all tunnels synchronizes the adjustments; in practice randomness is introduced through different timer values or a delayed start. A failed resize must not lead to path "ping-pong": the threshold (adjust-threshold) and the minimum delta are needed for hysteresis.

DS-TE: reservation by class

An ordinary reservation divides one pool among everyone: CT0. DS-TE (RFC 3564 - requirements, RFC 4124 - protocol) introduces Class-Types (CT0-CT7): separate pools so that voice traffic does not compete for the same bandwidth as data. Each pair (CT, priority) is called a TE-class, and there can be up to 8 of them; the mapping is set by the administrator and must be identical across the whole domain.

Per-class limits are expressed by Bandwidth Constraints (BC0-BC7) and by the models of how they interact:

Example for an 800 Mbit/s link: RDM, BC0 = 800 (CT0 + CT1 together), BC1 = 200 (CT1 alone). Voice (CT1) can take up to 200, the rest is data; when voice is 150, 650 remain for data. With MAM, for example BC0 = 600, BC1 = 200: voice will not take more than 200, but data will not get more than 600 either, even if there is no voice.

The IGP carries the BCs in the Bandwidth Constraints sub-TLV, and the unreserved bandwidth as 8 values interpreted as TE-classes. RSVP receives the CLASSTYPE object (Class-Num 66): a CT value of 1-7 in Path; absence of the object means CT0, so DS-TE nodes are compatible with ordinary ones. Admission control checks not only the total free bandwidth but also the BC of its class at the required priority.

What must not be forgotten: DS-TE is only a control-plane reservation. Priority of voice traffic in the data plane is provided by queues: CT1 LSPs must be bound to a class with a priority queue (EXP/DSCP), and this is a separate QoS configuration (see the QoS module). Without it, voice and data still compete in one queue despite the nice reservation.