Download - Resource Reservation Protocol and Admission Control

Resource Reservation Protocoland

Admission Control

Resource Management

Motivation

• Resource management in the access networks is important:

– Needed to identify and monitor the bottleneck in the networks.

– Needed to allocate network resources more efficiently to support a wide variety of services.

• Resource reservation might be necessary to provide QoS guarantees, but we need to address the scalability issues:

– Signaling overhead;

– Overhead caused by maintenance of the reservation state;

Overhead can be reduced by aggregating flows or reservation requests.Overhead can be reduced by aggregating flows or reservation requests.

Basic Concepts

• Resource reservation and allocation;– The manageable resources

• Bandwidth, buffer, CPU time, and etc.;– Traffic description, resource descriptor and SLA– The SLA

• SLA parameters– Traffic level;– Provider’s responsibilities in terms of network levels (throughput, loss rate,

delays and jitter);– Times of availability;– Method of measurement;– Consequences if service levels aren't met or the defined traffic levels are exc

eeded by the customer;– All costs involved– Traffic conditioning rules– …

Basic Concepts (cont’d)

• Resource reservation and allocation;– The SLA (cont’d)

• Service Level Specification, the details of the operational characteristics for an SLA are further defined in terms of Service Level Specifications (SLS) and/or Objectives (SLOs).

– expected throughput, drop probability, latency;– constraints on the ingress and egress points at which the service is provided,

