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

The Internet today is based on the Best Effort BE service digm in which all IP traffic on a network link is treated alike,para-or in other wpara-ords, no service quality supppara-ort is

The Internet today is based on the Best Effort (BE) service digm in which all IP traffic on a network link is treated alike,

para-or in other wpara-ords, no service quality supppara-ort is provided whenmomentary traffic volume exceeds link capacity Subsequently, tooffer true multi-service support for critical traffic types such asVoIP in an IP-based network, the technical tasks to be carried out

by an IP service provider seem challenging at first sight Not onlymust mechanisms be provided for implementing the network sup-port for different service types, but also mechanisms are needed tomap service requirements onto network resources To make bestuse of network resources, the service mapping scheme may need

to be revisited when resources or distribution of services change.The whole service quality support system should be manageable

in a scalable way

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

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

It turns out that implementation of multi-service quality support

in an IP domain is possible and manageable Moreover, this port can be provided with a mechanism allowing the networkelement in the core of the network to be kept simple

sup-Despite technical feasibility, multi-service support in IP network

is not likely to be immediately adopted by all ISPs and other work operators However, the ability to provide better-than-besteffort service will become an important business proposition due

net-to the progress of content digitalization net-to include also non-datatype services In implementating such support cost-efficiently, IP-based service quality support mechanisms are a viable alternative,

as we shall see In what follows, we shall discuss the basic service quality support mechanisms and ways of implementingthem with present-day technology in a cost-efficient way Further,service level description mechanisms needed at the boundaries

multi-of operators’ domains are accounted for in this and subsequentchapters

In this chapter, we shall first briefly review issues relevant tonetwork multi-service quality support, and discuss policing at theedge of the network and the effect of different protocol layers

to service quality Next, the generic ways of supporting servicequality are reviewed, followed by a summary of service qualitysupport means in ATM and IP Routing control in IP networksand link layer service quality issues are discussed next, and thepresent chapter concludes with a summary

This chapter attempts to demonstrate that the building blocksfor service quality support mostly exists already today withoutATM ATM-based service quality support is used as a point ofreference in this chapter Management of IP-based service qualitywill be discussed further in the next chapter, and the provision ofnetwork resources in Chapter 5 Routing control beyond the basicoperation of IP routing protocols will be discussed in this chapter,and further in next chapter

The adoption of dedicated multi-service quality support nisms in the network is only necessary when the following twoconditions are met:

mecha-1 Over-dimensioning of the network is not a feasible solution.

2 Providing of engineered service quality level for some servicetraffic types transported in the multi-service network such aslow delay and/or packet loss rate is desirable

Above, over-dimensioning means designing the network in such

a way that the network is at all times capable of transmittingthe momentary traffic volumes so that the service quality require-ments of transported streams are satisfied The latter conditionamounts to delay requirement of all traffic being determined bythe most delay-critical and loss-intolerant service type

An application example is in a corporate access network ing Voice over IP, sharing the access network capacity with burstyHTTP traffic and Simple Mail Transfer Protocol (SMTP) traffic Itmay not be economically feasible to dimension the network tohandle the largest possible bandwidth bursts This would neces-sitate providing the same delay to transport of HTTP and SMTPthan VoIP

carry-If over-provisioning is not a feasible alternative, either a rate capacity is provided for VoIP, or a prioritization mechanismneeds to be built into the actual network transport to providedifferentiated handling for distinct service quality classes Thesemain alternatives benefit from further support mechanisms, themost important of which are discussed below Before that, how-ever, let us note that service quality support may be needed evenwith a single service quality type An example of this could beproviding pre-defined performance for browsing traffic In such

sepa-a csepa-ase, sepa-a suitsepa-able subset of the service qusepa-ality support msepa-achineryreviewed below could be used

Let us now discuss service quality support on a more generallevel Discussing the bandwidth of a single link for concreteness,there are basically two alternatives to over-dimensioning in pro-viding service quality support in the presence of multiple servicetypes: capacity reservation and differentiated treatment Capac-ity reservation means that a part of the total capacity of a link isreserved solely for one or more traffic types The remaining capac-ity can be used for implementing other reservations, or be shared

by services on a best effort basis Differentiated treatment, on theother hand, means not reserving any fixed capacity, but priori-tizing service types with respect to each other when momentary

