Tài liệu Thực hiện chất lượng dịch vụ trong các mạng IP (P8) pptx

8
Mechanisms for Dynamic
Service Quality Control
The means of dynamically controlling service quality in IP net-
works is our next topic. There are two primary uses for such
methods: dynamic control of resources within an IP domain, and
implementation of dynamic SLAs between domains. The generic
element handling both of these tasks is often called the “band-
width broker” (BB), and this convention is followed also within
this book.
Admission control or service quality instantiation control is not
part of the basic DiffServ framework [RFC2475]. Subsequently,
the need for IP service quality support mechanisms for
DiffServ networks other than edge provisioning and per-hop
prioritization mechanisms in core networks has been widely
acknowledged [RFC2638, Sch98, THD + 99, TAP + 01, JC01, SAF +
01, TIPHON-3]. The basic reason for the need of dynamic per-
domain service quality control mechanism is the following: up to
a limit, service quality for critical service types can be provided
by mapping them to a proper service quality support aggregate
such as EF. This works because of the prioritization mechanism of
DiffServ. Alas, when there is too much traffic within the EF PSC,
the flows sharing the PHB begin to suffer. The effect of EF PHB
to other PSCs within the router can be controlled by using rate
limiters, but basic DiffServ framework does not provide tools for
Implementing Service Quality in IP Networks Vilho R
¨
ais
¨
anen
 2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X

252 MECHANISMS FOR DYNAMIC SERVICE QUALITY CONTROL
dynamic control within the aggregate. Similarly, the quality in AF
PSCs suffers from too many service instances trying to share them.
Theend-userSLAsattheedgeofthenetworkareimposedby
policing of traffic at the edge of the DiffServ domain. As we saw
in Chapter 3, policing requires that adequate DiffServ classifier
be placed at the edge of the network. With statically configured
DiffServ classifiers only, it is not possible to perform dynamical
resource control. Basically, two techniques can be used to improve
on this:
• Admission control to existing classifiers. In this case, the classi-
fiercanbeperendpointIPaddress,perprefix,orpertraffic
aggregate. This requires that there is an extra-DiffServ means of
blocking flows.
• Installment of Diffserv classifiers on demand.
For the latter alternative, using of outsourced policy model is an
enabling technology from the control architecture point of view
[LV02]. Obviously, in addition to the machinery to distribute the
classifiers, there has to be a policy existing as to when to limit
service quality instantiation and intelligence to create the actual
DiffServ classifiers. Per-domain Bandwidth Broker (BB) is a poten-
tial tool for taking care of the former task, and for providing the
data for the second task. Recent examples of application of band-
width broker to manage the network resources in multi-service IP
network domain can be found in [Lak02] and [MNV02]. In the
former, the emphasis is on the algorithms used for controlling
resources, whereas in the latter, also an architecture for manage-
ment is needed.
Between the domains, being limited solely to static SLAs limits
the level of efficiency of network use that can be reached. This

is basically due to statistical multiplexing of flows in traffic
aggregates. If the SLA between two operator specifies that the
delays and packet losses have to be within certain range, it may
be beneficial for a transit network operator to make dimensioning
based slightly on conservative multiplexing calculation. If the
operator could indicate to the business parties of momentarily
available extra capacity, this capacity could be utilized. This
can be viewed as an enabling technology for the broker-
type market models discussed shortly in Chapter 5. Another
potential use of automated inter-domain communication between
MECHANISMS FOR DYNAMIC SERVICE QUALITY CONTROL 253
bandwidth brokers is implementing a transport transit service,
which performs admission control in the access domain solely
based on inter-domain bandwidth availability information. This
is one of the models discussed in end-to-end ETSI EP TIPHON
service quality support model [TIPHON-3], and has been analysed
in detail by Schel
´
en [Sch98]. A bandwidth broker controlled
DiffServ domain can also interface to a 3GPP domain with suitable
interworking arrangements, as discussed in [MNV02].
The basic DiffServ framework is based on the edge provisioning
principle, where policing and marking of traffic at the network
edge are the determining components for per-flow quality sup-
port. Using bandwidth brokers, per-flow service quality in Diff-
Serv can be made more closely integrated with the resource avail-
ability situation in the network domains relevant for the transport
of individual service instances. The means that can be used to
maintain up-to-date information about service quality support are
discussed in Section 8.2.2. Policy-based management is one way of

implementing control of service quality instantiation, others being
discussed further below.
On an architectural level, at least the following schemes are pos-
sible to implement end-to-end support for service quality when
multiple transport domains (ADs) are involved:
• Oneormoreserviceproviderstakecareofprovidingtrans-
port resources for their own services, where transport resources
may be under control of separate transport operators. The trans-
port operators may obviously be used by other parties as well.
TheprovisioncanbeSLA-based.Thisisoneofthescenarios
analysed in the ETSI EP TIPHON QoS control reference model
[TIPHON-3].
• Separate per-element entities handle dynamic service quality con-
trol based on transport service quality support resource availabil-
ity. This is the bandwidth broker model analysed in [RFC2638,
Sch98, THD99], to name but a few sources.
• Hybrid model. In this approach, bandwidth brokers are used by
providing up-to-date service quality support resource availabil-
ity information to service providers.
The two first models are illustrated in Figure 8.1 and Figure 8.2.
Note that in the first case, the correspondence between service
providers and transport domain does not need to be one-to-many.
254 MECHANISMS FOR DYNAMIC SERVICE QUALITY CONTROL
Transport
domain 1
Transport
domain 2
Service domain
End system End system
Figure 8.1 An example of end-to-end provisioning on service layer

