Thực hiện chất lượng dịch vụ trong các mạng IP (P5)

For the transport operator, on the other hand,one part of the optimization problem is allocation of services toproper service quality support classes.. Efficient resource usage includes

of existing boundary conditions for the new configuration.Resource allocation is an optimization problem where the avail-able network resources, SLAs for different parties, and require-ments of service types are examples of boundary conditions TheSLA interfaces relevant to resource allocation are illustrated with

an example configuration in Figure 5.1 The responsibility of to-end service quality can be thought to be by default with serviceproviders, who use SLAs towards network transport providers toimplement the service quality Alternatively, an access networkoperator may provide a set of services from outsourced Applica-tion Service Providers (ASPs), such that the access network oper-ator is responsible for end-to-end service quality

end-There may be more than one service provider involved, forexample, in using IP telephony services in such a way that the

Implementing Service Quality in IP Networks Vilho R¨ais¨anen

 2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X

SLA

SLA SLA

SLA SLA

Service subscriber

Service operator Transport operator

Service operator

Transport operator

Service

subscriber

Figure 5.1 SLA reference model for the present chapter

caller and callee use different IP telephony service providers Inthe general case, there may be also transit operators involved

As to services, both external service operator/transport operatorand operator-internal service/transport interfaces are illustrated

in Figure 5.1 In general, there is no need to have a one-to-onerelationship between service and transport operators

Available network resources are the most limiting factor whenservice mapping in multi-service access networks is considered.This is true not only when the network infrastructure alreadyexists, but also when a new network is being built In backbonenetworks, on the other hand, more conservative network dimen-sioning is typically possible due to higher flow aggregation levels.The generic traffic engineering process described in the last chap-ter can be used to optimize the use of the available resources inboth access and backbone networks, but the starting point for thisoptimization is the initial resource allocation When traffic engi-neering process can be applied, requirements for the accuracy ofthe initial configuration become smaller When the traffic volumestransported in the network domain are anticipated to grow withtime, dimensioning of a new network infrastructure usually takesinto account future growth in traffic volumes Also in this case,the initial configuration is not as critical as for a fully loadedmulti-service access network The goal should nevertheless be asprecise as possible a resource allocation, starting from the antici-pated shares of traffic types

SLAs for direct end user customers can provide flexibility forresource allocation, if SLAs include traffic types that can beused for this purpose The SLAs for different customer segmentsand services may be different with respect to degree of details

of service quality support provided As discussed in Chapter 2,for services with stringent quality support requirements such as

5.1 SCOPE OF THIS CHAPTER 135

multimedia conferencing, absolute guarantees may be necessary

On the other hand, for data type services, statistical guaranteesmay be sufficient A change of admission control policy to demandservice quality types is a tool that can be used to control theresource allocation in access networks when the service qualityinvocation procedures allow for this

Towards the service and network providers, the SLAs are cally more static The resource allocation optimization and applica-tion of the traffic engineering process may result in a need to mod-ify the SLAs, but this typically takes place at longer timescales thanone associated with resource management for the operator’s ownend user services Thus, it could be said that the traffic engineer-ing process should also yield an indication of its means becomingexhausted, being indicative of a need to modify SLAs or by othermeans restore the operational efficiency of traffic engineering

Chapter 2 described the intrinsic requirements of services andtheir characterization Chapters 3 and 4 described mechanisms forproviding service quality support in the network This chapterdeals with the link between service requirements and IP networkservice quality support The concepts in this chapter are used indiscussing service management in the next chapter Let us nextdefine the reference model for this chapter

For the purposes of the present chapter, the end-to-end delivery

path for service instances is assumed to consist of multiple

trans-port operators, each capable of providing suptrans-port for service quality

for a set of services, either statistically on the level of behaviouralaggregates or per flow (cf Figure 5.1) It is further assumed thateach transport operator is capable of providing multi-service sup-port Each transport operator is assumed to be using a per-domainservice quality support mechanisms independently of each other.The actual mechanisms can be circuit-switched guaranteed QoSfor telephony, over-dimensioning, or DiffServ, to name but a fewalternatives The resource allocation discussion in this chapter per-tains to a multi-service DiffServ domain specifically, and thus ismost directly related to access networks

Services are assumed to be managed by service operators by

having Service Level Agreements (SLAs) with end users, with

