Side_1_360

the technical level. Means for negotiating and
documenting terms in the SLAs/SLSs can be
provided by the management systems. There-
fore, an actor would likely eventually implement
the required functionality in these systems. A
potential architecture is outlined in Figure 2.

3 Issues on IP Level

3.1 Operating IntServ over DiffServ

Networks

The IntServ model contains means for providing
guaranteed service levels. However, the so-
called scalability problem of IntServ is a main
disadvantage. DiffServ has therefore been pro-
moted, in particular in the core network where
the number of flows is high. Then IntServ might
be applied in the access network, in combination
with DiffServ in the core portion. In order to still
support end-to-end service delivery, providing
IntServ across the DiffServ portion has to be
promoted. A framework for this is presented in
[RFC2998].

IntServ-based services are implemented by net-
work elements, likely to be understood as
routers. However, a DiffServ network “cloud”
could also be seen as such a network element.
IntServ contains the service classes and ways of
quantifying resource requirements and deciding
upon the availability of the requested resource
in the network element (admission control). In

order to convey this information between the

network elements, RSVP has been suggested (as

one candidate). In contrast to the per-flow identi-

fication used in IntServ (and RSVP), DiffServ

applies a more coarse set of flows, based on the

DSCP in the IP packet header. This is known

as Behaviour Aggregate (BA) classification. In

each DiffServ router packets are given a treat-

ment called Per-Hop Behaviour (PHB) accord-

ing to the DSCP. As DiffServ avoids per-flow

processing and state information, it is said to

scale better than IntServ. RSVP can then refer

to aggregates.

Combining IntServ/RSVP and DiffServ can

bring some benefits compared to “pure” Diff-

Serv. One example is that admission control can

be applied at the border of the DiffServ domain.

Explicit signalling per flow allows for admission

control, e.g. of the EF class such that the flows

in that class receive the service level expected.

Voice conversations are examples where admis-

sion control could be fruitful to ensure that the

ongoing conversations get the service level and

additional conversations are rejected in case

there is not sufficient network resources.

As explicit signalling per flow is used, policy-

based control, e.g. per user and per application

can be introduced in a more dynamic way.

Moreover, if the router in the network marks the

packets, e.g. based on MF, signalling can be

Figure 2 Potential architec-

ture for managing IP-based

services, from [Asga01 ]

Monitoring

Port

SLS

invocation

Data

Transmission

Interdomain

SLS

SLS

invocation

Traffic

Conditioning

Traffic

Forecast

SLS

Subscription SLS

Subscription

SLS

Monitoring Node

Monitoring

Network

Monitoring

Dynamic

Route Mgt.

Routing

Per Hop

Behaviour

Network

Dimensioning

Dynamic

Resource Mgt.

Policy

Consumer

Policy

Mgt. Tool SLS Storing

Service

“Data Plane”

“Control Plane”

“Management Plane”

Customer/ISP

Data Plane

Customer

Policy

Management

Port

SLS Management

Port

Traffic

Engineering Port