CS Summer 2003 Lecture 9

CS 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 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 Summer 2003 FILTERSPEC Object | IPv4 SrcAddress (4 bytes) | | ////// | ////// | SrcPort |

CS 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 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 Summer 2003 Reservation Styles FFSE Not definedWF DistinctShared Explicit Wildcard Sender 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 Summer 2003 Fixed Filter (FF) Reservation Sender 1 Sender 2 Receiver 1 Receiver 2 Reservation by Sender 1 Reservation by Sender 2

CS 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 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 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, … | Length (bytes) | Class-Num | C-Type | | | // (Object contents) // | |

CS 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 Summer 2003 RSVP Object Formats Class-num identifies different classes e.g., 1= IPv4/UDP session, 2= IPv6/UDP session, 3=RSVP_HOP, … | Length (bytes) | Class-Num | C-Type | | | // (Object contents) // | |

CS 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 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 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 Summer 2003 RSVP_HOP Object IPv4 RSVP_HOP object: Class = 3, C-Type = | IPv4 Next/Previous Hop Address | | Logical Interface Handle |

CS Summer 2003 SENDER_TSPEC | 0 (a) | reserved | 7 (b) | | 1 (c) |0| reserved | 6 (d) | | 127 (e) | 0 (f) | 5 (g) | | Token Bucket Rate [r] (32-bit IEEE floating point number) | | Token Bucket Size [b] (32-bit IEEE floating point number) | | Peak Data Rate [p] (32-bit IEEE floating point number) | | Minimum Policed Unit [m] (32-bit integer) | | Maximum Packet Size [M] (32-bit integer) | Specifies sender’s traffic parameters. This object is carried unchanged from RSVP sender to receiver.

CS 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: … 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 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 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 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: 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 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 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 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 Summer 2003 Refresh Reduction R3 (Sender) R1 R2R4 (Receiver) Path Refresh Message Resv Refresh Message Path/Resv state refresh volume can be reduced via refresh reduction mechanisms

CS 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 Summer 2003 Local Repair – next hop changes Sender Receiver Resv Path RSVP adapts to the next hop change

CS Summer 2003 RSVP TE Big Picture

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