Upload
haduong
View
221
Download
3
Embed Size (px)
Citation preview
Connection-Oriented Networks - Harry Perros 1
Chapter 7:���Label Distribution Protocols
TOPICS – LDP – CR-LDP – RSVP – RSVP-TE
Connection-Oriented Networks - Harry Perros 2
• 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 3
The Label Distribution Protocol (LDP)
TOPICS: - Label spaces, hello adjacencies and sessions - LDP PDU format - LDP messages and formats
Connection-Oriented Networks - Harry Perros 4
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 5
LDP messages
• Four categories of messages have been defined, namely: – Discovery messages – Session messages – Advertisement messages – Notification messages
Connection-Oriented Networks - Harry Perros 6
• 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 7
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 8
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 9
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 10
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 11
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 12
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 13
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 14
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.
Connection-Oriented Networks - Harry Perros 15
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 16
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 17
• 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 18
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 19
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 20
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
Connection-Oriented Networks - Harry Perros 21
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
Connection-Oriented Networks - Harry Perros 22
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 23
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
Connection-Oriented Networks - Harry Perros 24
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
. . .
Connection-Oriented Networks - Harry Perros 25
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.
Connection-Oriented Networks - Harry Perros 26
LDP messages:
• Notification • Hello • Initialization • KeepAlive • Address • Address withdraw
• Label mapping • Label request • Label abort request • Label withdraw • Label release
Connection-Oriented Networks - Harry Perros 27
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 28
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 29
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
Connection-Oriented Networks - Harry Perros 30
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
Connection-Oriented Networks - Harry Perros 31
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
Connection-Oriented Networks - Harry Perros 32
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 33
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
Connection-Oriented Networks - Harry Perros 34
• 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
Connection-Oriented Networks - Harry Perros 35
• 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 36
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 37
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 38
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
Connection-Oriented Networks - Harry Perros 39
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
Connection-Oriented Networks - Harry Perros 40
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
Connection-Oriented Networks - Harry Perros 41
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
Connection-Oriented Networks - Harry Perros 42
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 43
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 44
• 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
Connection-Oriented Networks - Harry Perros 45
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 46
• 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
Connection-Oriented Networks - Harry Perros 47
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.
Connection-Oriented Networks - Harry Perros 48
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 49
• 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 50
• 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.
Connection-Oriented Networks - Harry Perros 51
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 52
• 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
Connection-Oriented Networks - Harry Perros 53
• 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.
Connection-Oriented Networks - Harry Perros 54
An example of how a CR-LSP is setup
Label request message
Label mapping message
Time
B A E C D
Connection-Oriented Networks - Harry Perros 55
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)
Connection-Oriented Networks - Harry Perros 56
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 57
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 58
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
Connection-Oriented Networks - Harry Perros 59
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
Connection-Oriented Networks - Harry Perros 60
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)
Connection-Oriented Networks - Harry Perros 61
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
Connection-Oriented Networks - Harry Perros 62
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.
Connection-Oriented Networks - Harry Perros 63
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 64
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
Connection-Oriented Networks - Harry Perros 65
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
Connection-Oriented Networks - Harry Perros 66
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
Connection-Oriented Networks - Harry Perros 67
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 68
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 69
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 70
An example
Tc
CBS
Packet 1 Packet 2 (marked)
Packet 3
time
Te
EBS
Packet 3 (marked)
Packet 4 (dropped)
Connection-Oriented Networks - Harry Perros 71
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 72
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 73
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
Connection-Oriented Networks - Harry Perros 74
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 75
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 76
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 77
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 78
• 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
Connection-Oriented Networks - Harry Perros 79
• 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
Connection-Oriented Networks - Harry Perros 80
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
Connection-Oriented Networks - Harry Perros 81
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
Connection-Oriented Networks - Harry Perros 82
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 83
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 84
• 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 85
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 86
An example
Sender Receiver
Resv
Path
Resv
Path
Path
Resv Resv
Path
Connection-Oriented Networks - Harry Perros 87
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 88
• 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 89
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 90
• 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 91
• 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 92
• 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 93
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 94
The following reservation schemes have been defined:
• Wildcard-filter (WF) style • Fixed-filter (FF) style • Shared explicit (SE) style
Connection-Oriented Networks - Harry Perros 95
• 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 96
• 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 97
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 98
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
Connection-Oriented Networks - Harry Perros 99
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 100
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
Connection-Oriented Networks - Harry Perros 101
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 102
• 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 103
• 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 104
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 105
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 106
• 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 107
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 108
• 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 109
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 110
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 111
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 112
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
Connection-Oriented Networks - Harry Perros 113
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 114
• 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 115
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 116
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 117
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 118
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 119
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 120
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 121
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 122
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
Connection-Oriented Networks - Harry Perros 123
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 124
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
Connection-Oriented Networks - Harry Perros 125
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 126
• 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
Connection-Oriented Networks - Harry Perros 127
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 128
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 129
– 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 130
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 131
– 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).