Figure 3.1 The benefits of prioritization

Note: Unit in the vertical axis is the maximum required capacity of urgent traffic

offered traffic exceeds link capacity In the prioritization approach,less traffic can be displaced in time to make room for momentaryvariations in the volume of more urgent traffic

Let us next compare the over-dimensioning approach againstcapacity reservation and differentiated treatment using a casestudy Figure 3.1 below shows a case in which the average volume

of non-urgent traffic is fivefold as compared to the volume ofurgent traffic Over-dimensioning according to the peak value

would require capacity C of 6 units Capacity reservation for

urgent traffic would mean putting aside 1 unit of capacity, anddimensioning separate capacity according to the average volume

of non-urgent traffic, leading to total capacity requirement C of 1+

2.5 = 3.5 units Finally, implementing prioritization mechanism in

the network leads to dimensioning being based on the averagevolume of all traffic, i.e., approximately capacity of 3 units Inthis case, differentiation based on urgency brings capacity-savingbenefits of 50% compared to over-dimensioning, and more than14% based on capacity reservation for non-urgent traffic Thisrequires that non-urgent traffic can be delayed

The above simple calculation was based on a “fluid flow”approximation, not taking into account discreteness of data Anexact analysis of the process requires application of queueingtheory, potentially yielding corrections to the simple case whenthe size of largest packets is not insignificant with respect to totallink capacity The fact that packet length can vary gives rise tovariation in the service time of a packet, causing variable amount

of delay to the subsequent packets

A further advantage of multiplexing is that the relative iness of a traffic aggregates is considered to decrease with the num-ber of flows, reducing the effects due to fractal traffic phenomena,for example [CCL+ 02] As will be discussed in Section 3.2, engi-neering of network for bursty flows benefits from edge mecha-nisms.

burst-In general, the saving calculation figures will depend on thepercentage of traffic types, which need priority treatment If all

of the traffic needs priority treatment and is delay-sensitive, dimensioning is the only alternative As mentioned above, appli-cation of some service quality control means may be beneficial also

over-in this case from the poover-int of view of end user experienced ity At the other end of the spectrum, when priority traffic withvariable bandwidth is sharing the link with bursty non-urgenttraffic and the maximum volume of priority traffic is less thanhalf of the link capacity, savings can be considerable In what fol-lows, it is assumed that when service quality support is feasible,purely prioritization-based service quality support scheme is used

qual-to maximize utilization of installed capacity The dimensioning

of capacity reservations is a well-established discipline, and moreinformation about that can be found in [McD00], for example.The above analysis calls our attention to the following importantissues in considering the usefulness of differentiated treatment inthe network:

• Are savings from implementation of differentiated treatment high enough? Implementing support for differentiated treatment in

the network makes the elements more complex and posesrequirements for management system

• Can differences in service delivery time requirements be leveraged

to implement differentiation? If the delay requirements of traffic

aggregates are too close to each other, delay differentiation maynot be practical

• Are relative volume shares of services known? Traffic volumes need

to be known or limits need to be imposed to maintain per-nodedifferentiation It should be noted that relative volumes need to

be computable in all routers which implement prioritization

• Are absolute volumes of traffic aggregates predictable? Even with

differentiation, range of variation of different traffic types needs

to be known

Mathematically, feasibility of prioritization-based multiplexing in

a multi-service network is determined by whether service ment specification for a service allows for service instantiations ofthat type to be displaced in time, or their total throughput limited.Some analysis techniques for this will be discussed in Chapter 5

require-What has been discussed above are de facto preconditions for

using differentiation More generally, the reasons for choosingprioritization-based mechanisms over other alternatives may not

be related solely to the mathematics of dimensioning The service multiplexing paradigm based on service differentiation inthe network has the following benefits according to Kilkki [Kil99]:

it to say here by way of an example that fairness can be thought

to relate to the end user’s perception of the value for the pricethe user has paid for the service, taking into account other users’investments into same service Robustness refers to the sensitivity

of service quality support mechanism towards actions of olent users, and versatility relates to the selection of tools at thenetwork provider’s disposal in providing service quality supportfor a multiplicity of needs Cost efficiency is a measure of therequired monetary investment for implementing the service qual-ity goals A related topic, we shall discuss utility-based serviceallocation in Chapter 5