indicating the `scope' of the service;– traffic profiles which must be adhered to for the requested service to be prov

ided;– disposition of traffic submitted in excess of the specified profile;– marking and shaping services provided.– An SLO partitions an SLA into individual objectives that can be mapped into policies

that can be executed. The SLOs define metrics to enforce, police, and/or monitor the SLA. Some commonly used metrics to determine whether or not an SLA is being fulfilled include component system availability (e.g., up-time and MTBF), performance (e.g., response time), and serviceability (e.g., MTTR).

Basic Concepts (cont’d)• Resource reservation and allocation;

– The SLA (cont’d)• Traffic Conditioning Specifications

– Traffic conditioning control functions that can be applied to a behavior aggregate, application flow, or other operationally useful subset of traffic, e.g., routing updates.

– These may include metering, policing, shaping, and packet marking. Traffic conditioning is used to enforce agreements between DiffServ domains, for example.

– A Traffic Conditioning Agreement (TCA) is an agreement specifying classifier rules and any corresponding traffic profiles and metering, marking, discarding and/or shaping rules which are to apply to the traffic streams selected by the classifier.

– A TCA encompasses all of the traffic conditioning rules explicitly specified within a SLA along with all of the rules implicit from the relevant service requirements.

Core: traffic description, required service and resource descriptorCore: traffic description, required service and resource descriptorIssue: how to define the optimal value of the amount of the requested resource Issue: how to define the optimal value of the amount of the requested resource


– The SLA (cont’d)• Example


– Reservation mechanism and Admission control (discussed in this section);

– Packet Classifier;

– Policing and shaping • the enforcement mechanism;

• commonly-used mechanism;– Leakey bucket;

– Token bucket;

• Congestion avoidance methods;

– The scheduling and queuing management (discussed in next section)• Link layer mechanisms;

• To implement actually the resource allocation to achieve certain QoS level;

The Typical Overall Structure

Application

RSVPD

AdmissionsControl

PacketClassifier

PacketScheduler

PolicyControl

DATA

DATA

RSVPD

PolicyControl

AdmissionsControl

PacketClassifier

PacketScheduler

DATA

RoutingProcess

Host Router

Policy control determines whether the user has administrative permission to make the reservation.

Principles of Resource Management ReservationReservation

Network resources are shared by users, but the sharing process is regulated by the QoS mechanism, e.g. by using admission control;

AllocationAllocation

Network resources are allocated, or assigned, to a user, however, the network may temporarily reallocate some of the resources to other users in case when it detects that they are not fully used or if a severe congestion situation occurs;

DedicationDedication

Network resources are dedicated to each communication. There is no overbooking, nor reallocation of unused resources during the communication;

Best-effortBest-effort

Network resources are shared by all users, and there is not any regulations at all. best-effort reservati on al l ocati on dedi cation

l oose ti ght

Principles of Resource Management(cont’d)

Deterministic guaranteesDeterministic guarantees

Generally speaking, upper bounds are provided for the performance parameters;

Statistical guaranteesStatistical guarantees

As for the performance parameters, they are determined by some average numbers observed over a period of time, generally the duration of the session.

Best-effort Best-effort no guarantees no guarantees

Reservation Reservation statistical guarantees statistical guarantees

Allocation Allocation statistical or deterministic guarantees statistical or deterministic guarantees

Dedication Dedication deterministic guarantees deterministic guarantees

Two types of guaranteed performance:Two types of guaranteed performance:

Resource Oversubscription

• The obvious solution to handle peak periods is to over-provision the network, to provide surplus bandwidth capacity in anticipation of these peak data rates during high-demand periods.

• Equally obvious, however, is that this is not economically viable--at least not with today's bandwidth technologies and infrastructures – and especially for WAN links.

• Since peak data rates and the network regions on which they might occur are seldom possible to predict, this is not a realistic alternative anyway.

• IP is necessary and bandwidth is necessary, but neither is sufficient for all application needs under all conditions.

– Best effort cannot always provide a usable service, let alone an acceptable one.– Even on a relatively unloaded IP network, delivery delays can vary enough to a

dversely affect applications that have real-time constraints. – To provide service guarantees--some level of quantifiable reliability--IP services

must be supplemented with the ability to differentiate traffic and enable different service levels for different users and applications.

However, QoS mechanism is necessary!However, QoS mechanism is necessary!

Resource Reservation Protocol---The Typical Resource Reservation Mechanism

Reservation protocol: RSVP

Upper layer protocols and applications

IP

Link layer modules

ICMP IGMP RSVP

IP service interface

Link layer service interface

Documents• RFC 2205:Resource ReSerVation Protocol (RSVP)-

Version 1 Functional Specification• RFC 2207:RSVP Extensions for ISPEC Data Flows• RFC 2209:Resource ReSerVation Protocol (RSVP)-

Version 1 Message Processing Rules• RFC 2210: The Use of RSVP with Integrated

Services• RFC 2211: Specification of the Controlled-Load

Network Element Service

Documents (cont’d)• RFC 2212:Specification of Guaranteed Quality of Service

• RFC 2215:General Characterization Parameters for Integrated Service Network Elements

• RFC 2216:Network Element Service Specification Template

Integrated Services

Integrated Services

FlowDescription

PolicyTrafficControl

Services Link-LayersQoS

RoutingSignaling

RSVP

Traffic Descriptors

Service Descriptors

AdmissionControl

Classifier

Scheduler

Guaranteed

ControlledLoad

BestEffort

Point-to-point

ATM

IEEE 802LANs

Low-bit-rate

RSVP

Integrated Services

• Classes of QoS on a per-flow basis• Request for QoS from hosts

– reservation protocol (RSVP)

• Reservation requires– Source traffic envelop

• Two-stage token bucket

– Level of resources required

– Admission Control

– Scheduling, Policing

Guaranteed Service• Provides a maximum end-to-end delay bound and

no queuing loss for conforming packets guarantees (via bandwidth reservation).

• Source traffic characteristics (Tspec)– peak rate (p), bucket depth (b), token rate (r), min.

policed unit (m), max. packet size (M)

• Reservation characteristics (Rspec)– bandwidth (R), slack term (S)

Guaranteed Service

• Two-stage token bucket

pdata

r

b

X r T+b

X Min(r T+b, pT+M)p rb > M

M

tottot D

R

CM

rpR

RpMb

)(

)(

))((

tottot D

R

CM

)(

Guaranteed Service

• End-to-end delay bound– Without consideration of packet size

• b/R + C/R + D

– Consider max. packet size• p > R r

• R p r

Guaranteed Service

• Parameters– C: rate-dependent error term (delay experienced

due to rate parameter, e.g., fragmentation of a packet into ATM cells)

– D: rate-independent error term (e.g., waiting for a slot in a slotted network)

– Ctot:end-to-end value of C

– Dtot:end-to-end value of D

Guaranteed Service

• Policing and reshaping– Traffic must be policed at the edge of networks

– Nonconforming packets are served by best-effort

– Reshaping traffic to token bucket inside the network• At a branching point where incoming branch is the max. of

outgoing branches

• At a merging point where many incoming branches are shared with one outgoing branch

Controlled-Load Service

• Commitment to offer the flow of a service equivalent to that seen by a best-effort flow on a lightly loaded network– Grade of service should not deteriorate as

network load increases

• Similar requirements as Guaranteed Service– Tspec, Policing, Admission– No end-to-end guarantee (Rspec)

Introduction of RSVP• A resource reservation setup protocol designed for an

integrated services network.• RSVP is receiver oriented

– Used by a host to request a specific QoS from the network.

– QOS parameters are defined in RFC 2210

• RSVP reserve resources for simplex data streams• Operates on top of IPv4 or IPv6

– port 46

Introduction of RSVP

• RSVP is not a routing protocol– Reserve resources along the existing route set up by

some routing protocols– E.g., in the multicast case, a host sends IGMP messages

to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group.

• RSVP identifies a session by (destination address, transport protocol id, destination port number)– TCP=6, UDP=17

Introduction of RSVP

• RSVP maintains soft state in routers and hosts– RSVP sends periodic refresh messages to

maintain the state along the reserved path(s)– In absence of refreshes, the state will

automatically time out and be deleted.

• Provides three reservation models (styles)

RSVP in Hosts and Routers

ApplicationRSVP

process

policy Control

packet classifier

packet scheduler

admission control

Routing process

RSVP

process

policy Control

packet classifier

packet scheduler

Admission control

RSVP

data data

host router/switch

RSVP Functions of Hosts/Routers

• Policy Control– administration

• Traffic Control– Packet classifier

• determine QoS class

– Admission control• check for resources

– Packet scheduler• determine when to send a particular packet

RSVP Messages• Common Header Format

• Message type– 1: Path 2: Resv– 3: PathErr 4: ResvErr– 5: PathTear 6: ResvTear– 7: ResvConf

0 1 2 3

vers Flags RSVP Checksum

RSVP Length

Msg Type

Send TTL Reserved

RSVP Messages

• Object format

• Class-num: – NULL(0), SESSION(1), RSVP_HOP(3), INTEGRITY(4),

TIME_VALUES(5), ERROR_SPEC(6), SCOPE(7), STYLE(8), FLOWSPEC(9), FILTER_SPEC(10), SENDER_TEMPLATE(11), SENDER_TSPEC(12), ADSPEC(13), POLICY_DATA(14), RESV_CONFIRM(15)

0 1 2 3

Length (bytes) Class-num C-Type

Object contents

RSVP Messages

R1 R2

R3

R4

S1

RCV1

RCV2

RCV3

ResvResvTearPathErr

PathPathTearResvErrResvConf

Class Number• NULL• SESSION: (DestAddr, Protocol ID, Port)• RSVP_HOP: IP of previous or next RSVP-capable

node• TIME_VALUES: refresh period• STYLE: reservation style (required in a Resv

message)• FLOWSPEC: define QoS in a Resv message• FILTER_SPEC: define a subset of session data

that should receive the desired QoS in a Resv message

Class Number• SENDER_TEMPLATE: sender IP, port number,

flow label in a Path message• SENDER_TSPEC: source traffic char. (Path)• ADSPEC: OPWA data in a Path message• ERROR_SPEC: error in a PathErr, ResvErr, or

ResvConf message• POLICY_DATA: info. for administration (Path,

Resv, PathErr, ResvErr)• INTEGRITY: cryptographic data• SCOPE: list of hosts to be forwarded• RESV_CONFIRM: receiver that needs conf.

Path Message

• <Path Message> ::= <Common Header> [<INTEGRITY>] <SESSION> <RSVP_HOP> <TIME_VALUES> [<POLICY_DATA>…] [<sender descriptor>]

• <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> [<ADSPEC>]

Path Message• RSVP_HOP (P_HOP): last RSVP-capable

node• Sender Template

– Sender IP, port number (IPv4/IPv6), flow label (IPv6) (content is identified by C_TYPE)

• Sender Tspec:– r, b, p, m, M

• Adspec– Default General Parameters, Guaranteed

Service, and/or Controlled-load Service

Sender TSpec Object0 1 2 3

r

b

p

m

M

ver reserved

reserved

overall length

service # (1) length of service 1 data

Parm id (127) flags Parm 127 length

TokenBucketTspec

Processing Path Message

• Update path state– if absent, create one– path state: sender Tspec, Phop, Adspec

• Set cleanup timer, restart timer– expiration of cleanup timer triggers deletion of path

state

• Path message is generated and forwarded– changes of path state– route changes– every refresh period (soft state)

ADSPEC

• Default General Parameters– Minimum path latency (no queuing delay)– Path bandwidth (min. of link bandwidth)– Global break bit (exist of non-RSVP-capable)– IS hop count– PathMTU

• Used by received to reset M of sender Tspec

ADSPEC• Guaranteed Service fragment

– Ctot: end-to-end value for C

– Dtot: end-to-end value for D

– Csum: composed value for C since last reshaping point

– Dsum: composed value for D since last reshaping point

– Guaranteed Serrvice Break bit

– Guaranteed Service General Parameters Headers/Values• overrides the corresponding value given in the Default General

Parameters

• e.g., reduced path bandwidth for Guaranteed service

ADSPEC

• Controlled-Load Service fragment– Controlled-Load Service Break bit– Controlled-Load Service General Parameters

Header/Values

One Pass With Advertising (OPWA)

• Sender includes Adspec in a path message for receiver to determine the end-to-end service– Compute R and slack term based on

• Sender Tspec: r, b, p, m

• Adspec: path bandwidth, path MTU, Ctot , Dtot

Resv Message

• <Resv Message> ::= <Common Header> [<INTEGRITY>] <SESSION> <RSVP_HOP> <TIME_VALUES> [<RESV_CONFIRM>] [<SCOPE>] [<POLICY_DATA>…] <STYLE> <flow descriptor list>

• <flow descriptor list> ::= <empty> | <flow descriptor list> <flow descriptor>

Resv Message• Three reservation styles: WF, FF, SE• flow descriptor

– WF Style<flow descriptor list> ::= <WF flow descriptor><WF flow descriptor> ::= <FLOWSPEC>

– FF Style<flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC> | <flow descriptor list> <FF flow descriptor>

<FF flow descriptor> ::= <FLOWSPEC> <FILTER_SPEC>– SE Style

<flow descriptor list> ::= <SE flow descriptor><SE flow descriptor> ::= <FLOWSPEC> <filter spec list><filter spec list> ::= <FILTER_SPEC> | <filter spec list> <FILTER_SPEC>

– flowspec consists of Rspec and Tspec– filterspec is used to identify the sender(s). It has the same format as sender template.

FLOWSPEC Object (Controlled-Load)

0 1 2 3

r

b

p

m

M

ver reserved

reserved

overall length



FLOWSPEC Object (Guaranteed)

0 1 2 3

r

bpmM

ver reserved

reserved

overall length



Parm id (130) flags Parm 130 lengthRS

Reservation Style

• Types of reservation style– One concerns the treatment of reservations for different

senders within the same session : establish a distinct reservation for each upstream sender, or else make a single reservation that is shared among all packets of selected senders.

– Another controls the selection of senders; an explicit list of all selected senders, or a wildcard that implicity selects all the senders to the session.

Reservation Style

• Fixed-Filter (FF) Style• Shared-Explicit (SE) Style• Wildcard-Filter (WF) Style

SenderSelection

Reservation

Distinct Shared

Explicit

Wildcard

Fixed-Filter (FF) Style

Shared-Explicit (SE) Style

Wildcard-Filter (WF) Style(None

defined)

Reservation Style

• Wildcard-Filter (WF) Style– Shared reservation and wildcard sender selection. – Creates a single reservation shared by all upstream

senders.– WF ( *{Q} )

• Shared Explicit (SE) Style– Shared reservation and explicit sender selection.– Creates a single reservation shared by selected

upstream senders.– SE ( {S1,S2,...}, {Q} )

• WF and SE styles are appropriate for those multicast applications in which multiple data sources are unlikely to transmit simultaneously (packetized audio).

Example of WF Style

WF(*{5B})WF(*{2B})

Incoming resv message

WF(*{3B})WF(*{2B})

WF(*{4B})

Reserve(*{5B})

Reserve(*{3B})

Reserve(*{4B})

Ourgoing resv message

WF(*{5B})

WF(*{5B})

WF(*{5B})

To S1, S2

To S3, S4

To S5, S6

Example of SE Style

SE((S2,S4){5B})SE((S1,S2){2B})


SE((S4){3B})SE((S4,S6){2B})

SE((S2,S3,S5){4B})

Reserve((S1,S2,S4){5B})

Reserve((S4,S6){3B})

Reserve((S2,S3,S5){4B})


SE((S1,S2){5B})

SE((S3,S4){5B})

SE((S5,S6){4B})

To S1, S2

To S3, S4

To S5, S6

Reservation Style

• Fixed-Filter (FF) Style– Distinct reservation and explicit sender selection.– Creates a distinct reservation for data packets from a

particular sender.– FF ( S {Q} ) <= a flow descriptor– FF ( S1 {Q1}, S2 {Q2}, ... ) : The total reservation is

the sum of Q1, Q2, ...

– FF style is appropriate for the flows from different senders (video signals).

Example of FF Style

FF(S1{2B},S2{3B}, S4{5B})FF(S1{4B},S2{2B})


FF(S4{4B})FF(S2{6B},S4{2B}, S6{2B})

FF(S2{3B},S3{2B}, S5{4B})

ReserveS1{4B}S2{3B}S4{5B}ReserveS2{6B}S4{4B}S6{2B}ReserveS2{3B}S3{2B}S5{4B}


FF(S1{4B}, S2{6B})

FF(S3{2B}, S4{5B})

FF(S5{4B}, S6{2B})

To S1, S2

To S3, S4

To S5, S6

Slack Term of Rspec• With a zero slack term, each router along the

path must reserve R bandwidth

• A nonzero slack term offers the individual routers greater flexibility in making their local reservation– Due to different scheduling mechanisms– Lack of bandwidth– Must ensure

inoutin

itot

inin

out

itot

outout RRr

R

C

R

bS

R

C

R

bS

Example of Slack Term

R1 R2 R3 R4 R5sender receiver

Resv(R=2.5M,S=0)

3.5Mb/s4Mb/s2Mb/s4Mb/s5Mb/s

ResvErr

R1 R2 R3 R4 R5sender receiver

Resv(R=3M,S>0)

3.5Mb/s4Mb/s2Mb/s4Mb/s5Mb/s

Resv(R=2M,S-d)

Tspec: r = 1.5Mb/s

Admission Control

• Admission Control: attempts to answer the question

– “given the current network condition, with already admitted flows, and a request for a new flow with QoS requirements, can the network admit the new flow and still satisfy the QoS for all flows”

• if yes, then admit

• if No, then block or reject

– Requires a description of the traffic for the new flow and the QoS requirements

– Multiplexing model, used in calculation or estimation of the bandwidth requirements for the aggregated flows;

– Metrics, used to evaluate the QoS for individual flow or all flows;

– Algorithm or mechanism, used to measure and estimate the current network conditions;

Basic Concepts

Basic concepts (cont’d)

• Hard Guarantee– No tolerance for violations;

– Admission control algorithms for guaranteed service use the a priori characterizations of sources to calculate the worst-case behavior of all the existing flows .

– Network utilization under this model is usually acceptable when flows are smooth; when flows are bursty, however, guaranteed service inevitably results in low utilization.

Basic concepts (cont’d)• Statistical Guarantee

– Some amount of QoS guarantee violation, usually bounded by some probability values.

• Soft Guarantee– It guarantees a fairly (not absolute or even probabilistic, e.g. C service in ISPN) b

ound on the rate of lost/late packets based on statistical characterization of traffic.

• Predictive service, statistical guarantee or soft guarantee;• For tolerant applications, e.g. vat, nv, vic, which can adapt to actual packet d

elays and are thus rather tolerant of occasional delay bound violations; they do not need an absolutely reliable bound.

• The ability to occasionally incur delay violations gives admission control a great deal more flexibility, and is the chief advantage of this type of service.

• Fairly bounds (not absolutely) flexibility and high utilization;– In this approach, each flow is allotted an effective bandwidth that is larger than it

s average rate but less than its peak rate.– In most cases, the equivalent bandwidth is computed based on a statistical model

of traffic.

• It will be quite difficult, if not impossible, to provide accurate and tight statistical models for each individual flow. (e.g. real time applications)


Basic ComponentsBasic Components


• Traffic descriptor– A traffic descriptor is a set of parameters that characterizes a traffic source;– Typically, sources are described by either peak and average rates or a filter like a

token bucket ;– These descriptions provide upper (or loosed) bounds on the traffic that can be

generated by the source.

• Admission criteria are the rules by which an admission control scheme accepts or rejects a flow. Since the network resources allocated to a traffic class are shared by all the flows of that class, the decision to accept a new flow may affect the QoS commitments made to the admitted flows of the particular class. The new flow can also affect the QoS of flows in lower priority classes. Therefore, an admission control decision is usually made based on an estimation of the effect the new flow will have on other flows and the utilization target of the network.

Basic Components (cont’d)Basic Components (cont’d)


Basic Components (cont’d)Basic Components (cont’d)

The logical entity that takes measurements of the network dynamics and provides the measurement information to the admission control algorithm.

Why measurementWhy measurement

It is observed that real-time traffic sources are very difficult to characterize and the token bucket parameters may only provide a very loose upper bound of the traffic rate

When the real traffic becomes very bursty, the network utilization can get very low if admission control is solely based on the parameters provided at call setup time.

Therefore, the admission control unit should monitor the network dynamics Therefore, the admission control unit should monitor the network dynamics and use measurements such as instantaneous network load and packet delay and use measurements such as instantaneous network load and packet delay to make its admission decisions. Schemes based on measurements are called to make its admission decisions. Schemes based on measurements are called measurement-based admission control (MBAC) schemes.measurement-based admission control (MBAC) schemes.

Classification of ADC• Classification of ADC mechanisms (1)

– Measurement-based and parameter-based• depending on whether the admission control unit uses

measured values as a substitute of the parameters.

• Classification of ADC mechanisms (2)– Rate-based and delay-based;

• depending on whether the admission control unit performs delay checking;

• Only bandwidth checking rate-based;

• Bandwidth checking + delay checking delay-based;– Usually for the traffic class requiring hard guarantees, e.g. the G-

service in IntServ.

Measurement-based approach

• The measurement-based admission control approach uses the a priori source characterizations only for incoming flows (and those very recently admitted); it uses measurements to characterize those flows that have been in place for a reasonable duration.

• Therefore, network utilization does not suffer significantly if the traffic descriptions are not tight.

• Because it relies on measurements, and source behavior is not static in general, the measurement-based approach to admission control can never provide the completely reliable delay bounds needed for guaranteed, or even probabilistic, service; thus, measurement-based approaches to admission control can only be used in the context of predictive service and other more relaxed service commitments.

• Furthermore, when there are only a few flows present, the unpredictability of individual flow’s behavior dictates that these measurement based approaches must be very conservative—by using some worst-case calculation for example.

• Thus, a measurement based ADC can deliver significant gain in utilization only when there is a high degree of statistical multiplexing.

Rate–Based Approaches• Rate sum approach

– To ensure that the sum of the existing reservations and the new flow’s rate does not exceed a threshold.

– This scheme does not make any assumptions about the source behavior or aggregate traffic arrival process except those provided in the traffic descriptors.

– The admission control criteria is simply as follows

v, the total amount of existing reservations;r, the new flow’s rate;the admission threshold.

Parameter-based version

The simplest version of the rate sum is to obtain v from the token bucket parameters.

If n flows are admitted and the token fill rate of flow i is ri, the most conservative estimation of v is

r is the token fill rate of the new flow and is the bandwidth allocated to a class of traffic.

Rate–Based Approaches (cont’d)Parameter-based version (cont’d)

This scheme can guarantee that even if all the flows send at their sustained rate, the network will be able to deliver them at their reserved QoS. However, this hard guarantee is achieved at the expense of low utilization of the network when some flows are inactive or sending at a lower rate than the reserved rate.

A way to increase the utilization is to measure the actual network load and substitute v with the measured load .

However, when the actual load approaches , average packet delay approaches infinite.

Therefore, measurement-based schemes lower the threshold to (0< <1).

Increasing the utilization target will make the admission control scheme more aggressive.

Measurement-based version (cont’d)

Rate–Based Approaches (cont’d)

• Equivalent capacity approach

The equivalent capacity C( ) is an estimation of the arrival rate of a class of traffic such that the stationary arrival rate of the traffic exceeds C( ) with a probability of .

An admission control decision is made based on C( ), the peak rate of the new flow P, and the bandwidth allocated to the class C. More specifically, a new flow is admitted if

C ( ) P C.

Normal distribution based approach

This scheme assumes the aggregate arrival rate can be modeled by a normal distribution with mean and variance 2. C( ) is given by:


Normal distribution based approach (cont’d)

The mean and variance 2 of the aggregate arrival are either derived from the token bucket parameters of individual flows or estimated from measurements.

This model is suitable for estimating the equivalent capacity of a large number of similar flows.

However, it is more likely that the real-time traffic flows may exhibit very different behavior. For example, audio and video sources may have different levels of burstiness and peak rates. Therefore, this scheme sometimes underestimates the equivalent capacity when the assumptions are violated.


Hoeffding Bound Based ApproachHoeffding Bound Based Approach

A looser bound of the sum of N independent variables.

Since the Hoeffding Bound does not assume normal distribution of the aggregate traffic, this scheme is valid for small size classes and traffic from heterogeneous sources.

Given the peak rate of N sources {Pi} 1n , the equivalent capacity estimated by the Hoeffding Bound is:

The average arrival rate is estimated using some measurement technique;

The peak rate is either provided by the source or derived from the token bucket parameters;


Discussions on the two previously mentioned approachesDiscussions on the two previously mentioned approaches

It is observed that although CN is a tighter bound on the aggregate arrival rate than CH , it sometimes underestimates the exact equivalent capacity when the number of flows is small.

As the class size grows larger, both schemes benefit from a larger statistical multiplexing gain.

The estimation error plays an important role in the equivalent capacity approach. A larger means the admission control algorithm behaves more aggressively, i.e., the estimated equivalent capacity will be lower and more flows may be accepted even if all the other parameters remain the same. It is suggested that the best approach is to choose based on accumulated experience given our limited knowledge of the traffic characteristics.

Delay-based ApproachTo begin with the following definitions:To begin with the following definitions:

k

G

k

G

the link capacity;

r the new flow rate (for a flow with priority k);

the measured guaranteed service link usage;

b the new flow token bucket depth;

the reserved bandwidth of all guar

i

anteed flows;

the measured rate of priority class i.

Guaranteed servicePredictive service

The priority level, 1 (highest) N (lowest)

Delay-based Approach (cont’d)ADC for predictive class :ADC for predictive class :If an incoming flow requests service with a predictive class (priority) k, check the bandwidth and delay constraints as follows:

Delay-based Approach (cont’d)ADC for guaranteed service:ADC for guaranteed service:

If an incoming flow requests guaranteed service, check the bandwidth and delay constraints as follows:

Conclusions• Tuning an admission control scheme (its configurable parameters

or measurement method) to create more or less aggressive behavior.

• Increased utilization can be achieved at the cost of more QoS violations. However, this trade-off is usually appropriate for real-time traffic that can tolerate a certain level of loss and delay jitter.

• LRD can make MBAC criteria unknowingly more aggressive.

Download - Resource Reservation Protocol and Admission Control

Top Related