transport operators and between each other, as necessary Atransport operator may also be a service operator, in whichcase the service operator/transport operator interface is anoperator-internal one Referring back to the client/server andconnectivity/service paradigms used in Chapter 2, the model

of Figure 5.1 is of latter type, allowing for signalled operation of service providers for a single service instance Theclient/server application of Figure 5.1 could only involve singleservice subscriber, single service operator, and one or moretransport operators

inter-For the service provider, service quality provision is at bestrelated to the intrinsic quality requirements of individual serviceevent types Depending on the SLA type, the service provider mayalso need to understand service quality support mechanisms of thetransport operators For the transport operator, on the other hand,one part of the optimization problem is allocation of services toproper service quality support classes This is a part that the ser-vice provider may need to understand, unless the SLA betweenthe service provider and transport operator is sufficiently detailedfor the service operator not to need worry about technical details

of the service quality support details

A second aspect of the transport operator optimization relates

to using resources effectively to implement multi-service SLAs fordifferent parties involved Efficient resource usage includes select-ing an optimal set of supported service quality aggregates, andusing network resources to implement SLAs using the aggregates.Here, it is assumed that the service provider and the transportprovider are able to negotiate the behavioural aggregate used forservice quality support

In the discussion below, the SLAs for service providers are ceptually seen as boundary conditions for the resource allocation

con-of the transport operators’ own end user services, the basic processand target of resource allocation being the same for both types oftraffic aggregates For operators’ own services, there is no need totake into account an external negotiation interface towards differ-ent business party, which is why they are used for simplicity inthe discussion below

Next we shall review service quality support-related resourceallocation models from ETSI EP TIPHON, Third GenerationPartnership Project (3GPP), and QoS Forum Two further DiffServ-related examples are provided due to their relation to policing, one

5.2 ETSI EP TIPHON REFERENCE MODEL 137

of them being draft ITU-T model After that, the concept of based resource allocation is reviewed The TIPHON referencemodel is relevant to IP telephony, that of 3GPP to mobile services,while the QoS Forum and ITU-T models and utility-based resourceallocation reference models are generic in nature The conceptsfrom these models are used in formulating a generic frameworkfor resource allocation for multi-service IP network

The European Telecommunications Standardization (ETSI) is anorganization making international telecommunications standards.The best-known ETSI standards are probably GSM and UMTS.During the latter half of the 1990’s, ETSI founded the IP telephonyproject TIPHON, which has devised a reference models for IPtelephony, in which service providers can be separated from trans-port operators [TIPHON-3] The model pertains to IP telephonyspecifically, but is sufficiently generic to be used here While some-what abstract, it illustrates the logically necessary functions andinterfaces of a separated service/transport paradigm Particularlyvaluable for the present purposes, the ETSI TIPHON referencemodel also includes a QoS reference model

The reference model consists of separated service and transportlayers, and is illustrated in Figure 5.2 The two-tier model allowsfor telephony providers, using Session Initiation Protocol (SIP),for example, to operate without having to build own transportnetworks

When a VoIP call is set up between the communicating parties,the IP telephony service provider for the calling party sets upthe call by communicating with the service provider of the calledparty, as necessary The respective service operators at each endset up necessary transport resources As a result of the resource

set-up, the communicating hosts may be provided with a QoS

tokens to authorize the access to appropriate transport resources

[TIPHON-3]

TRM TRM TRM

Transport operator 1

Transport operator 2

Transport operator 3

Service provider 2 Service

provider 1

Figure 5.2 ETSI EP TIPHON reference model

Note: Solid lines denote the transport layer, dotted lines the service layer, and dashed lines the link between service and transport layers

The reference model has been targeted to be “agnostic” withrespect to QoS mechanism used on the transport layer, and shouldtherefore work with ATM, IP QoS mechanisms including Diff-serv and IntServ, and over-provisioning, for example End-to-end

QoS requirements of services are dealt with by using QoS budgets,

so that the end-to-end service quality requirements are known,broken down into per-service provider allocations and further totransport level allocations For example, the service provider 1 inFigure 5.2 is supposed to be able to calculate how much delay andpacket loss is allowable in transport operator 1’s domain Serviceprovider 1 would then communicate this requirement to TransportResource Manager (TRM) within transport operator 1’s domain tocheck whether the necessary service quality support can be imple-mented by the transport operator The per-domain allocation doesnot have to be statically allocated for a particular path, but canalso be dynamically negotiated The QoS resource allocation may