To put the service quality management methods presented later

in a general context, the reference model shown in Figure 3.2 isused for this chapter On the network side, a service instantiation

can be thought of as being conceptually associated with a vice quality support instance The service quality support instance

ser-defines the quality support provided to the service instance by thenetwork domain

NE NE

NE

NE NE

Service instance Quality requirements:

- xxx

- yyy

NE

Figure 3.2 Reference model for this section

Note: A service instance is invoked between two hosts, routed through a number of network elements (NE) and having a set of quality requirements

Time

NBR PBR

Figure 3.3 An illustration of NBR and PBR

Further, it is assumed that a NBR and a Peak Bit Rate (PBR) can

be defined for service events, for example by using TSpec-typetraffic descriptor The significance of these characteristics is that aservice instance needs capacity of NBR to function properly, andmay at times benefit from a capacity of PBR (see Figure 3.3) Fur-ther, a Maximum Burst Size (MBS) is assumed to be known, spec-ifying the maximum allowed amount of data in a burst A bursthere means a period during which the momentary bit rate exceedsMBR In ATM, Sustainable Cell Rate (SCR) roughly corresponds toNBR and Peak Cell Rate (PCR) to PBR The flow descriptor param-eters are assumed to be specified as a part of a SLA between theclient and the network operator, more or less explicitly

For networks with appropriate function in place, the mance of service instance to a traffic descriptor – for example, the

confor-triplet (NBR, PBR, MBS) – can be verified and imposed by policing

the service flows at network ingress point Performing policing at

ingress is beneficial, as accumulation of burstiness in the network

is best prevented by applying the “traffic contract” between ator and end user as soon as possible The traffic contract can

oper-be considered to oper-be a form of a SLA If ignored, accumulation

of burstiness would make service quality support management innetwork core difficult Performing policing at the network edgeinstead of network core elements is useful due to traffic volumesbeing smaller at the network edge than in network core and sub-sequently less processing is needed Depending on service types,traffic conditioning can be of help in all service quality supportmechanism scenarios described above Specifically, applying traf-fic conditioning to non-urgent traffic in the scenario of Figure 3.1reduces the need for maximum bandwidth in over-provisioningscenario This is also true when there is only non-urgent traffic inthe network Also in a differentiation-based scenario, traffic condi-tioning is useful through a smoothing effect in the core network.The SLA, in general, can be defined per service event type, or byhaving parts addressing different service event types The applica-ble service type is assumed to be detected either based on signalledstate, or on protocol data such as IP address and/or port number.When signalled instalment of policing is used, for example, RSVPcan be used for that purpose Protocol data filter can be a fixed one,

or vary with operator-defined conditions A single service instanceconsisting of service events of different types may map to multi-ple SLA service type components For example, a teleconferencingservice instance could include VoIP service event type with strin-gent service quality, and a data application sharing service eventtype with different SLA service quality profile

A practical device for verifying conformance to SLA is typicallyeither leaky bucket or token bucket regulator controlling regulatorfunction The conformance check can be assumed to be of leakybucket type for ATM and token bucket for IP traffic After confor-mance of a flow or aggregate to traffic descriptor has been checked,

a controlling means is usually applied for limiting out-of-profileburstiness of traffic at network ingress In ATM parlance, policing

is typically an operation applied in the User-Network Interface(UNI), or upon user flows entering the network It is also possi-ble that the user performs policing prior to sending traffic to thenetwork In addition to being better able to control the quality ofone’s own services, policing one’s own outgoing traffic allows theuser to better understand the properties of one’s own traffic

In general, the following actions can be applied to out-of-profiletraffic:

• Traffic shaping Burstiness is smoothened out by buffering

out-of-profile traffic Due to finite buffer size or maximum allowabledelay per network element, traffic shaping may need to be com-bined with the following method

• Discard out-of-profile traffic.

• Assign out-of-profile traffic to a lower treatment class This method

allows the out-of-profile traffic to utilize unused capacity in thenetwork

• Do nothing Statistics of out-of-profile traffic volumes may still

be recorded

