CS 672

1

Summer 2003

Lecture 9

CS 672

2

Summer 2003

FILTERSPEC Object

• FILTERSPEC Object defines filters for selecting a subset of data packets in a session. In general, these filters can be specified in terms:• sender IP address/port,• higher-level protocols, or • any fields in the packet header

• RSVP (current specification) restricts the filter definition to be based on:• Sender IP address• (optional) Source TCP/UDP port number

CS 672

3

Summer 2003

FILTERSPEC Object

• FILTERSPEC + Session information identifies the set of packets (i.e., flow) which is to receive the requested QoS in the FLOWSPEC Object (i.e., TSpec, RSpec).

• In a given session, packets that do not match any of the specified filters are treated as a best-effort traffic.

• FILTERSPEC is used to set the parameters in the packet classifier.

CS 672

4

Summer 2003

FILTERSPEC Object

+-------------+-------------+-------------+-------------+

| IPv4 SrcAddress (4 bytes) |

+-------------+-------------+-------------+-------------+

| ////// | ////// | SrcPort |

+-------------+-------------+-------------+-------------+

+-------------+-------------+-------------+-------------+

| IPv4 SrcAddress (4 bytes) |

+-------------+-------------+-------------+-------------+

| ////// | ////// | SrcPort |

+-------------+-------------+-------------+-------------+

CS 672

5

Summer 2003

Reservation Styles

• RSVP reservation request also contains a set of options (collectively referred to reservation style).

• RSVP has two kind of reservation options namely:• Reservation style option that selects the type of reservation is to be made for

different senders within the same sessions. • Sender selection option that selects the list of senders that receive the requested

QoS.

CS 672

6

Summer 2003

Reservation Styles

• Reservation style option may have following attributes:• distinct – i.e., create a separate reservation for each upstream sender.• shared – i.e., create a single reservation that is shared among all packets of selected

senders.• Sender selection option may have following attributes:

• explicit –i.e., the selection of senders is explicitly listed. In the case of explicit sender-selection reservation, each filter spec matches exactly one sender.

• wildcard –i.e., no filter spec is used (all senders are eligible).

CS 672

7

Summer 2003

Reservation Styles

FF SE

Not defined WF

Distinct Shared

Explicit

WildcardSender Selection

Reservation

•Fixed Filter Style (FF) - separate reservation for each sender.•Wildcard Filter (WF) Style – means shared reservation for all upstream senders •Shared Explicit (SE) Style – means a single reservation is shared among a set of explicitly identified senders.

CS 672

8

Summer 2003

Fixed Filter (FF) Reservation

Sender 1

Sender 2

Receiver 1

Receiver 2

Reservation by Sender 1Reservation by Sender 2

CS 672

9

Summer 2003

Shared Explicit (SE) Reservation

Sender 1

Sender 2

Receiver 1

Receiver 2

Shared reservation for S1 and S2

Reservation for S1

Reservation for S2

CS 672

10

Summer 2003

RSVP Messages

• RSVP defines a number of messages for establishing establishing, maintaining, and releasing sessions.

• RSVP currently defines following messages:• Path• Resv• PathErr• ResvErr• PathTear• ResvTear• ResvConf

CS 672

11

Summer 2003

RSVP Message Formats

• Each message contains a common header.• Common header contains fields such as:

• Vers - RSVP protocol version. Current version is 1.• Msg Type - A number identifying the message type. For example, = 1 means Path

message, =2 Resv Message, …

0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | | // (Object contents) // | | +-------------+-------------+-------------+-------------+

0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | | // (Object contents) // | | +-------------+-------------+-------------+-------------+

CS 672

12

Summer 2003

RSVP Objects

• Each RSVP message consists of a fixed number header and a variable number of objects.

• Each RSVP Object is in the form of Type Length Value (TLV). Object type is indicated in the Class-Num field.

• RSVP has defined following Object types:• SESSION, RSVP_HOP, TIMER_VALUES, STYLE, FLOWSPEC, FILTER_SPEC,

SENDER_TEMPLATE, SENDER_TEMPLATE, …

CS 672

13

Summer 2003

RSVP Object Formats

• Class-num identifies different classes e.g., 1= IPv4/UDP session, 2= IPv6/UDP session, 3=RSVP_HOP, …

0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | | // (Object contents) // | | +-------------+-------------+-------------+-------------+

