Tải bản đầy đủ (.pdf) (44 trang)

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

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (241.39 KB, 44 trang )

3
Network Mechanisms
for Multi-service Quality
Support
This chapter deals with service quality support mechanisms in the
network. Of particular interest are mechanisms inside an Inter-
net Protocol domain, including edge treatment and service qual-
ity support mechanisms in the network core. Requirements for
signalling between the endpoint and the network edge will be
discussed in Chapter 5.
The Internet today is based on the Best Effort (BE) service para-
digm in which all IP traffic on a network link is treated alike,
or in other words, no service quality support is provided when
momentary traffic volume exceeds link capacity. Subsequently, to
offer true multi-service support for critical traffic types such as
VoIP in an IP-based network, the technical tasks to be carried out
by an IP service provider seem challenging at first sight. Not only
must mechanisms be provided for implementing the network sup-
port for different service types, but also mechanisms are needed to
map service requirements onto network resources. To make best
use 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
54 NETWORK MECHANISMS FOR MULTI-SERVICE QUALITY SUPPORT


It turns out that implementation of multi-service quality support
in an IP domain is possible and manageable. Moreover, this sup-
port can be provided with a mechanism allowing the network
element in the core of the network to be kept simple.
Despite technical feasibility, multi-service support in IP network
is not likely to be immediately adopted by all ISPs and other net-
work operators. However, the ability to provide better-than-best
effort service will become an important business proposition due
to the progress of content digitalization to include also non-data
type 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 multi-
service quality support mechanisms and ways of implementing
them with present-day technology in a cost-efficient way. Further,
service level description mechanisms needed at the boundaries
of operators’ domains are accounted for in this and subsequent
chapters.
In this chapter, we shall first briefly review issues relevant to
network multi-service quality support, and discuss policing at the
edge of the network and the effect of different protocol layers
to service quality. Next, the generic ways of supporting service
quality are reviewed, followed by a summary of service quality
support means in ATM and IP. Routing control in IP networks
and link layer service quality issues are discussed next, and the
present chapter concludes with a summary.
This chapter attempts to demonstrate that the building blocks
for service quality support mostly exists already today without
ATM. ATM-based service quality support is used as a point of
reference in this chapter. Management of IP-based service quality
will be discussed further in the next chapter, and the provision of

network resources in Chapter 5. Routing control beyond the basic
operation of IP routing protocols will be discussed in this chapter,
and further in next chapter.
3.1 INTRODUCTION TO NETWORK QUALITY SUPPORT
The adoption of dedicated multi-service quality support mecha-
nisms in the network is only necessary when the following two
conditions are met:
3.1 INTRODUCTION TO NETWORK QUALITY SUPPORT 55
1. Over-dimensioning of the network is not a feasible solution.
2. Providing of engineered service quality level for some service
traffic types transported in the multi-service network such as
low 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 transmitting
the momentary traffic volumes so that the service quality require-
ments of transported streams are satisfied. The latter condition
amounts to delay requirement of all traffic being determined by
the most delay-critical and loss-intolerant service type.
An application example is in a corporate access network carry-
ing Voice over IP, sharing the access network capacity with bursty
HTTP traffic and Simple Mail Transfer Protocol (SMTP) traffic. It
may not be economically feasible to dimension the network to
handle the largest possible bandwidth bursts. This would neces-
sitate providing the same delay to transport of HTTP and SMTP
than VoIP.
If over-provisioning is not a feasible alternative, either a sepa-
rate capacity is provided for VoIP, or a prioritization mechanism
needs to be built into the actual network transport to provide
differentiated handling for distinct service quality classes. These
main alternatives benefit from further support mechanisms, the

most important of which are discussed below. Before that, how-
ever, let us note that service quality support may be needed even
with a single service quality type. An example of this could be
providing pre-defined performance for browsing traffic. In such
a case, a suitable subset of the service quality support machinery
reviewed below could be used.
Let us now discuss service quality support on a more general
level. 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 service
types: capacity reservation and differentiated treatment. Capac-
ity reservation means that a part of the total capacity of a link is
reserved 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 the
other hand, means not reserving any fixed capacity, but priori-
tizing service types with respect to each other when momentary
56 NETWORK MECHANISMS FOR MULTI-SERVICE QUALITY SUPPORT
0
1
2
3
4
5
6
1
6 11 16 21 26 31 36 41 46
Capacity
Differentiation
Sum

