Side_1_360

Two service classes are described in addition to

the best effort class; Controlled Load [RFC2211]

and Guaranteed Service [RFC2212]. An objec-

tive of the Controlled Load (CL) class is to offer

low average delay and limited loss. It is intended

to offer roughly the same service (e.g. through-

put, delay, loss) independent of the network

load. Thus, if a flow is accepted for the CL ser-

vice, the routers are supposed to make a commit-

ment to offer a flow service level equivalent to

that seen by a best-effort flow on an unloaded

network. The CL class supports applications that

can tolerate a small amount of delay and loss

(e.g. adaptive real-time services). The Guaran-

teed Service (GS) class offers a quantifiable

bounded queuing delay and no loss and is in-

tended for real-time applications with stringent

timing requirements.

In order to provide the requested service class to

an application, information on class (and corre-

sponding parameters) has to be conveyed to a

network element (e.g. a router). Signalling (e.g.

Resource Reservation Protocol, RSVP) can be

used to create and maintain the required flow-

specific states in network elements allowing

them to provide the requested services. Introduc-

ing such control activities allows for additional

mechanisms related to resource handling. These

are depicted in Figure 19.

Prior to transferring “user” data a signalling

sequence has to be carried out (optionally, this

could also be done by management operations or

as a combination). Upon arrival of a request (e.g.

RSVP_PATH message) a router would check its

current load/configuration to decide whether or

not the request can be served (done by the

admission control). In case the request can be

served, a corresponding message is passed on

to the next element. When the request has made

the whole path (between the two end points),

an “acknowledge” message (e.g. RSVP_RESV

message) is returned if all required resources are

available. When such a message arrives at a net-

work element, the resources are reserved imply-

ing that the units depicted as part of the IP For-

warding module in Figure 19 are properly con-

figured. Information in the admission control

could also be updated. Then “user” data can be

transferred (having the specified Multi-Field

class) and being served as notified by the sig-

nalling activities.

IntServ nodes support the required performance

guarantees by implementing multiple queues per

output port in combination with scheduling and

buffer management. Typical mechanisms are

Weighted Fair Queuing (WFQ) scheduling and a

Random Early Detection (RED) variant for con-

gestion avoidance as described in Chapter 2.

A key feature of the IntServ model is that re-

sources are explicitly managed; by resource

reservation and admission control. According

to [RFC1633] traffic control is implemented by

the packet scheduler, the classifier, admission

control and the reservation setup protocol:

• Packet schedulermanages forwarding of flows
  by use of buffering and scheduling algorithms.
  Policing is taken care of by the scheduler.


• Classifiermaps each incoming packet to a
  class (all packets in the same class get the
  same treatment from the scheduler). A class
  is an abstraction that may be local to a router;

Figure 19 Schematic
illustration of an IntServ
router, adapted from
[RFC1633]

Function block Ingress router Interior router Egress router

MF classification X

BA classification X X X

Meter X X

Marker X X

Policer/Dropper X

Shaper X X

Signalling X X

Table 1 Example of use of
the function blocks related to
DiffServ

• 
  


• •

Signalling

Module

Admission

Control

Routing

Module

MF

Classifier

Buffer Management

Scheduler

IP Forwarding module