0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | | // (Object contents) // | | +-------------+-------------+-------------+-------------+

CS 672

14

Summer 2003

RSVP Objects

• SESSION Object• Destination IP address, Protocol ID, Destination Port

• RSVP_HOP Object• IP address of the message sender, Logical Interface Handle (LIH).• Used to route RSVP message in the reverse direction

• TIMER_VALUES Object• Contain value of the refresh period values

• STYLES Object• Reservation styles

CS 672

15

Summer 2003

RSVP Objects

• FLOWSPEC Object• Define the required QoS (i.e., RSPEC, TSPEC)

• FILTER_SPEC Object• Selects subset of data packets that should get the requested QoS.

• SENDER_TEMPLATE• Sender IP address, …

• SENDER_TSPEC Object• Sender’s traffic parameters

CS 672

16

Summer 2003

RSVP_HOP Object

• In a PATH message (i.e., downstream direction), RSVP_HOP object carries the IP address of the node sending this message or the previous hop (PHOP) address.

• In a RESV message (i.e., upstream direction), RSVP_HOP object carries the IP address of the node sending the RESV message. That is from the node receiving this message, it is the address of the next hop (NHOP).

CS 672

17

Summer 2003

RSVP_HOP Object

IPv4 RSVP_HOP object: Class = 3, C-Type = 1

+-------------+-------------+-------------+-------------+ | IPv4 Next/Previous Hop Address | +-------------+-------------+-------------+-------------+ | Logical Interface Handle | +-------------+-------------+-------------+-------------+

IPv4 RSVP_HOP object: Class = 3, C-Type = 1

+-------------+-------------+-------------+-------------+ | IPv4 Next/Previous Hop Address | +-------------+-------------+-------------+-------------+ | Logical Interface Handle | +-------------+-------------+-------------+-------------+

CS 672

18

Summer 2003

SENDER_TSPEC

31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | reserved | 7 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 1 (c) |0| reserved | 6 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++++++++++++++

31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | reserved | 7 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 1 (c) |0| reserved | 6 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++++++++++++++

• Specifies sender’s traffic parameters. This object is carried unchanged from RSVP sender to receiver.

CS 672

19

Summer 2003

PATH Messages

• When an application in the sending node has some data to transmit, it triggers a request to the RSVP module.

• The RSVP module in the sending node:• Builds the PATH message• PATH message contains objects such as: <Common

Header><SESSION><RSVP_HOP><TIME_VALUES> <SENDER <_TEMPLATE><SENDER_TSPEC> … and optional objects

• Sets source IP address = sender node’s address, destination IP address = receiver node’s address

• Performs a CAC check. If CAC check passes, allocate (set aside but not reserved yet) resources such as bandwidth.

• Sets the RSVP_HOP object = IP address of the outgoing interface.• Sends the Path message to the downstream RSVP neighbor.

CS 672

20

Summer 2003

PATH Messages

• The PATH message is hop-by-hop routed along the same path that would be taken by the data packets.

• Upon receiving the PATH message, the downstream RSVP node:• Creates the Path State Block (PSB) that contains all PATH message related state

information. • Stores information such as previous hop (PHOP) in the PSB.• Performs a CAC check. If CAC check passes, allocate (set aside but not reserved

yet) resources such as bandwidth.• Sets the RSVP_HOP object = IP address of the outgoing interface.• Sends the Path message to the downstream RSVP neighbor.

CS 672

21

Summer 2003

PATH Messages

• The process of forwarding PATH message repeats until it reaches the destination (i.e., receiver node)

• Note the SENDER_TSPEC is carried unmodified from the sender to the receiver.

• If any errors occur during PATH message processing, a PathErr message is transmitted in the upstream direction towards the sender.

CS 672

22

Summer 2003

RESV Messages

• Based on information carried in the PATH message, the receiver determines the reservation parameters.

• For requesting QoS, the receiver builds the RESV message• PATH message contains objects such as: <Common

Header><SESSION><RSVP_HOP><TIME_VALUES> <FILTER_SPEC><FLOWSPEC> • Sets source IP address = IP address of the node originating RESV message, destination

IP address = derived from RSVP_HOP in PSB. This is how RESV message is steered along the path traversed by the corresponding

PATH message in the opposite direction.• Performs a CAC check. If CAC check passes, reserve the resources.

CS 672

23