Reservation
Non-urgent traffic
Urgent traffic
Time
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 momentary
variations in the volume of more urgent traffic.
Let us next compare the over-dimensioning approach against
capacity reservation and differentiated treatment using a case
study. Figure 3.1 below shows a case in which the average volume
of non-urgent traffic is fivefold as compared to the volume of
urgent 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, and
dimensioning 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 average
volume of all traffic, i.e., approximately capacity of 3 units. In
this case, differentiation based on urgency brings capacity-saving
benefits of 50% compared to over-dimensioning, and more than
14% based on capacity reservation for non-urgent traffic. This
requires 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. An
exact analysis of the process requires application of queueing

theory, potentially yielding corrections to the simple case when
the size of largest packets is not insignificant with respect to total
link capacity. The fact that packet length can vary gives rise to
variation in the service time of a packet, causing variable amount
of delay to the subsequent packets.
3.1 INTRODUCTION TO NETWORK QUALITY SUPPORT 57
A further advantage of multiplexing is that the relative burst-
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.
In general, the saving calculation figures will depend on the
percentage of traffic types, which need priority treatment. If all
of the traffic needs priority treatment and is delay-sensitive, over-
dimensioning is the only alternative. As mentioned above, appli-
cation of some service quality control means may be beneficial also
in this case from the point of view of end user experienced qual-
ity. At the other end of the spectrum, when priority traffic with
variable bandwidth is sharing the link with bursty non-urgent
traffic and the maximum volume of priority traffic is less than
half 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
to maximize utilization of installed capacity. The dimensioning
of capacity reservations is a well-established discipline, and more
information about that can be found in [McD00], for example.
The above analysis calls our attention to the following important
issues in considering the usefulness of differentiated treatment in
the network:

• Are savings from implementation of differentiated treatment high
enough? Implementing support for differentiated treatment in
the network makes the elements more complex and poses
requirements 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 may
not be practical.
• Are relative volume shares of services known? Traffic volumes need
to be known or limits need to be imposed to maintain per-node
differentiation. 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.
58 NETWORK MECHANISMS FOR MULTI-SERVICE QUALITY SUPPORT
Mathematically, feasibility of prioritization-based multiplexing in
a multi-service network is determined by whether service require-
ment specification for a service allows for service instantiations of
that type to be displaced in time, or their total throughput limited.
Some analysis techniques for this will be discussed in Chapter 5.
What has been discussed above are de facto preconditions for
using differentiation. More generally, the reasons for choosing
prioritization-based mechanisms over other alternatives may not
be related solely to the mathematics of dimensioning. The multi-
service multiplexing paradigm based on service differentiation in
the network has the following benefits according to Kilkki [Kil99]:
• fairness;
• robustness;
• versatility;

• cost efficiency.
A detailed analysis of these factors is beyond the scope of this
book, and the interested reader is referred to Kilkki’s book. Suffice
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 price
the 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 malev-
olent users, and versatility relates to the selection of tools at the
network provider’s disposal in providing service quality support
for a multiplicity of needs. Cost efficiency is a measure of the
required monetary investment for implementing the service qual-
ity goals. A related topic, we shall discuss utility-based service
allocation in Chapter 5.
3.2 POLICING OF TRAFFIC AT INGRESS
To put the service quality management methods presented later
in a general context, the reference model shown in Figure 3.2 is
used for this chapter. On the network side, a service instantiation
can be thought of as being conceptually associated with a ser-
vice quality support instance. The service quality support instance
defines the quality support provided to the service instance by the
network domain.
3.2 POLICING OF TRAFFIC AT INGRESS 59
Network
NE
NE
NE
NE
NE
Client

Client or server
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
Capacity
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-type
traffic descriptor. The significance of these characteristics is that a
service instance needs capacity of NBR to function properly, and
may 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 burst
here means a period during which the momentary bit rate exceeds
MBR. In ATM, Sustainable Cell Rate (SCR) roughly corresponds to
NBR and Peak Cell Rate (PCR) to PBR. The flow descriptor param-
eters are assumed to be specified as a part of a SLA between the
client and the network operator, more or less explicitly.
For networks with appropriate function in place, the confor-
mance of service instance to a traffic descriptor – for example, the
triplet (NBR, PBR, MBS) – can be verified and imposed by policing