Note
: The media stream requiring service quality support is drawn in the
thick line, signalling of end systems with service domain in the thin solid line,
and interaction of service provider with transport domains in the dotted
thin line
Transport
domain 1
Transport
domain 2
End system End system
BB BB
Figure 8.2 An example of end-to-end provisioning performed by
per-domain bandwidth brokers (BB)
Note
: The communication to bandwidth broker and between bandwidth
brokers is drawn in solid thin lines, communication of BBs with transport
domains in dotted thin lines, and user traffic in the thick black line
Regarding the two basic scenarios, the present chapter is primar-
ily concerned with service-independent resource management. As
was mentioned in the previous chapter, it is also possible to make a
link between bandwidth broker-type entity and service admission
control. We shall discuss this topic further in Section 8.2.4.
Let us next have a look at existing studies on bandwidth bro-
kers, and then formulate a generic framework for application of
bandwidthbrokerinthecontextof multi-service DiffServ network
domains. The present chapter will be concluded with a summary.
8.1 PREVIOUS STUDIES
Other bandwidth broker architecture models have been studied in
the TEQUILA project [TAP + 01], the AQUILA project [MNV02],
8.1 PREVIOUS STUDIES 255

the GARA Application Programming Interface (API) model
[SAF + 01] and other sources [JC01], to give examples. The
technology repertoire analysed in these studies includes SLS
negotiation, DiffServ, and MPLS. For the purposes of the present
book, we will concentrate on intra-domain and inter-domain
resource management in DiffServ specifically. MPLS is considered
to be a traffic engineering technique that is used by the policy
management to optimize the resource usage within a network
domain, and as such is not directly related to bandwidth brokers.
The information supplied by the bandwidth broker, of course, can
be used by the policy management system as input in optimizing
the domain resources.
In what follows, the IETF two-bit DiffServ architecture, the
QBone bandwidth broker architecture, and Schel
´
en’s funnel
concept are discussed.
8.1.1 Two-bit DiffServ architecture
The “two-bit” DiffServ architecture described in [RFC2638] has
been designed to support two service models, namely the “assured
service” and “premium service”. The two-bit architecture basically
accommodates both EF PHB and AF PHB groups within the same
DiffServ network domain. The assured service, akin to the AF
PHB group, provides statistical guarantees for in-profile traffic.
The second service model, EF-like, is based on prioritization of
“premium” flows with respect to other traffic in the network. In
accord with the DiffServ framework, both service models make use
of traffic conditioning at the edge of the domain. Thus, the two
services are not in contrast with the AF and EF PHBs reviewed in
earlier chapters.

Implementing both services requires configuration of appropri-
ate filters at the edge of the network to correspond to the required
services. Referring to a case of a company with multiple users,
the authors of [RFC2638] propose a bandwidth broker as an entity
into which organizational policies can be configured, and which
can use these – together with the knowledge of existing connec-
tions – to make classification decisions for service instantiations.
The reference model is based on requesting the decision for new
flows from the bandwidth broker.
The function of a bandwidth broker – as defined in [RFC2638] – is
twofold:
256 MECHANISMS FOR DYNAMIC SERVICE QUALITY CONTROL
• Keep track of traffic allocations in the domain the resources
of which it is responsible for; and configure edge routers ac-
cordingly.
• Manage resource allocation messages sent to other domains.
Related to the first of these tasks, a bandwidth broker is responsi-
ble for receiving and authenticating resource allocation requests,
each consisting of service type, target rate, maximum burst size,
and of time period for the service. For admitted requests, network
elements may need to be configured in the domain the bandwidth
broker is responsible for, or a bandwidth broker in another domain
may need to be contacted. In [RFC2638], it is suggested that per-
flow configurations in edge routers be of soft-state type – that
is, they need to be refreshed periodically in order to stay valid.
The bandwidth broker concept of [RFC2638] has been used in the
QBone bandwidth broker architecture, which is our next topic.
8.1.2 Bandwidth broker in QBone architecture
The QBone architecture [THD99, QBA02], aimed at being a basis
for bringing service quality support to the Internet, has been dis-

cussed several times in the previous chapters. The architecture
is based on DiffServ, and subsequently the following goals and
constraints for intra- and inter inter-domain QBone resource man-
agement solution have been put forth:
• Aggregation of flows into aggregates (basic DiffServ principle).
• The minimum requirement for interoperation between operators
is capability of making bilateral SLAs.
• The flexibility for per-domain resource management should be
maximized.
The target has been to make the inter-domain resource manage-
ment scheme of QBone consistent with the DiffServ approach. The
QBone bandwidth broker, in general, can interface to different
types of network elements, including other bandwidth brokers,
routers, application servers, end systems, and network operators
[QBB02]. The interfaces are illustrated in Figure 8.3.
The second boundary condition for the QBone inter-domain solu-
tion is the set of services provided. The flagship service is the QBone
Premium Service (QPS). An instantiation of QPS requires a number
8.1 PREVIOUS STUDIES 257
Inter-domain
Adjacent BBAdjacent BB
Application
server
Network
operator
Edge router(s) Edge router(s)
User/host
Intra-domain
User/App
iface