Means of configuring policing will be discussed in the next ter The importance of conditioning will be referred to later in thecontext of end-to-end service quality dimensioning in Chapter 5.Here, suffice it to say that conditioning at the network edge alle-viates the possibility of worst-case effects of slow convergence toGaussian (well-behaved) aggregates with the number of flows inthe network core [NZA99] Such problems may arise due to bursty

chap-end-user traffic flows, technically described as being fractal or ing long-range correlations A classic example of this is fractality in

hav-Ethernet-based LAN [LTW+ 94] With increasing flow aggregationlevel, the arrival process on a link tends towards Poisson process,and the adverse effects of burstiness are reduced [CCL+ 02]

The ISO/OSI reference model enumerates no less than seven ers of interconnectivity The lowest three or four of these layers areoften referred to in practical engineering A well-known genericproperty of layered reference models, fitting of real-world pro-tocols neatly exactly within one OSI protocol layer is often prob-lematic TCP and UDP can be accommodated relatively nicely intoTransport Layer (layer four) of OSI model, but ATM and MPLS areboth partly layer 2 and partly layer 3 This is because they includerouting functions like layer 3 protocols, but are still “link layer”protocols from the viewpoint of IP applications For the purposes

lay-of concreteness, the four lowest layers lay-of OSI reference models are

UDP TCP

The protocols used in the layered structure can be of importance

to service quality support in IP networks, depending on what kind

of service quality support there is on each layer The significance ofTCP and UDP for service quality has been discussed in the previ-ous chapter, being an issue the endpoint application can partiallyaffect by choosing either TCP or UDP when instantiating a service

On the network side, the overall service quality support ity is affected also by link layer service quality support and thephysical set-up of the network, for example These issues will beelaborated in Section 3.8 and in Chapter 5

capabil-An issue of practical importance is the amount of tion and operations support required on different network layers.Performing service quality support configuration on as few net-work layers as possible and in as automated a way as possible isperceived to be an important goal Such an approach can bringconsiderable benefits to the network operator, in the form of low-ered operability costs, and also to the end user, in the form ofincreased network reliability This is one of the drivers in studyinglight protocol stacks such as IP/MPLS over WDM

QUALITY

The ITU-T draft recommendation [Y.1541] lists the network servicequality support mechanisms for different QoS classes in Table 3.1

Table 3.1 QoS support mechanisms for ITU-T’s draft QoS classes  tional Telecommunication Union

Interna-QoS class Node mechanisms Network techniques

0 Separate queue with

4 Long queue, drop priority Any route/path

5 Separate queue (lowest

priority)

Any route/path

Source: From [Y.1541].

[Y.1221] lists the following traffic control functions: networkresource management, admission control, parameter control(corresponding to policing), packet marking, traffic shaping,and packet scheduling In what follows, different service qualitysupport technologies are put into a generic context to structuredifferent ways of service quality support

Assuming that protocol stacks and network topology have beenselected, the following classification of generic ways of a network

to provide support for services is used in this book:

1 Reserve capacity for service events in transport elements

2 Provide support for differentiating treatment for service events

in transport elements

3 Provide means of differentiating service instantiation

An example, best effort treatment with over-dimensioning is

a special case of the first option In the above list, all themeans seek to address the same issue, namely that of providingsufficient network capacity for selected service type or types.The three issues listed address this from different – but notnecessarily mutually exclusive – viewing angles For example,option 2 indicates that some service types are to be prioritized with

respect to others at times of congestion, not ruling out options 1and 3 Please note that the third category speaks of differentiation

in service instantiation, that is, invocation of the service in the

first place

The optimization of network utilization will be discussed later

in Chapter 5 In this chapter, the emphasis is mostly on technicalservice quality support means

Capacity reservation for a service means that a quota of networkcapacity is allocated to a service support class Network-wide, thismeans that capacity is reserved along the route of a service event

in applicable network elements The set of elements in which thissupport is implemented for a particular service may be predefined

or not Reservation may be mathematically strict or more statistical

in nature Capacity reservation can be either predefined or signalled.

In the latter case, the signalling does not necessarily take place perservice instantiation, as can be seen below

Routing of a capacity reservation is clearly important Whenthe capacity reservation is interpreted literally, capacity needs to