the service flows at network ingress point. Performing policing at
60 NETWORK MECHANISMS FOR MULTI-SERVICE QUALITY SUPPORT
ingress is beneficial, as accumulation of burstiness in the network
is best prevented by applying the “traffic contract” between oper-
ator and end user as soon as possible. The traffic contract can
be considered to be a form of a SLA. If ignored, accumulation
of burstiness would make service quality support management in
network core difficult. Performing policing at the network edge
instead of network core elements is useful due to traffic volumes
being 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 support
mechanism scenarios described above. Specifically, applying traf-
fic conditioning to non-urgent traffic in the scenario of Figure 3.1
reduces the need for maximum bandwidth in over-provisioning
scenario. This is also true when there is only non-urgent traffic in
the 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 by
having parts addressing different service event types. The applica-
ble service type is assumed to be detected either based on signalled
state, or on protocol data such as IP address and/or port number.
When signalled instalment of policing is used, for example, RSVP
can be used for that purpose. Protocol data filter can be a fixed one,
or vary with operator-defined conditions. A single service instance
consisting of service events of different types may map to multi-
ple SLA service type components. For example, a teleconferencing
service instance could include VoIP service event type with strin-
gent service quality, and a data application sharing service event
type with different SLA service quality profile.

A practical device for verifying conformance to SLA is typically
either leaky bucket or token bucket regulator controlling regulator
function. The conformance check can be assumed to be of leaky
bucket 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-profile
burstiness 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 the
network. In addition to being better able to control the quality of
one’s own services, policing one’s own outgoing traffic allows the
user to better understand the properties of one’s own traffic.
3.3 ABOUT LAYERS 61
In general, the following actions can be applied to out-of-profile
traffic:
• Traffic shaping. Burstiness is smoothened out by buffering out-
of-profile traffic. Due to finite buffer size or maximum allowable
delay 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.Thismethod
allows the out-of-profile traffic to utilize unused capacity in the
network.
• Do nothing. Statistics of out-of-profile traffic volumes may still
be recorded.
Means of configuring policing will be discussed in the next chap-
ter. The importance of conditioning will be referred to later in the
context 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 to
Gaussian (well-behaved) aggregates with the number of flows in
the network core [NZA99]. Such problems may arise due to bursty
end-user traffic flows, technically described as being fractal or hav-
ing long-range correlations. A classic example of this is fractality in
Ethernet-based LAN [LTW + 94]. With increasing flow aggregation
level, the arrival process on a link tends towards Poisson process,
and the adverse effects of burstiness are reduced [CCL + 02].
3.3 ABOUT LAYERS
The ISO/OSI reference model enumerates no less than seven lay-
ers of interconnectivity. The lowest three or four of these layers are
often referred to in practical engineering. A well-known generic
property 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 into
Transport Layer (layer four) of OSI model, but ATM and MPLS are
both partly layer 2 and partly layer 3. This is because they include
routing functions like layer 3 protocols, but are still “link layer”
protocols from the viewpoint of IP applications. For the purposes
of concreteness, the four lowest layers of OSI reference models are
62 NETWORK MECHANISMS FOR MULTI-SERVICE QUALITY SUPPORT
802.3
IP
AT M
AAL
MPLS
AAL
IP
UDPTCP
Link layer

Physical
layer
Network
layer
Transport
layer
Figure 3.4 An illustration of mismatch of protocols with respect to ISO/OSI
protocol reference model using example protocol stacks
nevertheless often used. Figure 3.4 shows examples of approxi-
mate relations of often-used Internet protocol stacks with respect
to ISO/OSI model. The link layer also includes the Medium Access
Control (MAC) layer in Figure 3.4.
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 of
TCP and UDP for service quality has been discussed in the previ-
ous chapter, being an issue the endpoint application can partially
affect by choosing either TCP or UDP when instantiating a service.
On the network side, the overall service quality support capabil-
ity is affected also by link layer service quality support and the
physical set-up of the network, for example. These issues will be
elaborated in Section 3.8 and in Chapter 5.
An issue of practical importance is the amount of configura-
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 is
perceivedtobeanimportantgoal.Suchanapproachcanbring
considerable benefits to the network operator, in the form of low-
ered operability costs, and also to the end user, in the form of
increased network reliability. This is one of the drivers in studying

light protocol stacks such as IP/MPLS over WDM.
3.4 TYPES OF NETWORK SUPPORT FOR SERVICE
QUALITY
The ITU-T draft recommendation [Y.1541] lists the network service
quality support mechanisms for different QoS classes in Table 3.1.
3.4 TYPES OF NETWORK SUPPORT FOR SERVICE QUALITY 63
Table 3.1 QoS support mechanisms for ITU-T’s draft QoS classes  Interna-
tional Telecommunication Union
QoS class Node mechanisms Network techniques
0 Separate queue with
preferential
Constrained routing and
distance
1 Servicing, traffic grooming Less constrained routing
and distances
2 Constrained routing and
distance
3 Separate queue, drop priority Less constrained routing
and distance
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: network
resource management, admission control, parameter control
(corresponding to policing), packet marking, traffic shaping,
and packet scheduling. In what follows, different service quality
support technologies are put into a generic context to structure
different ways of service quality support.