Summer 2003

RESV Messages

• Programs the classifier (based on FILTER_SPEC) and scheduler (based on RSpec).• Sets the RSVP_HOP object = IP address of the outgoing interface. • Creates the RESV State Block (RSB)• Sends the Path message to the Upstream RSVP neighbor

• As the RESV message travels upstream, it creates RSB in each RSVP-capable node.

• This process repeats until the RESV message arrives at the target destination (i.e., sender )

• If any errors occur during PATH message processing, a PathErr message is transmitted in the downstream direction towards the receiver.

CS 672

24

Summer 2003

Soft State

• RSVP creates its path (i.e., RSB) and reservation (i.e., RSB) state using initial PATH and RESV messages.

• RSVP is based on soft state model which means it needs to be refreshed periodically. If not refreshed on time, the reservation state is removed.

• Thus each RSVP node periodically refresh PATH and RESV messages on a hop-by-hop basis.• With the exception of certain flags, the PATH/RESV refresh messages are identically to the corresponding

initial PATH/RESV messages.• If a node does not receive an appropriate PATH/RESV refresh messages within cleanout

timeout, the corresponding PATH/RESV state is deleted.• RSVP uses periodic transmission of refresh messages to refresh its state and any packet loss.

CS 672

25

Summer 2003

Refresh Reduction

• As the number of sessions increase,• the number of PATH/RESV refresh messages that needs to be generated and

processed also increase• In steady-state, RSVP soft state model may consume considerable

processing and bandwidth resources• Some of the issues associated with refresh volume and unreliable message

delivery can be addressed using refresh reduction mechanisms.• For example, use of summary refresh reduces amount of information that needs to be

refreshed.• And message ACK allows detect of message loss.

CS 672

26

Summer 2003

Refresh Reduction

R3

(Sender)

R1

R2 R4

(Receiver)

Path Refresh Message

Resv Refresh Message

Path/Resv state refresh volume can be reducedvia refresh reduction mechanisms

CS 672

27

Summer 2003

Local Repair – next hop changes

• As the next hop for certain destination changes, the data traffic packets will be routed along the newer path.

• RSVP adapts accordingly and start sending PATH/RESV refresh messages along the new path to establish and maintain state.

• One way to detect next hop change is based on comparison of RSVP_HOP objects. Depending upon refresh period, this method could be slower.

• Alternatively, routing protocol notifies the next hop change to RSVP which then quickly adapts accordingly.

CS 672

28

Summer 2003

Local Repair – next hop changes

SenderReceiver

Resv

Path

RSVP adapts to the next hop change

CS 672

29

Summer 2003

RSVP TE

Big Picture

CS 672

30

Summer 2003

Extending RSVP for MPLS Tunnels

• To support several functions related to establishment of traffic engineered MPLS tunnels, RSVP-TE (RFC 3209) extends the original RSVP protocol (RFC 2205).

• Specifically, RSVP-TE extensions enable new set of capabilities such as:• Downstream-on-demand (DoD) label distribution mode.• Establishment of explicitly routed LSPs (tunnels) with or without reservation of QoS

(e.g., bandwidth).• Re-optimization of established tunnels using a make-before-break approach.• Recording of the actual path traversed by the tunnel• Preemption options

CS 672

31

Summer 2003

RSVP-TE Extensions

• In order to support these capabilities, RSVP-TE specification (RFC 3209) defines following new objects such as:• LABEL_REQUEST Object (LRO)• LABEL Object• RECORD_ROUTE Object (RRO)• EXPLICT_ROUTE Object (ERO)• LSP_TUNNEL_IPv4 SESSION Object• LSP_TUNNEL_IPv4 SENDER_TEMPLATE Object• SESSION_ATTRIBUTE Object

CS 672

32

Summer 2003

RSVP Vs. RSVP-TE

• RSVP is used to request and reserve QoS for IP flows.• In contrast, RSVP-TE is used to establish/maintain MPLS tunnels with or without

QoS reservation.• RSVP defines a session as a data flow with particular destination IP address and

transport layer protocol (i.e., UDP/TCP port).• In contrast, RSVP-TE defines a session as a set of packets that are assigned the

same label at the tunnel source (head). • Because each tunnel can aggregate multiple flows, the number of tunnels does

not scale linearly with the number of flows. As a result, RSVP-TE is more scalable as compared with the RSVP.