chapter 7: label distribution protocols

Connection-Oriented Networks - Harry Perros 1

Chapter 7:��Label Distribution Protocols

TOPICS – LDP – CR-LDP – RSVP – RSVP-TE


•  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


The Label Distribution Protocol (LDP)

TOPICS: - Label spaces, hello adjacencies and sessions - LDP PDU format - LDP messages and formats


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.


LDP messages

•  Four categories of messages have been defined, namely: – Discovery messages –  Session messages – Advertisement messages – Notification messages


•  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.


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.


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.


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>


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


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.


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.


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.


For each interface, there is one hello adjacency.

•  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.


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.


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.


•  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.


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.


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.


LDP PDU format

An LDP PDU consists of an LDP header followed by one or more LDP messages, which may not be related to each other.

LDP header

LDP message N

. . .

LDP message 1


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: 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>

Version PDU length

LDP identifier


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.


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

.

Type length

Value

U F

. . .

•  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


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

•  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!

Type length

Value

U F

. . .


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

Message type Message length

Message ID

U

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.


LDP messages:

•  Notification •  Hello •  Initialization •  KeepAlive •  Address •  Address withdraw

•  Label mapping •  Label request •  Label abort request •  Label withdraw •  Label release


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


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.


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

Hello (0x0100) Message length

Message ID

0

Common hello parameters TLV

Optional parameters


Common hello parameters TLV

•  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.

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

Common hello parameters length

Hold time

0 0

T R Reserved


Common hello parameters TLV (Continued..)

•  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.

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

Common hello parameters length

Hold time

0 0

T R Reserved


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.


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

Initialization (0x0200) Message length

Message ID

0

Common session parameters TLV

Optional parameters


•  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.

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

Common session parameters length

Protocol version

0 0

D A

KeepAlive time

Reserved PVLim Max PDU length

Receiver LDP identifier

Common session parameters TLV


•  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


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.


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


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

Label mapping (0x0400) Message length

Message ID

0

FEC TLV

Optional parameters

label 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

FEC TLV

FEC (0x0100) length 0 0

FEC element 1

FEC element n

... •  A FEC element is one of the FECs, such as:

address prefix, host address


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

Generic label length 0 0

Label

Label TLVs


Label request message

An LSR sends a label request message to an LDP peer to request a binding (i.e., mapping) for a FEC.

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

Label request (0x0401) Message length 0

Message id

Optional parameters

FEC TLV


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.


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


•  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 label-switched 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.

A constrained-routed label-switched path


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.


•  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.

B

A

E

C

F

D

G


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 end-to-end delay, and maximum throughput.


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


•  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.


•  CR-LSP preemption –  If a route for a high-priority CR-LSP cannot be found,

existing CR-LSPs with a lower priority may be re-routed 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.


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)


•  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.

CR-LSP setup procedure


•  The explicit route is a series of abstract nodes (nodes or autonomous systems) carried in an ER-TLV.

•  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.


An example of how a CR-LSP is setup

Label request message

Label mapping message

Time

B A E C D


The label request message

Message id

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

Label request Message length 0

FEC TLV LSPID TLV (mandatory)

ER-TLV (optional) Traffic TLV (optional) Pinning TLV (optional)

Resource class TLV (optional) Preemption TLV (optional)


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


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.


Explicit route TLV (ER-TLV)

•  One or more ER-hop TLVs can be defined

ER-hop TLV 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

Type (0x0800) length 0

ER-hop TLV 2 …

ER-hop TLV n

0


Explicit route hop TLV (ER-hop TLV)

•  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.

Value //

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

Type length 0 0

L


The label mapping message

Message id

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

Label mapping Message length 0

FEC TLV Label TLV

Label request message id TLV LSPID TLV (optional) Traffic TLV (optional)


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

Type (0x0810) length 0

Peak data rate (PDR) Peak burst size (PBS)

Committed data rate (CDR) Committed burst size

Excess burst size (EBS)

0

Flags Frequency Reserved Weight


Peak rate: PDR, PBS