be iterative and affect call routing As has been seen in previouschapters, the properties of the terminals potentially affect end-to-end service quality In the TIPHON work, this has been taken intoaccount by classifying the terminals according to their impact toend-to-end service quality

There is no need to have one-to-one correspondence betweenservice and transport operators in TIPHON’s model In Figure 5.2,Service Provider 2 has service quality support signalling interface

to two transport operators along the end-to-end path In fact, thereneed not be QoS interface from a service operator to each transportoperator at all, but service quality support signalling can take placebetween transport operators The QoS reference model [TIPHON-3] also contains exemplary signalling charts for different inter-working scenarios One signalling mode shown therein performs

5.2 ETSI EP TIPHON REFERENCE MODEL 139

Table 5.1 Functional elements of the TIPHON QoS control model

QoS Service Manager

(QoSM)

Service layer Mediates requests for

end-to-end QoS based on policies stored in QoSPEs, communicating with other QoSMs and TRMs.

QoS Policy Element

Transport Policy Entity

(TPE)

Transport layer Functional entity maintaining

the policies of a transport domain.

Transport Function (TF) Transport layer Logical entity representing

the transport resources in the domain.

the end-to-end resource allocation set-up signalling entirely on thetransport layer, initiated by communication endpoints (terminals).All told, TIPHON’s QoS model includes the elements listed

in Table 5.1 QoS Service Managers handle the end-to-end service

quality including QoS budget negotiations and interfacing to thetransport layer, based on service layer policies Instantiation of ser-

vice quality on transport layer is controlled by Transport Resource

Manager, which can operate on aggregate level or flow level When

IntServ is used end-to-end, service quality signalling takes placebetween TRMs and terminals

In TIPHON’s QoS control model, the service and transport ers are logically separated from each other Due to this, they havesets of policies that operate on different conceptual levels The

lay-policies of the service domain relate to authorization of serviceinstantiations, whereas the policies of transport domain pertain toauthorization of flows to classes of resources.

The TIPHON QoS reference model lists three ways of allocatingQoS budgets across transport domains:

• Dynamic signalling of transport QoS parameters during callset-up

• Static SLAs between service domains

• Aggregation of transport domain resources and caching mation of QoS resource availability

infor-Per-call signalling is akin to per-flow RSVP reservations, and hassimilar kinds of scalability concerns associated with it Particularly

in IP telephony, the delay due to resource set-up is also important.Static SLAs between different parties is the simplest model Anelaboration of this allowing for more flexibility is the third model,

in which admission control is performed to available resourcesbetween operators

The TIPHON QoS model is illustrated in Figure 5.3, consisting

of QoS characterizations on the user layer, application layer, and

Codec, Frames per Packet, Frame Size, Jitter Buffer Delay,

FEC (Redundancy), Overall One-Way Delay,

TRANSPORT Packet Loss, Mean Delay, Delay Variation

Figure 5.3 QoS characterization of user, application, and transport levels

in the TIPHON reference model

Source: From [TIPHON-3]

5.2 ETSI EP TIPHON REFERENCE MODEL 141

transport layer QoS characterization on user layer consists of theTIPHON voice QoS class, having five possible values: wideband,narrowband high, narrowband medium, narrowband acceptable,and best effort Subscribers can choose between these classes based

on associated pricing and quality attributes The voice QoS classcan also be a part of the subscription profile

Mapping of user layer QoS characterization to application layercharacterization is performed by interpreting the voice QoS class

in technical terms The actual parameters involved depend on theoutcome of end-to-end codec negotiation In SIP, this is performedusing the Session Description Protocol (SDP) during call set-up.For example, the negotiated parameters could include the codec

to be used (for example, AMR, GSM FR, G.723.1, G.711) and thebit rate for the codec (ranging from 4.75 to 12 kbit/s for AMR).QoS characterization on the transport layer, that is, the servicequality support that a transport operator needs to be able to pro-vide, are derived from two sources:

1 Application quality characterization

2 End-to-end QoS budget

The two are not independent, as the end-to-end QoS budget may

be used in negotiating the application parameters (codec) Thechoice of codec and audio sample size affect the end-to-end delay.The relation between end-to-end delay and end user experienceused by TIPHON is shown in Figure 5.8 in Section 5.7.4