Assuming that protocol stacks and network topology have been
selected, 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 the
means seek to address the same issue, namely that of providing
sufficient network capacity for selected service type or types.
The three issues listed address this from different – but not
necessarily mutually exclusive – viewing angles. For example,
option 2 indicates that some service types are to be prioritized with
64 NETWORK MECHANISMS FOR MULTI-SERVICE QUALITY SUPPORT
respect to others at times of congestion, not ruling out options 1
and 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 technical
service quality support means.
3.4.1 Capacity reservation
Capacity reservation for a service means that a quota of network
capacity is allocated to a service support class. Network-wide, this
means that capacity is reserved along the route of a service event
in applicable network elements. The set of elements in which this
support 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 per
service instantiation, as can be seen below.
Routing of a capacity reservation is clearly important. When
the capacity reservation is interpreted literally, capacity needs to
be put aside in the network on a semi-permanent basis, or some
form of service quality support negotiation must be implemented.
In both cases, the service instances entitled to the associated ser-
vice quality support type need to be routed along the reservation.
In case of signalled reservation, the reservation state may fur-
ther need to be transferable between network elements if routing
of service instances changes. In general, a service instance may
be composed of service events having different routes across the
network. In this case, separate, possibly homogeneous capacity
reservations 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 allo-
cated to a service. For instance, in a fibre-based optical network
using WDM, one wavelength could be reserved for circuit-
switched telephone calls between two switching centres.
2. Signalled semi-permanent. “Permanent” reservations for ser-
vice classes can be set up with appropriate protocols using
signalling. The ATM Permanent Virtual Circuit (PVC) is an
example of this.
3.4 TYPES OF NETWORK SUPPORT FOR SERVICE QUALITY 65
3. Signalled on demand. Reservation is set up on demand for one
or more service instances. Examples of this include the ATM
Switched Virtual Circuit (SVC) and IETF’s IntServ framework
using RSVP signalling for capacity reservation along paths ap-
plied to individual flows.
4. Statistical reservation. Reservation is interpreted using prede-

fined statistical terms, for example, as being available 95% of
the time.
In the first and the second case, the routing for a service can be
performed as a part of network planning. In the third case, routing
of the reservation is based on existing reservations in the network
and the requested service quality support for the new flow. All
the capacity reservation methods described either implement ser-
vice quality support instantiation limitation/differentiation – that
is, admission control – or would benefit from it. Service quality
instantiation control can be based on request accepted/request
denied, or can also include service quality support-type renegotia-
tion. Statistical reservations are relevant for multiplexing-oriented
solutions, and allow for less formal types of instantiation control
to be exercised if need be.
3.4.2 Differentiated treatment
Another kind of support that a network can provide is differenti-
ated treatment according to service type. The following possibili-
ties exist:
1. Differentiation with respect to reliability. What kinds of guarantees
on reliable PDU delivery are provided to a service instance? The
following alternatives can be provided:
a Guaranteed reliability for a service instance.
b No guarantees about reliable PDU delivery. This is the plain
Internet Protocol model.
c Guaranteed reliability up to a limit (e.g., NBR), reliability
beyond that subject to availability of resources. This model is
used, for example, in Frame Relay (FR) and ATM’s concept
ofSCRandPCR.ThePDUsexceedingNBRcanbemarked
as lower priority ones, and per-PDU prioritization can be
applied to them.