be put aside in the network on a semi-permanent basis, or someform of service quality support negotiation must be implemented

In both cases, the service instances entitled to the associated vice quality support type need to be routed along the reservation

ser-In case of signalled reservation, the reservation state may ther need to be transferable between network elements if routing

fur-of service instances changes In general, a service instance may

be composed of service events having different routes across thenetwork In this case, separate, possibly homogeneous capacityreservations for service event types may need to be applied.Capacity reservation, in general, can be of the following types:

1 Physical Part of the network capacity on physical layer is cated to a service For instance, in a fibre-based optical networkusing WDM, one wavelength could be reserved for circuit-switched telephone calls between two switching centres

allo-2 Signalled semi-permanent “Permanent” reservations for vice classes can be set up with appropriate protocols usingsignalling The ATM Permanent Virtual Circuit (PVC) is anexample of this

ser-3 Signalled on demand Reservation is set up on demand for one

or more service instances Examples of this include the ATMSwitched Virtual Circuit (SVC) and IETF’s IntServ frameworkusing RSVP signalling for capacity reservation along paths ap-plied to individual flows

4 Statistical reservation Reservation is interpreted using fined statistical terms, for example, as being available 95% ofthe time

prede-In the first and the second case, the routing for a service can beperformed as a part of network planning In the third case, routing

of the reservation is based on existing reservations in the networkand the requested service quality support for the new flow Allthe capacity reservation methods described either implement ser-vice quality support instantiation limitation/differentiation – that

is, admission control – or would benefit from it Service qualityinstantiation control can be based on request accepted/requestdenied, or can also include service quality support-type renegotia-tion Statistical reservations are relevant for multiplexing-orientedsolutions, and allow for less formal types of instantiation control

to be exercised if need be

Another kind of support that a network can provide is ated treatment according to service type The following possibili-ties exist:

differenti-1 Differentiation with respect to reliability What kinds of guarantees

on reliable PDU delivery are provided to a service instance? Thefollowing alternatives can be provided:

a Guaranteed reliability for a service instance

b No guarantees about reliable PDU delivery This is the plainInternet Protocol model

c Guaranteed reliability up to a limit (e.g., NBR), reliabilitybeyond that subject to availability of resources This model isused, for example, in Frame Relay (FR) and ATM’s concept

of SCR and PCR The PDUs exceeding NBR can be marked

as lower priority ones, and per-PDU prioritization can beapplied to them

Differentiation with respect to reliability can be obtained by viding, for example, the first alternative to some service types,and the second to others Alternatively, no absolute guaran-tees are provided to any of the service types, but reliabilitydifferentiation is implemented on PDU level within the lim-its of momentary loading levels This is explained in moredetail below.

pro-2 Prioritization with respect to SDU loss If PDU loss can occur at

times of network congestion, can different service events beprioritized with respect to PDU loss? The alternatives are:

a Yes This is the approach used in IETF’s Differentiated vices’ (DiffServ) drop precedence classification and ATM CellLoss Priority (CLP) bit

Ser-b No This is the traditional Best Effort model of IP networks.Prioritization with respect to PDU loss provides a statisticalperformance profile Such differentiation tools can be used fordifferentiating the importance of traffic exceeding agreed-uponNBR from the importance of within-profile traffic, on the onehand, or between traffic types, on the other

3 Prioritization with respect to PDU forwarding Can a

store-and-forward type network element prioritize PDUs belonging todifferent service event types with respect to forwarding rapid-ity? The answers are:

a Yes Implemented by DiffServ’s forwarding priority classes

b No This is the traditional Best Effort model

It should be noted that capacity reservation, too, is one form ofprioritization with respect to PDU forwarding The two, how-ever, are not conceptually equivalent

4 Differentiation with respect to routing Is differentiated routing per

service event type supported?

a Yes This is the approach of ATM PVCs and SVCs, and canalso be implemented with Label-Switched Paths (LSPs) inMulti-Protocol Label Switching (MPLS)

b No This is the approach of traditional IP routing protocols,where routing is performed per packet

A note about packet switching and routing is in order here ferentiated routing benefits from routing of a service event being

Dif-controllable In the classical IP thinking based on robustness ofnetworks, each packet is – in principle – routed independently,

whereby route flapping between two or more routes for packets