Data
store
Routing
info
NMS
iface
PM
iface
‘‘Simple’’
policy
services
Figure 8.3 The interfaces and internal structure of a QBone bandwidth
broker  Internet2 QBone
Source
: From [QBB02]
of parameters to be specified between the service providers and the
customers. The parameters are:
• start and end times;
• source and destination;
• MTU size;
• peak rate.
The following unidirectional guarantees are provided to service
instances using QPS service quality support:
• No loss due to congestion.
• No latency guarantees.
• Worst-case jitter bounds (IPDV) except in the case of IP rout-
ing changes.
The above guarantees can be implemented by providing sufficient
resources for all momentary QPS aggregate loading situations on
all links, but allowing for queueing in routers.

In the QBone parlance, a bandwidth broker is a recommended
entity (“oracle”), responding to admission requests for network
258 MECHANISMS FOR DYNAMIC SERVICE QUALITY CONTROL
resources in a QBone domain. These requests, called Resource
Allocation Requests (RARs), may be made by an element from
the domain under the control of the bandwidth broker in question,
or by a peer bandwidth broker. The bandwidth broker responds
to RARs with a Resource Allocation Answer (RAA), constituting
either a confirmation or denial of the request.
Specifically, it is the task of a QBone bandwidth broker to make
sure that the SLSs with peering QBone domains are fulfilled. Track-
ing the admitted connections and SLSs established with peering
domains are identified as means of accomplishing this task. The
possibility of involving policy decision and enforcing points in the
process is mentioned.
An admitted service instance may lead to a need to reconfigure
policing rules in boundary routers of neighbouring domains. An
example of allowing temporarily 10 Mbit/s of traffic instead of
1 Mbit/s is given. Further, the possibility of making traffic con-
ditioning dependent on routing is mentioned. Presumably band-
width broker is a seen of a technology enabler for dynamic polic-
ing in this context.
Three protocol interface classes are discussed:
• User/application protocol. This interface carries the RAR and RAA
messages. Requests can be performed by humans, or are carried
between automatic systems using a protocol such as RSVP.
• Intra-domain protocol. This is used for element configuration.
COPS, Diameter, SNMP, and vendor-proprietary interfaces are
listed as examples of protocols for this interface.
• Inter-domain protocol. Bandwidth broker peering makes use of

this interface.
Relevant data interfaces include:
• Interface to routing tables. The bandwidth broker needs to know
the up-to-date routing topology of the DiffServ domain to be
able to handle resource management. Routing may change for
the reasons discussed in Chapter 4 and Chapter 5.
• Interface to data repository. Data stored in the repository
include SLS information, reservations, router configurations,
service/service quality support aggregate mappings, NMS
information, monitoring information, and other policy interface.
In the draft QBone bandwidth broker architecture outline [QBB02],
two implementation phases of bandwidth broker have been
8.1 PREVIOUS STUDIES 259
described: phase 0 and phase 1. These will be described in
the following.
8.1.2.1 Phase 0 bandwidth broker
End-to-end service level assurance in the architecture correspond-
ing to Phase 0 is based on static SLSs between neighbouring QBone
domains. A phase 0 bandwidth broker does not perform signalling
to peer brokers in other QBone domains. Between the network
elements and the bandwidth brokers of the source and destina-
tion domain, a protocol for performing RAR/RAA signalling is
assumed. This protocol can also be of non-automated form, for
example, a telephone call to a human responsible for resource
allocation of the domain.
The end-to-end resource management is proposed to be handled
by a Bandwidth Czar, to which/whom traffic demand matrix is
communicated by per-domain bandwidth brokers – by their oper-
ating system running on carbon or silicon hardware. The Czar
makes appropriate requests for resources in transit domains.

At minimum, phase 0 bandwidth broker does not differ very
much from “statically” provisioned network domain with SLAs
towards the end users and peer domains. Resource management
can be taken care of with the basic assumption of static SLAs, and
handling momentary bandwidth needs as special requests.
There may be a direct protocol such as RSVP used between
the communication endpoints, but it is not assumed to affect the
transit domain along the path of the service instance.
8.1.2.2 Phase 1 bandwidth broker
Phase 1 bandwidth broker addresses two new questions: that
of automated communication between peer bandwidth brokers
on the one hand, and that of performing automated end-to-end
reservation set-up. The latter also includes the task of setting up
adequate service quality support in access networks.
In Phase 1, SLSs are assumed to be already established – pair-
wise – between DiffServ domains that are participating in the
phase 1 bandwidth broker scheme. Dynamic SLS negotiation was
defined to be outside of the description of the functions of basic
bandwidth broker. Bandwidth brokers are assumed to be able to