Side_1_360

• Allow for pre-emption per class-type;


• Allow for specifying resource class affinity;


• Support mapping of DiffServ classes as when
  MPLS is not used;


• Allow dynamic adjustment of PHBs for Diff-
  Serv;


• Support multiple TE metrics, e.g. to be used
  when finding routes of LSPs.

Then a transit LSR can be seen to consist of four

functional stages (compare with Figure 23):

1. Determine the incoming PHB (i.e. which PHB
   the packet belongs to);


2. Determine the outgoing PHB (optionally with
   traffic conditioning, e.g. policing). When the
   conditioning is not present the outgoing PHB
   is equal to the incoming PHB;


3. Label swapping, i.e. from an incoming label
   to an outgoing label;


4. Coding of DiffServ information into the
   “encapsulation layer” information, e.g. Exp
   field, CLP, etc.

Suggestions for mapping between DiffServ

classes and “encapsulation layer” information

are given in [ID_MPLSdiff].

In order to establish LSPs supporting DiffServ

by signalling, the signalling protocol has to be

extended. For example, for RSVP a DiffServ

object has been defined, see [ID_MPLSdiff]. For

an E-LSP this object includes a description of

the mapping between Exp values and PHB. This

object contains the PSC for an L-LSP. Both E-

LSPs and L-LSPs can be established with band-

width reservation or without reservation. When

bandwidth is to be reserved, a TSpec field is

included in the PATH message and a Flowspec

field is included in the RESV message as de-

scribed for IntServ/RSVP.

For LDP a new TLV field (DiffServ TLV) is

described in [ID_MPLSdiff]. When a predefined

mapping is applied between Exp and PHB, use

of this field is optional. The DiffServ TLV

includes information for mapping between Exp

and PHB for an E-LSP. For an L-LSP the Diff-

Serv TLV describes the PSC supported by the

LSP. The Label request, Label mapping, Label

release and Notification messages may include

the DiffServ TLV. Bandwidth reservation may

be done by including the Traffic parameters TLV.

7 Resource Reservation

When reserving capacity for a flow (or flow

aggregate) a setup protocol can be used. An

option is to apply management-related proce-

dures for this purpose, implying that the man-

agement system could interact with the routers

instead of signalling being exchanged directly

between routers. In addition, a combination of

management and signalling procedures may also

work, for example when combining the action

with policy matters, bandwidth brokers, and so

forth.

7.1 Resource Reservation Protocol

(RSVP)

The Resource reSerVation Protocol (RSVP) is

frequently referred to when discussing reserva-

tion of resources. The signalling sequence is

illustrated in Figure 24. RSVP was designed to

enable senders, receivers, and routers of commu-

nication sessions (either multicast or unicast) to

communicate with each other in order to set up

the necessary router state to support the services.

RSVP is receiver-oriented, e.g. to overcome

scalability problems for multicast and to allow

heterogeneity for multicast.

Each RSVP-capable node handles reservation

and enforcement of traffic flows by using several

modules (see Figure 25). The modules related to

Integrated Services/RSVP in routers and hosts

are the same, but the actual implementations are

commonly different. An RSVP process on both

hosts and routers handles all the RSVP protocol

messages needed to establish reservations.

sender Intermediate receiver

PATH(.., Sender_TSpec, AdSpec, ..)

PATH(.., Sender_TSpec, AdSpec, ..)

RESV(.., Receiver_TSpec, RSpec, ..)

RESV(.., Receiver_TSpec, RSpec, ..)

Figure 24 Illustration of the
RSVP message sequence
for setup