Side_1_360

a node may use it to index the corresponding
reservation state. Thus, when MPLS and RSVP
are combined, the definition of a traffic flow can
be made more flexible. Compared to an ordinary
RSVP way of identifying a flow, more general-
ity can be obtained when MPLS is also consid-
ered. Then, the ingress node of an LSP can use a
variety of means to determine which packets that
are assigned to a particular label. After assigning
a label to a set of packets, the label may identify
a flow. The actual packets within the flow are
“hidden” for intermediate nodes. Hence these
nodes do not need to be aware of which flows
(sources, destinations, applications, etc.) that are
placed into the LSP.

The setup protocol uses downstream on-demand
label distribution. That is, a request introduces
an LSP and assigns a label. This is initiated by
an ingress node using the RSVP PATH message,
see Figure 26. In order to allow this, the PATH
message is augmented with a Label_request
field. The labels are allocated downstream and
distributed (propagated upstream) by the RSVP
RESV message (augmented with a Label field).
In order to complete the handling of LSPs, pro-
cedures for label allocation, distribution, binding
and stacking have to be devised. Moreover, the
concepts of strict and loose routes and abstract
nodes enhance the way of handling LSPs. Five
new fields (objects) are introduced in order to
handle LSPs with RSVP; Label, Label_request,
Explicit_route, Record_route and Session_att-
ribute. In addition, some changes are also seen
for the fields Session, Sender_template,
Filter_spec and Flowspec.

A key advantage using RSVP to establish LSPs
is that allocation of resources along the path is
possible. Resource reservation, however, is not
mandatory. Such LSPs without resource reserva-
tions can be used for example to carry best effort
traffic. They can also be used in many other con-
texts, including implementation of fallback and
recovery policies under fault conditions, and so
forth.

Using explicitly routed LSPs, a node at the

ingress edge of an MPLS domain can control the

path through which traffic traverses from itself,

through the MPLS domain, to an egress node.

Explicit routing can be used to improve the utili-

sation of network resources and enhance traffic

oriented performance characteristics.

Explicitly routed label switched paths can be

generalised through the notion of abstract nodes.

An abstract node is a group of nodes whose

internal topology is opaque to the ingress node

of the LSP. An abstract node is said to be simple

if it contains only one physical node. Using this

concept of abstraction, an explicitly routed LSP

can be specified as a sequence of IP prefixes or

a sequence of Autonomous Systems.

The signalling protocol model supports the spec-

ification of an explicit path as a sequence of

strict and loose routes. The combination of

abstract nodes and strict and loose routes sig-

nificantly enhances the flexibility of path defini-

tions.

Utilising the combinations of RSVP, MPLS and

DiffServ is described in [RFC2430].

7.2 Label Distribution Protocol

The Label Distribution Protocol (LDP) is de-

fined for distribution of labels within an MPLS

domain. Hence, RSVP could replace this proto-

col. Introducing constraint-based routing, Con-

straint-based Routing LDP (CR-LDP), extends

the information used when setting up paths

beyond what is available for the routing proto-

col. The idea is that the LSP will then be better

suited to serve the traffic flows. Explicit routing

can be said to be a subset of the more general

constraint-based routing, as the constraint actu-

ally gives the route [ID_crldp].

CR-LDP is a simple, scalable, open, non-propri-

etary traffic engineering signalling protocol for

MPLS IP networks. CR-LDP provides mecha-

nisms for establishing explicitly routed LSPs

in an MPLS network, as depicted in Figure 27.

incoming traffic

egress

ingress

LER A

LSR B

LSR C LER D

path message LSP

(B, C, D)

resv message

(label 7)

path message

(C, D)

resv message

(label 3)

path message

(D)

resv message

(label 5)

Figure 26 Illustration of LSP

set-up by using RSVP