belonging to a single flow is possible [Pax97, Pax97b] The firststep towards differentiated routing would be to divert some ser-vice event types to a path with something else as lowest cost,while other traffic types would be routed along the lowest costpath In this Type-of-Service (ToS) routing, the routing of indi-vidual service events could still be done per packet, followingthe basic philosophy of packet switching Alternatively, all PDUsbelonging to a service event type can be routed in a connection-oriented way using a predefined path This property, which could

be implemented with ATM or MPLS, for example, may be able in order to avoid switching back and forth between routes ofdifferent length

desir-Routing differentiation can be provided for some traffic typesonly, if both IP routing and connection-oriented routing can bemixed in the same network elements

What sets routing differentiation apart from capacity tion is that the former does not necessitate hard reservations.Routing differentiation can be applied to packets, flows or traf-fic aggregates

The network can secure service quality for selected services bylimiting access to network quality support resources on per-servicetype basis The options are:

1 Service quality instantiation control can be linked to the qualityrequirements of service event types This is the approach used

in RSVP, ATM, as well as GPRS and 3GPP cellular networks

a A subtype of this is admission control applied on coarser vice classification granularity For example, real-time serviceevents vs non-real time service events

ser-2 Service quality instantiation control is based on user type

3 Service quality instantiation control is applied to all servicesequally Upon a predefined condition being met, all furtherconnections are blocked, irrespective of service event type

4 No formal service quality instantiation control is used This isthe default behaviour of IP networks Severe enough congestion

can lead to service instance invocation being interrupted by theuser, or by protocols.

The different methods listed above can be combined It shouldalso be noted that the actual service instantiation decision may

be different from service quality support instantiation decision; inplain English, the service may be started even when the networkturns down the request for enhanced service quality

Not having a service quality instantiation mechanism in a work domain means that in case of congestion, services within

net-a single cnet-apnet-acity reservnet-ation will hnet-ave to estnet-ablish the division ofthe bandwidth among themselves In such a case, the properties ofapplication protocols become important: TCP-based applicationswill “back off” when congestion occurs, which may lead to UDP-based applications benefiting from the congestion

support mechanisms

Different network techniques for supporting service quality werediscussed above, including capacity reservations, differentiatedtreatment, and differentiated service quality instantiation.Different kinds of network service quality support mechanismscan in general coexist, even though capacity reservations anddifferentiation-based methods are often considered to belong todifferent paradigms The scope of network service quality supportmechanisms is summarized in Table 3.2

All the mechanisms listed in Table 3.2 have the potential to affectthe quality of the whole service event, and of applying to an entirenetwork domain However, some mechanisms are clearly moredirectly related to deterministic control of certain scope Thus, forexample, loss and forwarding prioritization are applied in indi-vidual network element, depending on the statistically varyingloading situation within the element in question Routing differ-entiation, on the other hand, has a direct deterministic impact onother network elements

The possibility of having multiple service event types within

a single service instance may need to be taken into account indesigning network-side service quality support The reason for this

is that if instantiation of a service requires that all the service event

Table 3.2 Summary of scopes of network service quality support mechanisms

Capacity reservation Network element or

network domain

Service type

Reliability differentiation Endpoint Service instance or

service event SDU loss differentiation Network element Service event

SDU forwarding

differentiation

Network element Service event

Routing differentiation Network domain Service type or service

instance Service quality instantiation

differentiation

Network domain Service instance

types are provided with appropriate service quality instantiation,failure of the latter for any of the service event types leads tofailure of the entire service instantiation

Next, we shall study how these apply to service models ofInternet Protocol QoS support mechanisms, using ATM as a com-parison Let us first take a look at ATM first

ATM is an extension of ISDN into broadband domain Whereasnarrowband ISDN was based on Time-Division Multiplexing(TDM), ATM is based on 53-byte (octet) cells that aretransmitted asynchronously between switches (The somewhatstrange cell size of 53 bytes – 53 is an indivisible number, forstarters – was a standardization compromise between competingcell size proposals.)

Several ATM Adaptation Layers (AALs) have been defined forinterfacing towards different service types, the most importantbeing

• AAL1: circuit emulation service for delay-critical traffic;