In ETSI TIPHON IP telephony reference model, the end-to-endnegotiation is performed under control of service layer operators,and involves one or more transport operators The service operatorperforms the mapping from service quality to transport resourcerequirements The TIPHON QoS model consists of a subscription,codec, and transport levels, addressing the different abstractionlevels that can be used in telephony The transport operator uses alogical transport resource management element to perform admis-sion control to available resources

The weakness of the original TIPHON QoS model is the amount

of per-flow signalling associated in admission control of a new

flow: at least one of the service operators was supposed to signal

to one or more transport operators to ensure appropriate servicequality support for the flow When more than one service provider

is involved in the end-to-end set-up, handling all scenarios arisingfrom each operator using service quality support signalling withthe transport operator or operators, call set-up delay can quicklybecome prohibitively large in such cases The concept of perform-ing admission control to traffic aggregates was incorporated intothe TIPHON model as a further mode, having better scalabilityproperties We shall return to the topic of admission control toaggregates in Chapter 8

Internet2 project is a partnership to develop inter-domain vice quality support for the Internet, led by US universities andparticipated in by a number of corporations and other organi-zations [THD+ 99] Distance learning, remote instrument accessand control, advanced scientific visualization and networked col-laboration are listed as potential uses for service quality support

ser-in the future Internet Internet2 addresses the followser-ing areas:applications, middleware, advanced networks, engineering, andpartnerships QBone is the QoS testbed of Internet2 to addressthe needs such as those listed above, and has been attended to