66 NETWORK MECHANISMS FOR MULTI-SERVICE QUALITY SUPPORT
Differentiation with respect to reliability can be obtained by pro-
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 reliability
differentiation is implemented on PDU level within the lim-
its of momentary loading levels. This is explained in more
detail below.
2. Prioritization with respect to SDU loss. If PDU loss can occur at
times of network congestion, can different service events be
prioritized with respect to PDU loss? The alternatives are:
a Yes. This is the approach used in IETF’s Differentiated Ser-
vices’ (DiffServ) drop precedence classification and ATM Cell
Loss Priority (CLP) bit.
b No. This is the traditional Best Effort model of IP networks.
Prioritization with respect to PDU loss provides a statistical
performance profile. Such differentiation tools can be used for
differentiating the importance of traffic exceeding agreed-upon
NBR from the importance of within-profile traffic, on the one
hand, or between traffic types, on the other.
3. Prioritization with respect to PDU forwarding.Canastore-and-
forward type network element prioritize PDUs belonging to
different 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 of
prioritization 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 can
also be implemented with Label-Switched Paths (LSPs) in
Multi-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. Dif-
ferentiated routing benefits from routing of a service event being
3.4 TYPES OF NETWORK SUPPORT FOR SERVICE QUALITY 67
controllable. In the classical IP thinking based on robustness of
networks, 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 first
step 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 cost
path. In this Type-of-Service (ToS) routing, the routing of indi-
vidual service events could still be done per packet, following
the basic philosophy of packet switching. Alternatively, all PDUs
belonging 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 desir-
able in order to avoid switching back and forth between routes of
different length.
Routing differentiation can be provided for some traffic types
only, if both IP routing and connection-oriented routing can be
mixed in the same network elements.
What sets routing differentiation apart from capacity reserva-
tion is that the former does not necessitate hard reservations.
Routing differentiation can be applied to packets, flows or traf-

fic aggregates.
3.4.3 Differentiation of service quality instantiation
The network can secure service quality for selected services by
limiting access to network quality support resources on per-service
type basis. The options are:
1. Service quality instantiation control can be linked to the quality
requirements 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 ser-
vice classification granularity. For example, real-time service
events vs. non-real time service events.
2. Service quality instantiation control is based on user type.
3. Service quality instantiation control is applied to all services
equally. Upon a predefined condition being met, all further
connections are blocked, irrespective of service event type.
4. No formal service quality instantiation control is used. This is
the default behaviour of IP networks. Severe enough congestion
68 NETWORK MECHANISMS FOR MULTI-SERVICE QUALITY SUPPORT
can lead to service instance invocation being interrupted by the
user, or by protocols.
The different methods listed above can be combined. It should
also be noted that the actual service instantiation decision may
be different from service quality support instantiation decision; in
plain English, the service may be started even when the network
turns down the request for enhanced service quality.
Not having a service quality instantiation mechanism in a net-
work domain means that in case of congestion, services within
a single capacity reservation will have to establish the division of
the bandwidth among themselves. In such a case, the properties of
application protocols become important: TCP-based applications

will “back off” when congestion occurs, which may lead to UDP-
based applications benefiting from the congestion.
3.4.4 Summary of generic network service quality
support mechanisms
Different network techniques for supporting service quality were
discussed above, including capacity reservations, differentiated
treatment, and differentiated service quality instantiation.
Different kinds of network service quality support mechanisms
can in general coexist, even though capacity reservations and
differentiation-based methods are often considered to belong to
different paradigms. The scope of network service quality support
mechanisms is summarized in Table 3.2.
All the mechanisms listed in Table 3.2 have the potential to affect
the quality of the whole service event, and of applying to an entire
network domain. However, some mechanisms are clearly more
directly related to deterministic control of certain scope. Thus, for
example, loss and forwarding prioritization are applied in indi-
vidual network element, depending on the statistically varying
loading situation within the element in question. Routing differ-
entiation, on the other hand, has a direct deterministic impact on
other network elements.
The possibility of having multiple service event types within
a single service instance may need to be taken into account in
designing network-side service quality support. The reason for this
is that if instantiation of a service requires that all the service event
3.5 SERVICE SUPPORT IN ATM 69
Table 3.2 Summary of scopes of network service quality support
mechanisms
Mechanism Network scope Service scope
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 to
failure of the entire service instantiation.
Next,weshallstudyhowtheseapplytoservicemodelsof
Internet Protocol QoS support mechanisms, using ATM as a com-
parison. Let us first take a look at ATM first.
3.5 SERVICE SUPPORT IN ATM
ATM is an extension of ISDN into broadband domain. Whereas
narrowband ISDN was based on Time-Division Multiplexing
(TDM), ATM is based on 53-byte (octet) cells that are
transmitted asynchronously between switches. (The somewhat
strange cell size of 53 bytes – 53 is an indivisible number, for
starters – was a standardization compromise between competing
cell size proposals.)
Several ATM Adaptation Layers (AALs) have been defined for
interfacing towards different service types, the most important
being

• AAL1: circuit emulation service for delay-critical traffic;
• AAL2: for delay-sensitive Variable Bit-Rate streams;

×