• AAL2: for delay-sensitive Variable Bit-Rate streams;

• AAL5: frame or packet-oriented services Suitable for ing TCP/IP.

transport-Thus, IP-based services can interface to ATM using suitable AALs,

or can use TCP/IP over AAL5 The latter has been de facto

alterna-tive, since ATM is not available end-to-end Also other adaptationlayers have been used for trunking purposes, for example

The ATM forum has defined the following service categories[ATM]:

1 CBR (Constant Bit Rate) Capacity equal to PCR is provided forthe service event type or service instance

2 RT-VBR (Real-Time Variable Bit Rate) The network guaranteescapacity SCR to service instantiation on the average, and sup-

ports bursts with maximum capacity requirement <=PBR and

volume smaller than Maximum Burst Size (MBS) Low-delayservice is provided

3 NRT-VBR (Non-Real Time Variable Bit Rate) As above, exceptthat no guarantees about delay or delay variation are provided

4 UBR (Unspecified Bit Rate) No guarantees about service ity, roughly equal to IETF’s best effort service model (see below)for traffic mapped into UBR

qual-5 ABR (Available Bit Rate) Access to capacity not used by otherservices Service support determined by Minimum Cell Rate(MCR) and PCR No delay or delay variation guarantees aregiven

More discussion on ATM services can be found, for example,

in [McD00]

ATM provides multiple degrees of service quality support, rangingfrom capacity reservation to available bit rate Different degrees

of burstiness are supported in the service models ATM servicesupport is summarized in Table 3.3

Table 3.3 Summary of service quality support in ATM

Capacity reservation CBR: yes, RT-VBR: yes, NRT-VBR:

statistical Reliability differentiation According to service model + on

SDU level SDU loss differentiation Yes

SDU forwarding prioritization No explicit forwarding priority,

implicitly present in capacity reservations and mapping to VCs of different type SDU routing differentiation Traffic can be mapped into

different VCs Service quality instantiation

differentiation

Depends on service model

PROTOCOL

With in reference to OSI model, IP operates on layer 3, providingper-packet routing for PDUs – IP packets – based on IP destina-tion address Two versions of IP exist, IPv4 having 32-bit addressfields and IPv6 having 128-bit address fields Application typicallyinterfaces to Internet Protocol on “layer 4” using the abstraction

of port numbers in addition to source and destination addresses,but also “raw socket” mode interfacing directly to IP is possible.Accessing of raw sockets is typically limited to system administra-tors, and the programs of normal users can only open multiplexedL4 sockets This is the case in Linux, for example

IPv6 brings with it the possibility of identifying a flow usingthe flow label field in the IPv6 header [RFC2460] According tothe latest proposal, an IPv6 flow is uniquely identified by thetriplet (source address, destination address, flow label) [RCC+ 02].The practical device for an application programmer to access-ing layer 4+ layer 3 both in IPv4 and IPv6 is the Berkeley Sys-tem Distribution (BSD) socket interface, providing communicationservices through a data structure reminiscent of a UNIX file

descriptor [St98] Blocking, non-blocking, and signal-based munication through the socket interface are possible In addition tosetting the DiffServ Code Point (DSCP) in IPv4 and IPv6 packets,latest extensions to the socket control interface make it possible toset the flow label in IPv6 packet headers The socket abstractionhas proven to be very successful.

com-In what follows, the service quality support in IP is described,first for the basic IP protocol (best effort), and then for two differentparadigms for implementing service quality support to IP, namelyIntegrated Services (IntServ) and Differentiated Services (DiffServ).The best effort and DiffServ paradigms will be discussed further inSections 3.6.1 and 3.6.5 The IntServ framework covers the servicemodels presented in Sections 3.6.2 and 3.6.3 as well as signalling

in Section 3.6.4, which is why it is summarized here next

The Integrated Services is a framework developed in IETFduring 1990s to implement multi-service support in the Internet,encompassing a service model and an implementation frameworkand signalling [RFC1633] The two service models currentlydefined for IntServ are guaranteed quality and controlled loadsupport The implementation framework of IntServ includesscheduler, classifier, and admission control as architecturalcomponents Controlled load service support [RFC2211] andguaranteed QoS support [RFC2212] discussed in Sections 3.6.2and 3.6.3 and Section 3.6.4 are implementations of the IntServframework Resource Reservation Protocol (RSVP) is the “weapon

