Side_1_360

RSVP-based
As a general signalling protocol, RSVP may
carry most of the data needed for admission con-
trol, including characteristics of the traffic flow
(see Section 7.1) as well as information about
the users/port numbers.

Initiating the RSVP messages by the end sys-
tems, the traffic handling mechanisms may be
co-ordinated dynamically along the relevant
data path. In some places this is referred to as
dynamic topology-aware admission control.

RSVP is used by an end system to request spe-
cific service levels from the network for particu-
lar traffic flows. Routers also apply RSVP to
forward requests to all nodes along the path(s)
of the flows and to establish and maintain state
to provide the requested service. Hence, RSVP
requests will generally result in resources being
reserved in each node along the path. RSVP
allows users to obtain preferential access to net-
work resources, under the control of an admis-
sion control mechanism. Such admission control
is often based on user or application identity;
however, it is also valuable to provide the ability
for per-session admission control. In order to
allow for per-session admission control, it is
necessary to provide a mechanism for ensuring
that an RSVP request from an end system has
been properly authorized before allowing the
reservation of resources. In order to meet this
requirement, there must be information in the
RSVP message, which may be used to verify the
validity of the RSVP request. An example is to
have an authorization element assigned to the
user, which can be inserted in the RSVP mes-
sages.

Policy and Bandwidth Broker-based
Policy and Bandwidth Broker (BB) is described
in [Jens01a]. Although RSVP supports the abil-
ity to convey requests allowing for resource
reservations, an essential feature may be miss-
ing. This feature is the ability of network man-

agers and service providers to monitor, control,

and enforce the use of network resources and

services based on policies derived from criteria

such as the identity of users and applications,

traffic/bandwidth requirements, security consid-

erations, and time of day/week. A framework for

policy-based control over admission control is

described in [RFC2753].

Implicit Admission Control/Local Probing

The local probing approach relies on generating

test packets (probes) to check whether or not a

new traffic flow can be set up. The probes may

be generated by the end systems. In case several

service classes are offered, it is to be decided if

the probes should be sent in the same class as the

following traffic flow or in another class (e.g.

the lower service class). Hence, the local probing

may be suitable for DiffServ. An advantage of

this method is that no changes are needed in the

routers not generating probes. This has also been

referred to as distributed admission control, see

e.g. [Kell00].

Probing results may also be based on marking

(e.g. using ECN) of ongoing traffic flows. Hence,

information on the marking tells the admission

control algorithm whether or not a new traffic

flow with certain characteristics can be served.

A common feature of implicit admission control

is that no per-flow state information is needed,

which may also be run in the end systems. How-

ever, remembering the connectionless nature of

IP, and if the routers are not taking part in the

control, it may be uncertain whether all packets

in the traffic flow actually traverse the same

path. This means that some mid-flow packets

may well experience other conditions than the

information estimated from probes if they are

transferred on another path.

The different schemes for admission control may

be combined. For example, an implicit admis-

sion control may be used in the access network

Figure 12 Illustration of

features related to admission

control (by the network)

policy data (user,

application, network, etc.)

resource

management

(resource state

overview)

admission control

monitoring

signalling

routing

buffer

classifying management scheduling

shaping

policing

request/response

(flow characteristics, etc.)

initiator

request/response

(flow characteristics, etc.)