Download Chapter 7: Label Distribution Protocols

Chapter 7:
Label Distribution Protocols
TOPICS
–  LDP
–  CR-LDP –  RSVP
–  RSVP-TE
Connection-Oriented Networks - Harry Perros
1
•  MPLS requires a set of procedures for the
reliable distribution of label bindings
between LSRs.
•  MPLS does not require a single label
distribution protocol.
•  LDP/CR-LDP and RSVP-TE are the most
popular label distribution protocols
Connection-Oriented Networks - Harry Perros
2
The Label Distribution Protocol (LDP)
TOPICS:
- Label spaces, hello adjacencies and sessions
- LDP PDU format - LDP messages and formats
Connection-Oriented Networks - Harry Perros
3
LDP peers
•  Two LSRs that use LDP to exchange labels
and FEC mapping information are known as
LPD peers.
•  Two LDP peers exchange information over
an LDP session.
•  Several different LDP messages have been
defined.
Connection-Oriented Networks - Harry Perros
4
LDP messages
•  Four categories of messages have been
defined, namely:
–  Discovery messages
–  Session messages
–  Advertisement messages
–  Notification messages
Connection-Oriented Networks - Harry Perros
5
•  Discovery messages provide a mechanism whereby
LSRs indicate their presence by sending a hello
message periodically.
•  Session messages are used to establish, maintain,
and terminate an LDP session
•  Advertisement messages are used to create, change,
and delete label mappings to a FEC.
•  Notification messages are used to provide advisory
information and to signal error information.
Connection-Oriented Networks - Harry Perros
6
Forward Equivalent Class (FEC)
•  Each FEC comprises one or more FEC elements.
•  Each FEC element identifies a set of packets
which may be mapped to the corresponding LSP.
•  FEC element: Address prefix –  This is the most common type of FEC. It is an address
prefix of any length from 0 to a full address that
represents an IP subnet.
•  FEC element: Host address
–  This type is a full host address. When the traffic is
destined to a specific host, an LSP can be created for
that host address FEC. Connection-Oriented Networks - Harry Perros
7
Label space
•  The label space is the set of all labels.
•  There is a common label space for all
interfaces where IP packets carry the shim
header (i.e. POS, GbE interfaces), known as
per platform label space.
Connection-Oriented Networks - Harry Perros
8
LDP identifiers
•  This is a six-byte quantity and it is used to identify
the LSR label space
–  The first four bytes carry a globally unique value
identifying the LSR, such as a 32-bit router id that has
been assigned to the LSR by the AS administrator.
–  The last two octets identify a label space. If the label
space is per platform, then the last two octets are set to
zero.
•  An LDP id (often referred to as a label space id) is
expressed as <LSRid: label space number>
Connection-Oriented Networks - Harry Perros
9
LDP sessions between two non-directly connected LSRs.
•  An LDP session maybe desirable between two
non-directly connected LSRs.
•  For instance, two distant LSRs, LSRa and LSRb,
may communicate via an LSP. Label stacking is
used as well. LSRa can establish a session to
LSRb to exchange labels which are pushed down
the stack, per example in MPLS presentation
Connection-Oriented Networks - Harry Perros
10
LDP sessions
•  An LDP session is set-up between two
directly connected LSRs, to support the
exchange of LDP messages between them.
•  An LDP session between two LSRs is
associated with a label space.
Connection-Oriented Networks - Harry Perros
11
LDP runs over TCP/UDP
•  For reliability, an LDP session runs on top
of TCP. When multiple LDP sessions are
required between two LSRs, there is one
TCP session of each LDP session.
•  LDP discovery messages (i.e., hello
messages), however, run over UDP.
Connection-Oriented Networks - Harry Perros
12
LDP discovery
•  This is a mechanism that enables an LSR to
discover potential LPD peers, i.e., other
LSRs, which are directly connected to it.
•  An LSR sends periodically LDP link hellos
out of each interface. Hello packets are sent
over UDP addressed to a well-known LDP
discovery port for the “all routers on this
subnet” group multicast address.
Connection-Oriented Networks - Harry Perros
13
•  An LDP link hello sent by an LSR carries the
LDP id for the label space the LSR wants to use
for the interface, and possibly additional
information. •  Receipt of an LDP link hello identifies a hello
adjacency.
For each interface, there is one hello adjacency.
Connection-Oriented Networks - Harry Perros
14
Extended discovery mechanism
•  This is used for non-directly connected
LSRs.
•  An LSR periodically sends LDP targeted
hellos to a specific address, over UDP.
•  Receipt of an LDP targeted hello identifies a
hello adjacency.
Connection-Oriented Networks - Harry Perros
15
Establishing an LDP session
•  The exchange of LDP link hellos between two
LSRs, triggers the establishment of an LDP
session.
•  Single link between two LSRs: single hello
adjacency and a single LDP session.
•  Parallel links with per platform label space: as
many hello adjacencies as the number of links,
but one LDP session.
Connection-Oriented Networks - Harry Perros
16
•  The establishment of an LDP session involves
the following steps:
–  First, a TCP session is established.
–  Then, an LDP session is initialized, during which
the two LSRs negotiate session parameters, such
as: protocol version, label distribution method,
timer values, etc.
Connection-Oriented Networks - Harry Perros
17
Maintaining hello adjacencies
•  An LSR maintains a timer for each hello
adjacency, which it restarts each time it
receives a hello message.
•  If the timer expires without receiving a
hello message from the peer LSR, the hello
adjacency is deleted. If all hello adjacencies
associated with an LDP session are deleted,
the LDP session is terminated. Connection-Oriented Networks - Harry Perros
18
Maintaining LDP sessions
•  An LSR maintains a keepAlive timer for
each peer session.
•  The timer is reset each time it receives an
LDP PDU (any PDU) from its LDP peer. If
the LDP peer has nothing to send, it sends a
keepAlive message.
Connection-Oriented Networks - Harry Perros
19
LDP PDU format
LDP header
LDP message 1
. . .
LDP message N
Connection-Oriented Networks - Harry Perros
An LDP PDU
consists of an
LDP header
followed by one
or more LDP
messages, which
may not be related
to each other.
20
The LDP PDU header
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Version
PDU length
LDP identifier
Version: LDP protocol version (currently version 1)
PDU length: Total length in bytes excluding the version and PDU length
fields. Maximum = 4096 bytes
LDP identifier (label space id): <32-bit router id, label space number>
Connection-Oriented Networks - Harry Perros
21
LDP messages
•  Each LDP message consists of a header
followed by mandatory and optional
parameters. •  The header and the parameters are all
encoded using the type-length-value (TLV)
scheme.
Connection-Oriented Networks - Harry Perros
22
TLV structure
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
U
F
Type
length
. . .
Value
•  U: Unknown TLV bit. .
–  It is used when an unknown TLV is received. If U=0, a notification is returned to the
message originator and the entire message is ignored. If U=1, the TLV is silently
ignored and the rest of the message is processed as if the TLV did not exist
• 
F: Forward unknown TLV bit. –  This bit applies only when U=1, and the LDP message containing the unknown TLV
has to be forwarded. If F=0, the unknown TLV is not forwarded with the rest of the
message. If F=1, the unknown TLV is forwarded with the rest of the message
Connection-Oriented Networks - Harry Perros
23
TLV structure (continued)
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
U
F
Type
length
. . .
Value
•  Type: Encodes how the value field is to be interpreted
•  Length: Specifies the length of the value field in bytes
•  Value: Contains information which is interpreted as specified in the type field. It may contain TLV encoding itself!
Connection-Oriented Networks - Harry Perros
24
LDP messages
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
U
Message type
Message length
Message ID
Mandatory parameters
Optional parameters
U: Unknown message bit. Upon receipt of an unknown message, if U=0, a notification is returned to the message originator. If U=1, the unknown message is silently ignored.
Message type: Identifies the type of message
Message length: Total length in bytes of message ID field and the mandatory and optional parameters fields
Message ID: A 32-bit value used to identify this message. Subsequent messages related to this one have to carry the same message ID.
Connection-Oriented Networks - Harry Perros
25
LDP messages:
• 
• 
• 
• 
• 
• 
Notification
Hello
Initialization
KeepAlive
Address
Address withdraw
Connection-Oriented Networks - Harry Perros
• 
• 
• 
• 
• 
Label mapping
Label request
Label abort request
Label withdraw
Label release
26
Notification message
•  It is used to inform an LDP peer of a fatal error or
to provide advisory information re. the outcome of
processing an LDP message or the state of an LDP
session. Some of the notification messages are:
–  Malformed PDU or message
–  Unknown or malformed TLV
–  Session KeepAlive timer expiration
–  Unilateral session shutdown
–  Initialization message events
–  Events resulting from other errors
Connection-Oriented Networks - Harry Perros
27
Hello message
•  LDP hello messages are exchanged for
discovering LDP adjacencies.
•  Hello messages maybe either link hellos or
targeted hellos.
•  The message type field in the LPD PDU
header indicates it is a hello message. Connection-Oriented Networks - Harry Perros
28
Hello message structure
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0
Hello (0x0100)
Message length
Message ID
Common hello parameters TLV
Optional parameters
Connection-Oriented Networks - Harry Perros
29
Common hello parameters TLV
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0
0
Common hello parameters
Hold time
length
T
R
Reserved
•  Hold time: –  It specifies the hello hold time in seconds. This is the time that the
the sending LSR will maintain its record of hellos from the
receiving LSR without receipt of another hello.
–  If hold time=0, then the defaulted value is used, which is 15 sec
for link hellos and 45 sec for targeted hellos. A value of 0xffff
means infinite.
–  The hold timer is reset each time a hello message is received. If it
expires before a hello message is received, the hello adjacency is
deleted.
Connection-Oriented Networks - Harry Perros
30
Common hello parameters TLV (Continued..)
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0
0
Common hello parameters
Hold time
length
T
R
Reserved
•  T: –  It specifies if it is a targeted hello (T=1) or a link hello (T=0).
•  R: –  This field is known as the request send targeted hellos. A value of
1 indicates that the receiver is requested to send periodic targeted
hellos to the source of this hello. A value of 0 makes no such
request.
Connection-Oriented Networks - Harry Perros
31
Initialization message
•  This is the most complex LDP message, and
it is used to request the establishment of an
LDP session.
•  Several important parameters are specified in
this message.
Connection-Oriented Networks - Harry Perros
32
Initialization message structure
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0
Initialization (0x0200)
Message length
Message ID
Common session parameters TLV
Optional parameters
Connection-Oriented Networks - Harry Perros
33
Common session parameters TLV
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0
0
Common session parameters
KeepAlive time
Protocol version
A
D
Reserved
length
PVLim
Max PDU length
Receiver LDP identifier
•  KeepAlive time: It indicates the maximum number of
seconds that may elapse between the receipt of two
successive LDP PDUs. The KeepAlive timer is reset each
time an LDP PDU is received.
Connection-Oriented Networks - Harry Perros
34
•  A: It indicates the type of label advertisement.
Downstream unsolicited (A=0), or downstream on
demand (A=1). •  D: It is used to enable loop detection
•  PVLim (Path vector limit): Gives the maximum
number of LSRs recorded in the path vector used
for loop detection.
•  Max PDU length: Defaulted value of the maximum
allowable length is 4096 bytes.
•  Receiver LDP identifier: Identifies the receiver’s
label space
Connection-Oriented Networks - Harry Perros
35
Address message and address withdraw message
•  Before sending label mapping and label
request messages, an LSR advertises its
interface addresses using the address
messages.
•  Previously advertised addresses can be
withdrawn using the address withdraw
message.
Connection-Oriented Networks - Harry Perros
36
Label mapping message
•  An LSR uses this message to advertise to its
LDP peers a binding of a label to a FEC.
•  The message consists of two mandatory
TLVs:
–  FEC TLV
–  Label TLV
Connection-Oriented Networks - Harry Perros
37
Label message structure
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0
Label mapping (0x0400)
Message length
Message ID
FEC TLV
label TLV
Optional parameters
Connection-Oriented Networks - Harry Perros
38
FEC TLV
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0
0
FEC (0x0100)
length
FEC element 1
...
FEC element n
•  A FEC element is one of the FECs, such as:
address prefix, host address
Connection-Oriented Networks - Harry Perros
39
Label TLVs
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0
0
Generic label
length
Label
Connection-Oriented Networks - Harry Perros
40
Label request message
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0
Label request (0x0401)
Message length
Message id
FEC TLV
Optional parameters
An LSR sends a label request message to an
LDP peer to request a binding (i.e., mapping)
for a FEC.
Connection-Oriented Networks - Harry Perros
41
An LSR may transmit a request message under
the following conditions:
–  The LSR recognizes a new FEC via the forwarding
table, and the next hop is an LDP peer, and the LSR
does not already have a mapping from the next hop for
the given FEC.
–  The next hop to the FEC changes, and the LSR does not
already have a mapping from the next hop for the given
FEC.
–  The LSR receives a label request for a FEC from an
upstream LDP peer, the FEC next hop is an LDP peer,
and the LSR does not already have a mapping from the
next hop. Connection-Oriented Networks - Harry Perros
42
The Constrained-based Routing -
Label Distribution Protocol (CR-LDP)
TOPICS
–  CR-LSP
–  CR-LSP setup procedure
–  The label request message
–  The label mapping message
–  The traffic parameters TLV
Connection-Oriented Networks - Harry Perros
43
A constrained-routed label-switched path
•  CR-LDP is a signalling protocol based on LDP. •  It is used to set-up a unidirectional point-to-point
LSP, referred to as constrained-routed labelswitched path (CR-LSP).
•  A CR-LSP is analogous to an ATM point-to-point
connection, only it is unidirectional.
•  A bidirectional LSP is setup by creating two
separate LSPs, one in each direction.
Connection-Oriented Networks - Harry Perros
44
CR-LSP
•  An LSP is set-up as a result of the routing
information in an IP network using the shortest
path algorithm. •  A CR-LSP is calculated at the source LSR based
on criteria not limited to routing information, such
as explicit routing and QoS-based routing. •  The route is then signaled to the other nodes along
the path. •  This routing technique is known as source routing.
Connection-Oriented Networks - Harry Perros
45
C
B
D
A
G
E
F
•  In this MPLS network, router A wants to set-up a CR-LDP (i.e., a
point-to-point unicast connection) to router G. •  A calculates a path through the network that – 
– 
– 
– 
may minimize the number of hops (as in LDP), or it may minimize the total end-to-end delay, or it may maximize throughput, or
path is pre-calculated to achieve load-balancing, etc.
•  It then uses CR-LDP messages to set-up the connection through the
MPLS network.
Connection-Oriented Networks - Harry Perros
46
CR-LDPs, therefore, can be used for a variety
of reasons, such as:
–  Evenly distribute traffic among links by moving
some of the traffic from highly utilized links to
less utilized links (load balancing),
–  create tunnels for MPLS-based VPNs,
–  introduce routes based on a QoS criterion, such
as minimum number of hops, minimum total endto-end delay, and maximum throughput.
Connection-Oriented Networks - Harry Perros
47
Some CR-LDP features
•  It is based on LDP, and it runs on top of TCP for
reliability. • The CR-LDP state-machine does not require
periodic refreshment. •  Strict and loose explicit routes
–  This allows the source node some degree of
imperfect knowledge about the network
topology
Connection-Oriented Networks - Harry Perros
48
•  Route pinning
–  Fixes the path through a loosely defined route,
so that it does not change when a better next
hop becomes available.
•  Specification of traffic parameters
–  The peak rate, committed rate, and service
granularity can be specified. Policers are also
used at the ingress. Connection-Oriented Networks - Harry Perros
49
•  CR-LSP preemption
–  If a route for a high-priority CR-LSP cannot be found,
existing CR-LSPs with a lower priority may be rerouted to permit the higher-priority CR-LSP to be
established.
•  Resource class
–  The network operator may classify network resources
in various ways. These classes are also known as
“colours” or “administrative groups”. When a CR-LSP
is established, the resource class it can draw from has to
be established. Connection-Oriented Networks - Harry Perros
50
LDP support
•  CR-LDP requires the following LDP messages:
–  Basic/Extended discovery messages
–  Label request message for downstream on demand with
ordered control
–  Label mapping message for downstream on demand
with ordered control
–  Notification messages
–  Withdraw and release messages
–  Loop detection (for loosely routed segments)
Connection-Oriented Networks - Harry Perros
51
CR-LSP setup procedure
•  A CR LSP is setup using downstream-on-demand
allocation with ordered control.
•  A request at an ingress LSR to setup a CR-LSP
might originate from a management system or an
application.
•  The ingress LSR calculates the explicit route
(using information provided by the management
system, or the application, or from a routing
table) and creates the label request message.
Connection-Oriented Networks - Harry Perros
52
•  The explicit route is a series of abstract nodes
(nodes or autonomous systems) carried in an ERTLV.
•  The ingress LSR sends the label request message
to the first LSR indicated in the ER-TLV.
•  The receiving LSR forwards the label request
message to the next LSR in the ER-TLV, and so
on until the message reaches the egress LSR.
•  The egress LSR returns a label mapping message
that will traverse the path in the opposite direction.
Connection-Oriented Networks - Harry Perros
53
An example of how a CR-LSP is setup
A
B
C
D
E
Label request message
Time
Label mapping
message
Connection-Oriented Networks - Harry Perros
54
The label request message
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0
Label request
Message length
FEC TLV
Message id
LSPID TLV (mandatory)
ER-TLV (optional)
Pinning TLV (optional)
Traffic TLV (optional)
Resource class TLV (optional)
Preemption TLV (optional)
Connection-Oriented Networks - Harry Perros
55
LSPID TLV
•  The LSPID is a unique identifier of a CR-LSP.
•  It is composed of the ingress LSR router ID (or any of its
own IPv4 addresses) and an CR-LSP id which is locally
unique to that LSR.
•  The LSPID is useful in –  network management.
–  it can also be used in an already established CR-LSP as a hop in an
ER-TLV
–  In CR-LSP repair
Connection-Oriented Networks - Harry Perros
56
FEC TLV
•  A new FEC element is introduced in CR-LDP to
support CR-LSPs
•  A FEC TLV with a type CR-LSP, is a CR-LSP
FEC TLV.
•  One of the other FEC TLVs introduced in LDP
may be also used.
Connection-Oriented Networks - Harry Perros
57
Explicit route TLV (ER-TLV)
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0
0
Type (0x0800)
ER-hop TLV 2
…
ER-hop TLV n
length
ER-hop TLV 1
•  One or more ER-hop TLVs can be defined Connection-Oriented Networks - Harry Perros
58
Explicit route hop TLV (ER-hop TLV)
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0
0
Type
L
length
Value //
•  Type: IPv4 prefix, IPv6 prefix, autonomous system
number, LSPID
•  Length: specifies the length of the value field
•  L bit: Set to 1, if it is a loose ER-hop, or to 0 if it is a strict
ER-hop
•  Value: A variable-length field that contains the node (or
the abstract node) that is part of the CR-LSP.
Connection-Oriented Networks - Harry Perros
59
The label mapping message
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0
Label mapping
Message length
FEC TLV
Label TLV Message id
Label request message id TLV
Traffic TLV (optional)
LSPID TLV (optional)
Connection-Oriented Networks - Harry Perros
60
Traffic parameters TLV
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0
0
length
Type (0x0810)
Flags
Frequency
Reserved
Peak burst size (PBS)
Weight
Peak data rate (PDR)
Committed data rate (CDR)
Excess burst size (EBS)
Committed burst size
Connection-Oriented Networks - Harry Perros
61
Peak rate: PDR, PBS
•  Peak rate: This is the maximum rate expressed in
bytes/second at which traffic is sent to the CRLDP. •  It is defined is terms of a token bucket P
–  The maximum token bucket size is set equal to the peak
burst size (PBS), expressed in bytes. –  The token bucket is replenished at a rate equal to the
peak data rate (PDR), expressed in bytes/sec.
Connection-Oriented Networks - Harry Perros
62
Token bucket operation
•  Initially, the token count Tp=PBS.
•  Let PDR = N bytes/sec. Then, every second the token
count Tp is incremented by N if Tp ≤PBS (It should not
exceed PBS).
•  When a packet of size B arrives, if Tp -B≥0, then the
packet is not in excess of the peak rate, and Tp = Tp -B. •  Otherwise, it is in excess of the peak rate. Tp is not
decreased. The packet is a violating packet and it can be
marked or dropped.
Connection-Oriented Networks - Harry Perros
63
Example of the peak rate token bucket operation:
PBS
Tp
time
Packet 1
Packet 2
•  Rate of arrival = PDR, packet size ≤ PBS
•  Legend:
–  Blue line: indicates the level of Tp –  Red line indicates the arrival of a packet
–  The slope of the lines is = PDR
Connection-Oriented Networks - Harry Perros
64
Rate of arrival is temporarily > PDR, packet size ≤ PBS
PBS
Tp
time
Packet 1
Packet 2
Packet 3
Packet 1 goes through because of the token count containing enough bytes
Packet 2 is not as lucky! It’ll be dropped or marked. Tp is not decreased.
Packet 3 goes through.
The token bucket mechanism permits the peak rate of the source to
exceed temporarily the PDR (like the CDVT in ATM)
Connection-Oriented Networks - Harry Perros
65
Rate of arrival ≤ PDR, but packet size > PBS
PBS
Tp
time
Packet 1
Packet 1 will be dropped or marked. Tp is not decreased.
The token bucket mechanism does not permit a packet bigger than
MBS to go through. (MBS has the same meaning as the maximum
frame size MFS in the GFR service category of ATM)
Connection-Oriented Networks - Harry Perros
66
Committed rate: CDR, CBS
•  The committed rate is the amount of bandwidth
allocated to the CR-LSP by the network.
•  As in the case of the peak rate, the committed rate
is defined by a token bucket C with parameters –  Committed data rate (CDR), expressed in bytes/sec
–  Committed burst size (CBS), expressed in bytes.
•  Token bucket C is replenished at the rate of CDR,
and its maximum size is CBS.
Connection-Oriented Networks - Harry Perros
67
Excess token bucket
•  The excess token bucket E is defined by the
parameters: –  committed data rate (CDR), expressed in bytes/sec
–  excess burst size (EBS), expressed in bytes.
•  Token bucket E is replenished at the rate of CDR
and its maximum size is EBS.
Connection-Oriented Networks - Harry Perros
68
Committed and excess token bucket operation:
•  Initially, the committed token count Tc = CBS, and the excess
token count Te = EBS.
•  Let CDR = M bytes/sec. Then, every second
–  Tc is increment by M if Tc < CBS (Should not exceed PBS).
–  Te is increment by M, if Te < EBS (Should not exceed EBS)
•  When a packet of size B arrives, if Tc-B≥0, then the packet is
not in excess of the committed rate, and Tc = Tc - B. •  Otherwise, if Te-B≥0, then the packet is in excess of the
committed rate, but not in excess of the EBS and Te = Te - B. •  Otherwise, it is in excess of both the committed rate and the
EBS, and neither Tc or Te are decremented.
Connection-Oriented Networks - Harry Perros
69
An example
EBS
Te
time
CBS
Tc
Packet 1
Packet 2
(marked)
Packet 3
Packet 3
(marked)
Connection-Oriented Networks - Harry Perros
Packet 4
(dropped)
70
Effect of the token buckets:
•  PDR > CDR and PBS < CBS, then
–  Packet may go through depending on the current
size of the committed token bucket. –  If it does not, packet may go through as marked
depending on the size of the excess token bucket •  PDR < CDR and PBS > CBS, then
–  Packet gets marked always
Connection-Oriented Networks - Harry Perros
71
Bandwidth allocation
•  How much bandwidth (i.e., committed rate)
should be allocated?
–  This problem is identical to that in ATM, where
it has been adequately addressed.
•  How big should EBS be?
–  This depends on whether the network wants to
carry marked packets and by how much. It also
may depend on the SLA between user and
network operator.
Connection-Oriented Networks - Harry Perros
72
Flags
0
1
Res
2
3
4
5
6
7
F6
F5
F4
F3
F2
F1
•  Six flags are defined:
– 
– 
– 
– 
– 
– 
Flag F1: corresponds to the PDR
Flag F2: corresponds to the PBS
Flag F3: corresponds to the CDR
Flag F4: corresponds to the CBS
Flag F5: corresponds to the EBS
Flag F6: corresponds to the weight
•  Each flag indicates whether the value it is associated with
is negotiable or not
Connection-Oriented Networks - Harry Perros
73
Frequency
•  It specifies at what granularity the CDR allocated
to the CR-LSP is made available. The following
frequency code points have been defined:
–  0 - Unspecified
–  1 - Frequent
•  The available rate should average the CDR when measured
over any time interval equal to or longer than a small number
of shortest packet times at the CDR.
–  2- VeryFrequent
•  The available rate should average the CDR when measured
over any time interval equal to or longer than the shortest
packet time at the CDR. –  3-255: Reserved
Connection-Oriented Networks - Harry Perros
74
Weight
•  It indicates the weight of the CR-LSP. It is used to
determine the CR-LSP’s relative share of the
excess bandwidth.
•  Weight values are from 1 to 255.
•  0 means that weight is not applicable.
Connection-Oriented Networks - Harry Perros
75
Class services
•  Class services can be constructed by appropriately
manipulating the traffic parameters, and the token
bucket decisions re. passing/dropping/marking a
packet.
•  Below, we give several examples of different class
services
Connection-Oriented Networks - Harry Perros
76
Delay Sensitive (DS) service
•  The network commits to deliver with high probability user datagrams
at a rate of PDR with minimum delay and delay requirement.
Datagrams in excess of PDR will be discarded
•  Traffic parameters:
– 
– 
– 
– 
– 
– 
– 
PDR=user specified
PBS= user specified
CDR=PDR
CBS=PBS
EBS=0
Frequency=Frequent
Dropping action: drop>PDR
Connection-Oriented Networks - Harry Perros
77
Throughput Sensitive (TS) service
•  The network commits to deliver with high probability user
datagrams at a rate of at least CDR. The user can transmit
at a rate higher than CDR but datagrams in excess of CDR
have a lower probability of being delivered.
•  Traffic parameters:
– 
– 
– 
– 
– 
– 
– 
PDR=user specified
PBS=user specified
CDR=user specified
CBS=user specified
EBS=0
Frequency=Unspecified
Dropping action: drop>PDR, BPS, mark > CDR, CBS
Connection-Oriented Networks - Harry Perros
78
Best Effort (BE) service
•  No expected service guarantees
•  Traffic parameters:
– 
– 
– 
– 
– 
– 
– 
PDR=infinite
PBS= infinite CDR= infinite CBS= infinite
EBS=0
Frequency=Unspecified
Dropping action: none
Connection-Oriented Networks - Harry Perros
79
Frame Relay Service (FRS)
ATM-CBR
Traffic parameters:
Traffic parameters:
– 
– 
– 
– 
– 
– 
– 
PDR=user specific
PBS= user specific
CDR= CIR CBS= ??
EBS=??
Frequency=Unspecified
Dropping action: drop>PDR, PBS
mark>CDR,CBS,EBS
Connection-Oriented Networks - Harry Perros
– 
– 
– 
– 
– 
– 
– 
PDR=PCR
PBS= CDVT CDR= PCR CBS= CDVT
EBS=0
Frequency=VeryFrequent
Dropping action:
drop>PCR
80
ATM-RT VBR
– 
– 
– 
– 
– 
– 
– 
PDR=PCR
PBS= VDVT
CDR= SCR
CBS= MBS
EBS=0
Frequency=Frequent
Dropping action:
drop>PCR
mark>SCR,MBS
ATM-NRT VBR
– 
– 
– 
– 
– 
– 
– 
PDR=PCR
PBS= VDVT
CDR= SCR
CBS= MBS
EBS=0
Frequency=Unspecified
Dropping action:
drop>PCR
mark>SCR,MBS
Connection-Oriented Networks - Harry Perros
ATM-UBR
– 
– 
– 
– 
– 
– 
– 
PDR=PCR
PBS= CDVT CDR= -
CBS= -
EBS=0
Frequency=Unspecified
Dropping action:
drop>PCR
81
The Resource Reservation Protocol
(RSVP)
TOPICS
- Main features of RSVP
- Reservation styles
- Soft State
- The RSVP message format
- The Path message
- The Resv message
Connection-Oriented Networks - Harry Perros
82
Main features of RSVP
•  RSVP was designed to support the integrated
services (intserv) architecture. •  The intserv architecture was developed by IETF in
the mid 1990s with a view to introducing QoS in
the IP network. •  Intserv was never widely accepted. It has been
superceded by the DiffServ architecture, which has
been successfully deployed in the IP network.
Connection-Oriented Networks - Harry Perros
83
•  RSVP is a signaling protocol used for the
reliable establishment and maintenance of
resource reservations for both unicast and
many-to-many multicast applications •  RSVP can be used to carry other types of
control information since it is not aware of
the content of the RSVP protocol fields.
•  In view of this, it was proposed to be used
in MPLS.
Connection-Oriented Networks - Harry Perros
84
Path and Resv messages
RSVP makes use of two messages:
–  Path: This message originates from the sender
and travels to the receiver.
–  Resv: Upon receipt of the Path message, the
receiver responds with a Resv message, which
travels on the reverse path of the Path message,
and reserves bandwidth on each router along
the path.
Connection-Oriented Networks - Harry Perros
85
An example
Sender
Path
Path
Resv
Receiver
Resv
Path
Resv
Connection-Oriented Networks - Harry Perros
Path
Resv
86
The Path message
It contains the following information:
•  Phop: This is the address of the previous hop
RSVP-capable router that forwards the message.
This address is stored in the path state information
at each node, and it is used to send the reservation
message Resv upstream towards the sender. • Sender template: This field carries the sender’s IP
address and optionally the UDP/TCP sender port.
Connection-Oriented Networks - Harry Perros
87
•  Sender TSpec: This defines the traffic
characteristics of the data flow that the sender will
generate. •  Adspec: This carries one-pass with advertising
(OPWA) information. This is information
(advertisements) gathered at each node along the
path taken by the Path message, such as
availability of specific QoS control services. This
information is delivered to the receiver who can
use it to construct a reservation request or adjust
appropriately an existing reservation.
Connection-Oriented Networks - Harry Perros
88
The Resv message
The Resv message carries the following information:
•  Flowspec: It specifies the desired QoS, and it
consists of:
–  Receiver Tspec: A set of traffic descriptors which is
used by the nodes along the path to reserve resources
–  Rspec: It defines the desired bandwidth and delay
guarantees.
–  Service class: In intserv, the service class could be either
the guaranteed service or the controlled-load service. Connection-Oriented Networks - Harry Perros
89
•  Guaranteed service:
–  It provides firm bounds on the end-to-end
queueing delay with no packet loss for all
conforming packets
•  Controlled-load service. –  It provides QoS that closely approximates the
best effort service a user would receive from an
unloaded network. Specifically:
•  A high percentage of transmitted packets will be
successfully delivered. The packet loss should be
close to the error rate of the links.
•  The end-to-end delay of the delivered packets will
not greatly exceed the minimum end-to-end delay.
Connection-Oriented Networks - Harry Perros
90
•  Filter spec: It defines the packets that will receive
the requested QoS defined in the flowspec. A
simple filter spec could be just the sender’s IP
address and optionally its UDP or TCP port.
Connection-Oriented Networks - Harry Perros
91
•  RSVP messages are sent in raw IP datagrams
without a TCP or UDP encapsulation. (UDP
encapsulation is permitted for routers that do not
support raw IP datagrams).
•  RSVP is simplex, that is, it makes reservations for
unidirectional data flows. Therefore, in order for
two users A and B to communicate both ways, two
separate sessions have to be established; one
session from A to B, and another one from B to A.
Connection-Oriented Networks - Harry Perros
92
Reservation styles
Three different reservation schemes are
possible, based on:
1.  When multiple senders are transmitting to the
same receiver, a separate reservation for each
data flow or a single reservation for all the
data flows on a router is possible.
2.  Explicit or wildcard: The list of senders is
explicitly stated by the receiver, or it is open
to any sender.
Connection-Oriented Networks - Harry Perros
93
The following reservation schemes have
been defined:
• Wildcard-filter (WF) style • Fixed-filter (FF) style
• Shared explicit (SE) style Connection-Oriented Networks - Harry Perros
94
•  Wildcard-filter (WF) style: Any sender can
transmit to the session and there is a single
resource reservation shared by all the data
flows from all upstream senders. The
resource reservation is the largest of all
requested reservations.
Connection-Oriented Networks - Harry Perros
95
•  Fixed-filter (FF) style: A separate
reservation is made for each particular
sender specified in the explicit list of
senders. Other senders identified in the
explicit list which transmit in the same
session do not share this reservation.
•  Shared explicit (SE) style: A list of senders
is explicitly stated and there is a single
shared reservation for all their flows.
Connection-Oriented Networks - Harry Perros
96
Soft State
•  RSVP takes a soft state approach. That is,
the state information in a router has to be
periodically refreshed by Path and Resv
messages.
•  RSVP runs on top of IP which does not
guarantee delivery of packets. The soft state
approach provides the necessary reliability
in the delivery of the RSVP messages.
Connection-Oriented Networks - Harry Perros
97
The RSVP message format
•  An RSVP message consists of the common
header shown below, followed by a variable
number of objects.
Vers
Flags
Send_TTL
MsgType
Reserved
Connection-Oriented Networks - Harry Perros
RSVP checksum
RSVP length
98
MsgType: The message type is specified by a
number carried in this 8-bit field. The following
messages types and numbers have been specified:
–  Path
–  Resv
–  PathEr
–  ResvErr
–  PathTear
–  ResvTear
–  ResvConf
Connection-Oriented Networks - Harry Perros
99
The object format
2 bytes
1 byte
Class-num
Length (bytes)
1 byte
C-Type
Object contents
•  Length: A 16-bit field used to indicate the total length in bytes of the
object. It must be a multiple of 4, and at least equal to 4
•  Class-num: An 8-bit field used to identify the object class. •  C-Type: An 8-bit field used to define the object type. Connection-Oriented Networks - Harry Perros
100
RSVP objects
•  NULL: The contents of a NULL object are ignored by the receiver
•  SESSION: It contains the IP destination address, the IP protocol id, and
optionally a destination port. •  RSVP_HOP: It carries the IP address of the RSVP-capable router that
sent this message. The RSVP_HOP object is referred to as the PHOP
(previous hop) object for messages from the sender to the receiver, and
the NHOP (next hop) object for messages from the receiver to the
sender.
•  TIME_VALUES: It contains the value for the refresh period used by
the creator of the message. It is required in every Path and Resv
message.
Connection-Oriented Networks - Harry Perros
101
•  STYLE: It defines the reservation style plus style-specific
information. It is required in every Resv message.
•  FLOWSPEC: It carries the necessary information in an
Resv message to make a reservation in a router.
•  FILTER_SPEC: It defines which data packets should
receive the QoS specified in the FLOWSPEC object. It is
required in a Resv message.
•  SENDER_TEMPLATE: It defines the sender’s IP address
and perhaps some additional demultiplexing information,
such as a port number. It is required in a Path message.
•  SENDER_TSPEC: It contains the traffic characteristics if
the sender’s data flow. It is required in a Path message.
Connection-Oriented Networks - Harry Perros
102
•  ADSPEC: It carries the one-pass with advertising
information. •  ERROR_SPEC: It specifies an error in a PathErr, ResvErr,
or a confirmation in a ResvConf message.
•  POLICY_DATA: It carries information that allows a router
to decide whether a reservation is administratively
permitted. •  INTEGRITY: It carries cryptographic data to authenticate
the originating node.
•  SCOPE: It carries an explicit list of sender hosts towards
the information in the message is to be forwarded. •  RESV_CONFIRM: It carries the IP address of a receiver
that requested a confirmation. Connection-Oriented Networks - Harry Perros
103
The Path message objects
• 
• 
• 
• 
• 
• 
INTEGRITY (optional), SESSION
RSVP_HOP
TIME_VALUES
POLICY_DATA objects (optional), A sender descriptor consisting of the SENDER_
TEMPLATE and the SENDER_TSPEC
•  ADSPEC (optional).
Connection-Oriented Networks - Harry Perros
104
Procedure
•  Each sender host sends a Path message for
each data flow it wishes to transmit. •  The Path message is forwarded from router
to router using the next-hop information in
the routing table until it reaches the
receiver. •  Each router along the path captures and
processes the Path message. Connection-Oriented Networks - Harry Perros
105
•  The router creates a path state for the pair
{sender, receiver} defined in the
SENDER_TEMPLATE and SESSION
objects of the Path message. •  Any POLICY_DATA, SENDER_TSPEC,
and ADSPEC objects are also saved in the
path state.
•  If an error is encountered a PathErr message
is sent back to the originator of the Path
message.
Connection-Oriented Networks - Harry Perros
106
The Resv message objects
•  INTEGRITY (optional)
•  SESSION
•  RSVP_HOP
•  TIME_VALUES
•  RESV_CONFIRM (optional)
•  SCOPE (optional)
•  POLICY_DATA objects (optional), •  STYLE
•  A flow descriptor list
Connection-Oriented Networks - Harry Perros
107
•  The RSVP_HOP contains the NHOP, that is the IP address
of the router that sent the Resv message.
•  The presence of the RESV_CONFRIM object in the Resv
message is a signal to the router to send a ResvConf
message to the receiver to confirm the reservation. The
RESV_CONFIRM carries the IP address of the receiver. •  The flow descriptor list is style dependent. For the
wildcard-filter (WF) style the flow descriptor list consists
of the FLOWSPEC object. For the Fixed-filter (FF) and
shared explicit (SE) styles, it consists of the objects
FLOWSPEC and FILTER_SPEC. Connection-Oriented Networks - Harry Perros
108
SENDER_TSPEC contents for intserv
The SENDER_TSPEC contains the traffic
parameters: token bucket rate, token bucket
size, peak data rate, minimum policed unit
(i.e., size of smallest allowable packet), and
maximum policed unit (i.e., size of
maximum allowable packet).
Connection-Oriented Networks - Harry Perros
109
FLOWSPEC contents for intserv
When requesting the controlled-load
service, the FLOWSPEC consists of the
receiver TSpec which contains values for
the parameters: token bucket rate, token
bucket size, peak data rate, minimum
policed unit, and maximum policed unit.
These parameters are used to calculate the
resource reservation in a router.
Connection-Oriented Networks - Harry Perros
110
FLOWSPEC contents for intserv
•  When requesting the guaranteed service, the
FLOWSPEC consists of the receiver TSpec
and the Rspec which carries the parameters:
–  rate and –  slack time. •  These two parameters are used to define the
desired bandwidth and delay guarantee.
Connection-Oriented Networks - Harry Perros
111
The Resource Reservation ProtocolTraffic Engineering (RSVP - TE)
TOPICS
–  Main features of RSVP-TE
–  Service classes and reservation styles
–  The RSVP-TE new objects
–  The RSVP-TE Path and Resv messages
–  RSVP-TE extensions
Connection-Oriented Networks - Harry Perros
112
Main features of RSVP - TE
•  RSVP-TE uses downstream-on-demand
label allocation with ordered control to
setup an LSP. •  This is implemented using the Path and
Resv messages which have been augmented
with new objects. Connection-Oriented Networks - Harry Perros
113
•  An LSP can be setup using the next-hop
information in the routing table.
•  RSVP-TE can also setup an explicit route
by using a new object, called the
EXPLICIT_ROUTE, which encapsulates
the hops that make up the explicit path. •  Strict or loose routing through an abstract
node is permitted.
Connection-Oriented Networks - Harry Perros
114
Setting up an LSP - ingress node: – The ingress node sends a Path message
with a LABEL REQUEST object. This is
a new object and it indicates that a label
binding for the path is requested. – If an explicit route is requested, then the
EXPLICIT_ROUTE object will be
inserted in the Path message. Connection-Oriented Networks - Harry Perros
115
Setting up an LSP - next hop node: – The Path message is forwarded to the
next hop indicated in the routing table for
the particular IP destination address of
the receiver, or the next hop indicated in
the EXPLICIT_ROUTE object. – A node incapable of accepting the new
requested LSP sends back a PathErr
message.
Connection-Oriented Networks - Harry Perros
116
Setting up an LSP - egress node: – The egress LSR (i.e., receiver), responds
with an Resv message. – A new object called the LABEL object,
is inserted in the message which is sent
back upstream towards the sender, i.e.,
the ingress node, following the inverse
path traversed by the Path message. Connection-Oriented Networks - Harry Perros
117
Setting up an LSP - going upstream:
–  Each node that receives the Resv message with
a LABEL object uses that label for outgoing
traffic associated with the LSP. –  It allocates a new label, places it in the LABEL
object of the Resv message and sends it
upstream to the previous-hop node. –  The LSP is established when the sender
receives the Resv message. Connection-Oriented Networks - Harry Perros
118
Resource reservation
•  RSVP-TE enables the reservation of bandwidth
along an LSP using standard RSVP reservations
together with intserv service classes. •  Resource reservation is optional and LSPs can be
setup without reserving any resources. Such LSPs
can be used, for instance, to carry best effort
traffic and implement backup paths.
Connection-Oriented Networks - Harry Perros
119
Service classes
•  There is no restriction in RSVP-TE as to which
intserv service classes should be supported.
RSVP-TE, however, should support the
controlled-load service and the null service. •  The null service class is newer service class that
was introduced in RSVP in order to support RSVP
signaling for the differentiated service (diffserv)
architecture. Connection-Oriented Networks - Harry Perros
120
Reservation styles
•  Of these three reservation styles defined in
RSVP, the wildcard-filter is not used in
RSVP-TE. •  The receiver node can use the FF or SE
style for an LSP, and it can chose different
styles for different LSPs.
Connection-Oriented Networks - Harry Perros
121
The RSVP new objects
•  The following five new objects have been
introduced to support the functionality of RSVPTE:
–  LABEL
–  LABEL_REQUEST
–  EXPLICIT_ROUTE –  RECORD_ROUTE –  SESSION_ATTRIBUTE
Connection-Oriented Networks - Harry Perros
122
The LABEL object
•  Three different object types (C-Type field),
are supported namely C-Type 1, C-Type 2
and C-Type 3. •  C-Type 1 is a label request for generic
labels
•  C-Type 2 and 3 is a label request for ATM
labels and frame relay respectively.
Connection-Oriented Networks - Harry Perros
123
The LABEL_REQUEST object
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Length (bytes)
Class-num
Reserved
C-Type
L3PID
C_Type 1
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Length (bytes)
Class-num
Reserved
C-Type
L3PID
M
Res
Minimum VPI
Minimum VCI
Res
Maximum VPI
Maximum VCI
C_Type 2
Connection-Oriented Networks - Harry Perros
124
The EXPLICIT_ROUTE Object
•  This object is used to specify the hops in the
requested explicit route. •  Each hop could be a single node or a group
of nodes, referred to as an abstract node. For
simplicity, RSVP-TE refers to all the hops
as abstract nodes, with the understanding
that an abstract node could consist of a
single node.
Connection-Oriented Networks - Harry Perros
125
Sub-object for IPv4
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
L
Type
Length
IPv4 address
IPv4 address
Prefix length
Reserved
•  Common fields: L, Type, Length
–  L: 1-bit field to indicate whether the route through the
abstract node is strict or lose.
–  Type: indicates whether the address provided is IPv4,
IPv6 or autonomous system.
–  Length: Length of entire sub-object.
Connection-Oriented Networks - Harry Perros
126
The RECORD_ROUTE object
•  Loops can be detected through the
RECORD_ROUTE object. In this object the
IP address of each node along the path can
be recorded. Also, the labels used along the
path can be recorded. The RECORD_
ROUTE object can be present in both Path
and Rev messages.
Connection-Oriented Networks - Harry Perros
127
The RSVP-TE Path message
It is similar to the Path message in RSVP. It
consists of the common header followed by
objects: –  INTEGRITY (optional), –  SESSION
–  RSVP_HOP
–  TIME_VALUES
–  EXPLICIT_ROUTE (optional)
Connection-Oriented Networks - Harry Perros
128
–  LABEL_REQUEST
–  SESSION_ATTRIBUTE (optional)
–  POLICY_DATA objects (optional), –  A sender descriptor consisting of the
SENDER_TEMPLATE and the
SENDER_TSPEC
–  ADSPEC (optional).
–  RECORD_ROUTE (optional)
Connection-Oriented Networks - Harry Perros
129
The RSVP-TE Resv message
The RSVP-TE Resv message consists of the
common header followed by the objects:
–  INTEGRITY (optional), –  SESSION
–  RSVP_HOP
–  TIME_VALUES
–  RESV_CONFIRM (optional)
Connection-Oriented Networks - Harry Perros
130
–  SCOPE (optional)
–  POLICY_DATA objects (optional), –  STYLE
–  A style-dependent flow descriptor list. •  For the Fixed-filter (FF) style it consists of the
objects: FLOWSPEC, FILTER_SPEC, LABEL,
RECORD_ROUTE (optional). •  For the shared explicit (SE) style it consists of the
objects: FILTER_SPEC, LABEL,
RECORD_ROUTE (optional).
Connection-Oriented Networks - Harry Perros
131