•  Peak rate: This is the maximum rate expressed in bytes/second at which traffic is sent to the CR-LDP.

•  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.


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.


Example of the peak rate token bucket operation:

time

Tp

PBS

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


Rate of arrival is temporarily > PDR, packet size ≤ PBS

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)

time

Tp

PBS

Packet 1 Packet 2 Packet 3


Rate of arrival ≤ PDR, but packet size > PBS

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)

time

Tp

PBS

Packet 1


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.


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.


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.


An example

Tc

CBS

Packet 1 Packet 2 (marked)

Packet 3

time

Te

EBS

Packet 3 (marked)

Packet 4 (dropped)


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


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.


Flags

•  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

0 1 2 3 4 5 6 7

Res F6 F5 F4 F3 F2 F1


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


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.


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


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


•  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

Throughput Sensitive (TS) service


•  No expected service guarantees •  Traffic parameters:

–  PDR=infinite –  PBS= infinite –  CDR= infinite –  CBS= infinite –  EBS=0 –  Frequency=Unspecified –  Dropping action: none

Best Effort (BE) service


Frame Relay Service (FRS) Traffic parameters:

–  PDR=user specific –  PBS= user specific –  CDR= CIR –  CBS= ?? –  EBS=?? –  Frequency=Unspecified –  Dropping action: drop>PDR, PBS

mark>CDR,CBS,EBS

ATM-CBR Traffic parameters:

–  PDR=PCR –  PBS= CDVT –  CDR= PCR –  CBS= CDVT –  EBS=0 –  Frequency=VeryFrequent –  Dropping action:

drop>PCR


ATM-RT VBR –  PDR=PCR –  PBS= VDVT –  CDR= SCR –  CBS= MBS –  EBS=0 –  Frequency=Frequent –  Dropping action:

drop>PCR mark>SCR,MBS

ATM-UBR –  PDR=PCR –  PBS= CDVT –  CDR= - –  CBS= - –  EBS=0 –  Frequency=Unspecified –  Dropping action:

drop>PCR

ATM-NRT VBR –  PDR=PCR –  PBS= VDVT –  CDR= SCR –  CBS= MBS –  EBS=0 –  Frequency=Unspecified –  Dropping action:

drop>PCR mark>SCR,MBS


The Resource Reservation Protocol (RSVP)

TOPICS - Main features of RSVP - Reservation styles - Soft State - The RSVP message format - The Path message - The Resv message


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.


•  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.


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.


An example

Sender Receiver

Resv

Path

Resv

Path

Path

Resv Resv

Path


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.


•  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.


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.


•  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.


•  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.


•  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.


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.


The following reservation schemes have been defined:

• Wildcard-filter (WF) style • Fixed-filter (FF) style • Shared explicit (SE) style


•  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.


•  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.


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.


MsgType RSVP checksum

RSVP length

Vers

Send_TTL Reserved

The RSVP message format

•  An RSVP message consists of the common header shown below, followed by a variable number of objects.

Flags


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


The object format

•  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.

Length (bytes) Class-num

Object contents

C-Type

2 bytes 1 byte 1 byte


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.


•  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.


•  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.


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).


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.


•  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.


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


•  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.


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).


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.


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.


The Resource Reservation Protocol- Traffic 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


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.


•  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.


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.


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.


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.


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.


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.


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.


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.


The RSVP new objects

•  The following five new objects have been introduced to support the functionality of RSVP-TE: –  LABEL –  LABEL_REQUEST –  EXPLICIT_ROUTE –  RECORD_ROUTE –  SESSION_ATTRIBUTE


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.


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

Minimum VPI Minimum VCI

Maximum VPI

M Res

Res

Reserved L3PID

Maximum VCI

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

Reserved L3PID

Length (bytes) Class-num C-Type

Length (bytes) Class-num C-Type

C_Type 1

C_Type 2

The LABEL_REQUEST object


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.


•  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.

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

Prefix length

IPv4 address L Type Length

IPv4 address Reserved

Sub-object for IPv4


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.


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)


– 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)


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)


– 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).

chapter 7: label distribution protocols

Documents