by a number of network service providers To quote the Internet2website (http://www.internet2.org):

The goal of the QBone is to provide an inter-domain test bedfor differentiated services (DiffServ), where the engineering,behaviour, and policy consequences of new IP services can

Inter-domain interworking for DiffServ in QBone paradigm can

be implemented by SLAs and Service Level Specifications (SLSs),

5.3 QBONE 143

the latter being the technical part of the SLAs The inter-relation

of SLAs and SLSs will be discussed in more depth in the nextchapter, and for present purposes it is sufficient to know that sinceSLAs/SLSs exist at the boundaries of the domains, they can attheir simplest be based on bilateral agreements between networkoperators The QBone architecture aims to provide added value

to end-to-end DiffServ+ SLA/SLS architecture with enhancedsupport for dynamic inter-domain operations The goal is tospecify a common set of operational practices and procedures

to be followed by network operators Bandwidth Brokers (BBs)are viewed as tools for making automated admission controldecisions, network device configurations, and dynamic inter-domain SLAs Bandwidth brokers will be discussed further inChapter 8

For present purposes it is sufficient to know that static SLAscan be viewed as a special case of dynamic bandwidth brokerparadigm, and that neither SLA negotiation between domainsnor admission control towards end system necessarily have to beautomatic Thus, the bandwidth broker – at most general – is aconceptual device in discussing resource management

A further requirement is an integrated measurement ture with hooks provided for supporting end-to-end debuggingand auditing by users, network operators, and implementers.Both active and passive measurement data may be collected forthis purpose and preferably shared openly among participants

Within the QBone, each participating network is a DiffServDomain that inter-operates with other QBone networks to providethe end-to-end QBone services Two separate “service models”have been devised, the first of which must be supported by allQBone domains Within the terminology of the present book, thetwo models would be better termed service support models

1 QBone Premium Service (QPS): QPS is a low-delay, low-jitter, and

low-loss service based on the DiffServ EF model Token bucketprofiler on the network edge configured with token bucketparameters including peak rate, and bucket depth of MTUbytes The following definition is from the Internet2 website:

QPS is based on reservations for token bucket parameters inDiffServ network A QPS reservation makes a simplex, peak-limited bandwidth assurance The extent of a QPS reserva-tion may be entirely within a QBone domain, from one edge

of a QBone domain to another edge of the same domain, orthrough multiple QBone domains and is defined by a servicesource and service destination, each of which is, in general,defined by a network prefix

A QBone reservation consists of the following data [THD+ 99]:source, destination, route, starting time, ending time, peak rate,MTU, and jitter Requirements for QBone SLS are listed, includ-ing SLS components such as the Traffic Conditioning Specifica-tion (TCS)

2 Alternative Best Effort (ABE): ABE provides a low bounded

queu-eing delay service in the Internet, while still bqueu-eing best-effort,and requiring no additional charging or usage control To quotethe Internet2 website,

[G]oal [of ABE] is to help applications with stringent realtime constraints, such as interactive audio With ABE, it is notrequired to police how much traffic uses the low delay capa-bility, the service being designed to operate equally well inall traffic scenarios Applications choose between receiving alower end-to-end delay and receiving more overall through-put Every best effort packet is tagged as either “green” or

“blue” “Green” packets receive a low, bounded queueing lay To ensure [that] “blue” packets do not suffer as a result,

de-“green” flows receive less throughput [than blue flows] ing bouts of congestion

dur-Green versus blue marking differentiates between traffictypes, which are affected by per-packet latency values andthose, affected only by the overall throughput Examples

of applications using the green and blue markings are IPtelephony and web browsing, respectively The two servicetypes of ABE do not map directly to standardized AF or EFPer-Hop Behaviours

The QBone reference model is an end-to-end model for transportnetwork service quality support means for single-domain as well

5.4 3GPP QOS MODEL 145

as multi-domain case The model addresses network service ity support modes and mechanisms, and service mapping is notaddressed, apart from the service quality support models pro-vided Two such service models are provided: obligatory QPS,and tentative ABE

qual-QPS provides low-delay, low-jitter, and low-loss service qualitysupport QPS requires policing, and is based on one-way reser-vations of capacity using the token bucket paradigm within one

or more domains QPS can be implemented with the EF PHB

of DiffServ

ABE provides the possibility of trading overall throughput forlow delay service ABE does not require policing at the networkedge ABE does not map directly to standard DiffServ PHBs

In its simplest form, the end-to-end QBone model can be mented with DiffServ within each domain with bilateral SLA/SLSagreements between operators QBone is studying bandwidth bro-kers as a tool for admission control to network resources, as well

imple-as for dynamic inter-domain SLAs

General Packet Radio Service (GPRS) was designed to make cessing of packet-oriented services better integrated with the cel-lular network than is the case in circuit data of GSM The firstGPRS standard version (release 97) supports circuit-switched (CS)telephony, CS data as well as packet-switched (PS) data traffic.The communication between a GPRS terminal and another IP-addressable device (another mobile terminal or an Internet server,for example) takes place using a Packet Data Protocol (PDP) con-text, having QoS parameters associated with it From the point

ac-of view ac-of end user IP communication, GPRS Gateway SupportNode (GGSN) at the edge is the access router used by the mobileterminal, and PDP context hides most mobility-related functionsfrom endpoints of end user IP communication

The GPRS R 97 QoS profile defines the following requirementsfor the service: delay, service precedence, reliability, meanthroughput, and peak throughput [KP01] Of these parameters,delay means end-to-end delay, service precedence means roughlydrop precedence, and reliability defines which degree of loss theservice can tolerate The QoS parameters are used in the GPRS

radio interface to select a the radio priority, and in the GPRS corenetwork to select adequate core network QoS parameters.

The Universal Mobile Telephone System (UMTS) specification ofETSI’s Third Generation Partnership Program (3GPP) is an exten-sion of the GPRS paradigm to support Wideband Code DivisionMultiple Access (WCDMA) radio interface, including a more ad-vanced QoS model The 3GPP QoS model provides support forservice quality differentiation for generic real-time and interactiveservices, in addition to voice and data This is accomplished by

defining UMTS bearers for radio access and core network, which

support not only the specification of priority and bandwidth type

of parameters, but provide for a richer set of service quality port requirement specifications PDP context is the unifying linkfor QoS across different bearers In the terminal, a sufficient Appli-cation Program Interface (API) between applications and the oper-ating system is assumed to exist to request service quality support

sup-A simplified overview of protocol stacks of 3GPP architecture isshown in Figure 5.4 Note that radio access bearer and IP bearerprovide service quality support for user layer traffic (end user

IP flows) “from below”, whereas service quality interworking wards external Internet takes logically place on user layer

The interested reader can find a longer account of 3GPP QoSmodel in [KP01], only a short description being given here Net-work architecture for UMTS is shown in Figure 5.4 As with GPRS,

each user flow is mapped in to a PDP context One of the ties of the PDP context is traffic class, being one of the following

proper-four types:

Radio tunnelling

RAB Link

GTP ATM Link

GTP ATM Link

GTP IP Link Terminal

Base transceiver station

& radio network controller

Serving GPRS support node

Gateway GPRS support node

Link GTP

IP Link User IP layer User IP layer

Figure 5.4 Release 99 UMTS architecture protocol stacks

Note: The protocol architecture has been simplified

5.4 3GPP QOS MODEL 147

1 Conversational class This service class has been designed forinteractive real-time communications such as voice or multime-dia telephony, which has strict limits for end-to-end delay

2 Streaming class This service class is suitable for non-urgentreal-time services that can tolerate longer delay than conversa-tional class applications

3 Interactive class is suitable for interactive data-type servicessuch as browsing the Internet Interactive class traffic is typ-ically prioritized with respect to background class

4 Background class

In addition to the traffic class, the QoS profile associated with aPDP context includes the parameters listed below in Table 5.2 Notall of them are applicable to all traffic classes

The QoS profile parameters of the PDP context are used in ping to bearers The Radio Bearer (RB) is used in the radio inter-face, and the bearer between mobile and SGSN is called upwards iscalled Radio Access Bearer (RAB) In the transport network, userlayer traffic is transported by GPRS Tunnelling Protocol (GTP)tunnelling using either ATM or IP transport The correspondingbearer is called core network (CN) bearer Protocol stacks relating

map-to different bearers are illustrated in Figure 5.4 While the promap-to-col stacks in the radio access and transport networks seem a bitcomplicated, they provide the end user flows with the abstrac-tion layer of bearer to implement the PDP context service qualityrequirements and hide mobility from communication endpoints

proto-Table 5.2 QoS profile meters in 3GPP framework Maximum bit rate

para-Guaranteed bit rate Maximum service data unit SDU size

SDU format information SDU error ratio

Residual bit error ratio Delivery of erroneous SDU Delivery order

Transfer delay Traffic handling priority Admission/retention Priority

The QoS requirements of the PDP context are signalled end inside the mobile network and mapped to appropriate bearerparameters The desired QoS properties are then implementedusing appropriate bearer mechanisms in radio and mobile net-work domains The full 3GPP QoS architecture involves multiplelevels of bearers which are omitted here.

end-to-For Interactive class, Traffic Handing Priority (THP) providesfiner granularity, having three possible values The significance

of this parameter is as follows: as measured end-to-end, an active traffic class flow with THP1 receives, on average, lowerend-to-end delay than interactive traffic class flow with THP2 Asimilar relation exists between THP2 and THP3 Traffic handlingpriorities can be thought of as roughly corresponding to delayclasses in the GPRS QoS model

The 3GPP architecture is designed to support telephonyand packet-based services for wide-area cellular access Thearchitecture uses IP transport in packet core between mobilityservers, and service quality interworking on the Internet can beimplemented by SLA-type mapping from CN bearer to externalmechanism at the edge of the mobile network

The 3GPP QoS model encompasses four traffic classes, providingquality support for basic service categories, including telephony,streaming, browsing, and background data transfer

An extension of basic 3GPP architecture is reviewed brieflyabove, Chapter 9 will use IP-based RAN as a case study to applythe conceptual framework developed in this book

The authors of [MNV02] consider a DiffServ-based architecturewith the following service quality support classes: premiumconstant bit rate, premium variable bit rate, premium multimedia,premium mission critical, and best effort The first two for theservice quality support classes are meant for UDP, and the nexttwo for TCP The service quality support classes have beendesigned with interoperability of 3GPP traffic classes in mind,

5.6 UTILITY-BASED ALLOCATION OF RESOURCES 149

and the authors present an example mapping between the twoservice quality support models According to the authors, theservice model can be implemented with a combination of priorityqueueing (PQ) and WFQ, with tail-drop, RED and WRED aspossible mechanisms for buffer management Token bucket is usedfor peak rate policing in premium constant bit rate model, and inpremium variable bit rate model, two token buckets are used forpolicing both sustainable and peak rate For TCP traffic, policing

is done with a single token bucket with “downgraded” DSCPmarking for out-of-profile traffic

In ITU-T’s draft specification [Y.1221], three service quality

sup-port models called IP transfer capabilities are defined.

• Dedicated bandwidth transfer capability (DBW) is suitable for

services with stringent delay requirements Parameters to becontrolled are peak rate, token bucket size, and maximumallowed packet size Out-of-profile packets may be discarded

• Statistical bandwidth transfer capability (SBW) is intended for

applications with no stringent delay requirements Controlparameters are peak rate, peak rate bucket size, sustainable rate,sustainable rate bucket size, and maximum allowed packet size.Traffic above sustainable bit rate but within peak bucket trafficwill be delivered

• Best Effort transfer capability (BE): no guarantees provided.

In [Y.1221], congestion and overloading control are performedwith packet discarding control as well as potentially using ExplicitCongestion Notification (ECN)

The previously reviewed schemes for provisioning of servicequality support with network resources have stemmed mainlyfrom a service quality requirement viewpoint, without directlytaking into account the operator’s business objectives Next, weshall discuss the concept of resource allocation performed based

on utility, where such objectives can be expressed by interpreting

utility as revenue

For the purposes of this topic, let us assume a networktransport/service provider with a selection of supported servicesprovided for customers, as well as SLAs for other operators This

scenario is suitable for illustrating the benefit of utility-basedallocation The subject matter of this chapter, however, is alsouseful for pure network transport operators, especially whendynamic SLA mechanisms are used Dynamic SLAs will bediscussed further in Chapter 8.

A generic formulation of utility-based allocation of resources

is as follows: maximize utility of service resource allocation ject to service quality requirements and total amount of resourcesavailable in the network (see, for example, [PB01]) The variables

sub-to adjust are the set of supported service types,{S i}, and the cated resources for each service type, {R i} An oft-used examplefor evaluating utilities of individual services is the utility curve,assumed to be available for each service type The utility curve

allo-is often shown for bandwidth, whereby the curves for CBR VoIPand WWW browsing – for example – could look like the example

in Figure 5.5 Utility for CBR VoIP deteriorates quickly below acritical bandwidth limit, whereas the utility for browsing in the-ory is a smoother function of the available bandwidth From thecurve, one can immediately see that it is no use to provide a band-width below the “step” threshold for a VoIP stream The utility of

a browsing session, on the other hand, behaves more smoothly as

a function of the bandwidth

The utility for a particular service type of Figure 5.5 is a function

of bandwidth, i.e.:

1 / Bandwidth Utility

Figure 5.5 Utility curves for VoIP (dotted line) and WWW browsing (dashed line)

5.6 UTILITY-BASED ALLOCATION OF RESOURCES 151

where b is an estimator for bandwidth available to the service

instance A classical reference using utility functions of this typefor managing bandwidth allocation for elastic traffic is [Kel97] Inthis kind of scheme, the goal is to maximize the aggregate utilitycomputed over all streams given that utility functions of usersare known

From the discussion in Chapter 2, it is evident that availablebandwidth is not sufficient for analyzing multi-service case butthe utility in general should be a function of availability, delay,delay variation and packet loss, too, to mention but a few char-acteristics A step in this direction, use of delay utility in control-ling scheduling has been addressed in [SB02] Taking into accountthe characteristics that can be evaluated per network element, anamended utility function for a service class could read:

where d ,
d , and l denote estimators for delay, delay variation,

and packet loss rate, respectively Compared to using only width in utility computation, adding more variables makes theutility optimization much more complex

band-The utility of service types obviously needs to be evaluated

in order to be maximized The utility function of a service canthen be defined in a contract between the customer and thenetwork/service operator Utility may be defined according tocustomer class, for example, differentiating business users andeconomy users for services In such a case, the utility functionfor a particular service type could have the same generic form,but the utility function of a business user could be scaled with

a factor larger than unity with respect to the utility function ofthe economy user, for example Thus, the overall utility could besummarized in the form of a matrix, a generic imaginary example

of which is shown in Table 5.3

Table 5.3 An example utility table for services Each entry represents a utility function

The network resource allocation problem can then be expressedmathematically as the following kind of optimization problem:

a service type in a multi-service network can be a function of age available bandwidth, variation in available bandwidth, delay,delay variation, and packet loss With utility functions, resourceallocation is turned into an optimization problem, with the set ofsupported services and resources allocated to them as variables.This scheme requires that the utility of the services be known.Translation of the services into monetary – or some other type

aver-of – utility can be done, but users may have implicit order” utility functions related to continuity of services, and ofavailable service selection Thus, simple-minded application ofutility-based resource allocation methods may be dangerous In anenvironment based on SLAs, utility is a useful concept in assess-ing the value of different sets of SLA configurations, and thus can

“second-be viewed as an advanced “meta-level tool” in enhancing revenuefrom a network on a long term

Let us next collect the knowledge from previous resource tion models in the form of a generic model to perform the resource

alloca-5.7 GENERIC RESOURCE ALLOCATION FRAMEWORK 153

allocation in a single multi-service IP network domain as a part

of end-to-end service quality support chain All told, this cise includes signalling, mapping of traffic onto network resources,evaluating and configuring service quality performance inside adomain, and computing end-to-end service quality budgets.Useful concepts from previously reviewed service quality sup-port architectures include the following:

exer-• Separation of service and transport layers This is an enabling

con-cept for access technology independent of service usage In thelong run, it can also be expected to be in the interests of the enduser and service provider, as discussed in Chapter 1

• Interface for mapping of services to service quality support classes.

This kind of interface is a must in non-over-dimensioned service network

multi-• End-to-end service quality model, translatable into per-domain

allo-cations Having an to-end model allows structuring of

end-to-end service performance

• Admission control to traffic aggregates On the network service

quality support side, aggregated treatment of service qualityrequests improves scalability

• Policing of traffic at network ingress Policing makes service

qual-ity support in the network easier Further, as seen earlier inthis chapter, policing can be coupled with service quality sup-port models

• Service quality support models for structuring service quality

map-ping.

• Static or dynamic inter-domain SLAs SLAs help to structure the

responsibilities of operators and providers, as will be seen inthe next chapter

• Utility-based evaluation of resource allocation This is a promising

concept

• Pricing of service quality support categories This is a practical tool

for controlling the number of service instances making use ofeach category

Next, a resource allocation framework is presented, based on acombination of these concepts

5.7.1 Signalling

For per-flow, terminal-controlled service quality, a signallingscheme is needed for the transport network for requesting servicequality support in the network This signalling can be performed

by a communication endpoint, by a service provider, or both Twodifferent schemes are possible here:

1 A full set of service quality support parameters is requested

2 A small number of service quality support classes is used tween the end user and the network

be-With IP-based applications, the first option requires that the socketinterface for the application supports request of the appropriateparameters Obviously, it also requires that the application knowswhich parameter values to request and – if service quality renego-tiation is implemented – which parameter values are acceptable.The link between application in the endpoint and the operatingsystem can be implemented using an API with service qualitydescriptors, or with predefined service quality support classes as

in the TIPHON model Additionally, the TCP/IP implementation

of the operating system of the end user IP host must support theservice quality support signalling between the IP host and the net-work The signalling scheme can be, for example, RSVP, SIP/SDPparameters for IP telephony, UMTS terrestrial RAN (UTRAN) sig-nalling in 3rd generation mobile networks, or some future sig-nalling protocol (see Figure 5.6) As mentioned in the previous

Application API

O/S

Application

Service signalling interface

Network signalling

operator

Network signalling interface

5.7 GENERIC RESOURCE ALLOCATION FRAMEWORK 155

chapter, also the use of COPS has been proposed for this interface.The choice of signalling protocol partially depends on whether theaccess network domain understands application-level signalling

A VoIP access domain may understand SDP parameters, but neric DiffServ domain not

ge-The alternative of having only a small number of service ity support classes is conceptually simpler, as not all applica-tions need to understand the full set of parameters This approachrequires that a small number classes are predefined for servicesupport, and that mapping to service quality support parameterscan be performed in the operating system, in service quality mid-dleware, or by service provider or network transport operator TheTIPHON user voice quality class is an example of such predefinedservice support classes for telephony, and the traffic classes withinthe 3GPP QoS model for a multi-service case

qual-It is not necessary that all the details of service quality supportmechanism parameters are visible to the end user, but the exactmeaning of the service class could be defined in an “end user SLA”between the network or service operator and the user, depending

on the price paid by the customer An example with two types ofend user SLAs could be as follows:

“Economy SLA”:

• Voice over IP with low delay, delay variation, and packet lossrate, using predefined codec with associated pricing scheme andtoken bucket parameters

• All the rest is best effort data with flat rate up to a predefinedcumulative traffic volume per month

“Super SLA”:

• Voice over IP or video telephony with low delay, delay tion, and packet loss rate; different codecs possible with associ-ated pricing scheme and token bucket parameters

varia-• Streaming support with predefined pricing scheme and tokenbucket parameters

• Browsing support with flat rate up to a predefined cumulativetraffic volume per month Token bucket parameters are definedfor browsing