of choice” for the present implementation of IntServ in theInternet, and is specified in a series of RFCs, the first being[RFC2205] The role and consequences of RSVP are discussed inSection 3.6.4

The prevalent “service model” of today’s Internet is BE, whichmeans that IP network does not provide any service guarantees.Thus, there are no guarantees against unavailability, excessivedelays, or packet losses This is possible since the Internet Protocol

is neither connection-oriented nor reliable Typically, either TCP

or UDP is used as the transport layer protocol above IP layer toprovide convenient programming interface and application streammultiplexing according to port number TCP provides reliability

on the transport layer, whereas UDP only provides for error tion Obviously, very little can be done on the transport layer tocontrol delay and delay variations, if the IP layer does not sup-port this.

detec-The means of providing good service quality with best effort vice model is over-dimensioning of the network When no router iscongested, queueing delays and delay variations remain small andpacket loss does not occur Best Effort and over-dimensioning are

ser-by far the simplest way of implementing service quality nately they are not the cheapest one, as we saw at the beginning

Unfortu-of this chapter! Strict over-dimensioning requires that there is ficient IP network capacity for transferring traffic at all times inall the routers This means that the network needs to be dimen-sioned according to peak hour traffic Such an approach often leads

suf-to a considerable part of network capacity not being utilized formost of the time, being a major handicap in certain access net-works, as we shall see in Chapter 9 In [GCK+ 01], authors arguethat too much trust should not be put on over-dimensioning and

go on to present ways of improving best effort Internet, ing feedback mechanisms (e.g., Explicit Congestion Notification,ECN), scheduling mechanisms, and buffer management mecha-nisms One clear argument in favour of this line of thinking is thefact that means of coping with traffic growth are very limited in

includ-an over-dimensioned network

The feasibility of best effort transport in the network core can beenhanced by applying SLAs to end user flows at the edge of thenetwork to limit the average volume and especially burstiness oftraffic Depending on the granularity of control, SLAs can be madeuser-class specific This approach, while simple, does not alwaysutilize the core network capacity in an optimal manner, since thedifferences in service quality requirements cannot be utilized inthe best possible manner

It should be noted that although over-dimensioning is not ways an optimal solution, it is often fully feasible in high-capacityparts of the network such as long-haul backbone networks Manyfactors contribute to this, for example, percentual variations intraffic become smaller with increasing aggregation level (centrallimit theorem) A very important reason can be a rapid increase

al-in traffic volumes, whereby it is an economically sound strategy

to prepare for larger traffic volumes

3.6.2 Controlled-load service support

Controlled-load service is an implementation of IETF’s IntegratedServices framework The behaviour of IETF controlled-load servicesupport is specified in [RFC2211] as being approximately equal

to, from the point of view of a service instance, service quality in

an unloaded network The service level support is also providedwhen the network is overloaded This definition is applicable

to the SLA-conformant part of service traffic, as measured by atoken bucket regulator Adaptive real-time applications are cited

as an example of the service type potentially benefiting from thisservice model

More precisely, the following description is provided of load service [RFC2211]:

controlled-Assuming the network is functioning correctly, these cations may assume that:

appli-i A very high percentage of transmitted packets will besuccessfully delivered by the network to the receiving end-nodes (The percentage of packets not successfully deliv-ered must closely approximate the basic packet error rate

of the transmission medium.)

ii The transit delay experienced by a very high percentage ofthe delivered packets will not greatly exceed the minimumtransmit delay experienced by any successfully deliveredpacket (This minimum transit delay includes speed-of-light delay plus the fixed processing time in routers andother communications devices along the path.)

To receive controlled-load service support, an endpoint must ply flow properties in the form of TSpec Note that RSpec is notnecessary due to the definition of the service support model Theactual implementation of the service model is left open in theRequest for Comment (RFC) in question, but notes about requiredper-network element function are listed

sup-Controlled-load service is described by the RFC author as tionally minimalistic” It is indeed conceptually simple, but due tomissing information about RSpec, different degrees of service qual-ity requirements cannot be leveraged in the network configuration.For example, delay requirements for VoIP are stringent, whereas