Enhance your Career in Networking With IPinBits!!!​

FUNDAMENTALS OF RSVP : Lets have a look with lab

When it comes to QOS, we have the three basic models as below:

  • Best Effort (do not use QoS for traffic that does not need any special treatment.)
  • DiffServ (Differentiated Services implemented using IP precedence and DSCP)
  • IntServ (Integrated Services implemented using RSVP)

When using DiffServ we implement QoS on a “hop by hop” (PHB) basis where we use the ToS byte of IP packets for classification.

IntServ is completely different, it is a signaling process where network flows can request a certain bandwidth and delay that is required for the flow. 

OverView on RSVP:

  • RSVP is a signaling protocol not routing protocol itself, it uses unidirectional traffic flows.
  • Similar to LDP, it also required IGP along its path to function.
  • Makes resource reservations for unidirectional data flows.
  • Allows the receiver of a data flow to initiate and maintain the resource reservation used for that flow.
  • Maintains a soft state in routers and hosts, providing graceful support for dynamic membership changes and automatic adaptation to routing changes.
  • Provides several reservation models or styles to fit a variety of applications.
  • Supports both IPv4 and IPv6 packets that can be sent over RSVP-signaled LSPs.
  • The message exchanged in rsvp are as below in the below sections.

Lets See how RSVP works :

RSVP uses the following messages, for data flows, establishing and removing reservations, confirm reservations and report errors.

The first two messages (PATH AND RESV) are the main messages and then the remaining are subtypes.

When a host wants to make a reservation, it will send a RSVP reservation request using a RSVP path message. This message is passed along the route towards the destination. When a router can guarantee the required bandwidth/delay, it will forward the message. Once it reaches the destination, it will reply with a RSVP resv message. The same process will occur for the opposite direction. Each router will check if they have enough bandwidth/delay for the flow and if so, they will forward the message towards the source of the reservation. Once the host receives the reservation message, we are done.

Both PATH and RESV messages are periodically sent by the host and receiver respectively in order to refresh path status and reservation status along the path on each hop.

Refresh time is the variable used for the above and refresh time is calculated as below:

(keep-multiplier + 0.5) x 1.5 x refresh-time (keep multiplier is number, refresh time is in seconds)

Path Message:

  • Generated by the headend router and is forwarded through the network along the path of a future TE LSP.
  • At each hop, the PATH message checks the availability of requested resources and stores this information.
  • In the above diagram, Host will generate a path message and pass on it to all the downstream routers hop by hop, all the transit routers will also generate path messages and forward to the neighbor until destination.
  • RSVP PATH message has Router Alert (RA) bit set, which allow the intermediate hops to intercept/process and send a new PATH message towards the Tail end Router.
  • RFC 2113 introduced a new IP option called the Router Alert option. If this option is present in an IP header, it is a signal to every router it crosses that the router needs to take a close look at the packet. The Router Alert (RA) is always present in the Path message.
  • The RSVP PATH message functions as a label request in MPLS TE domain. Because all TE domains function with downstream-on-demand label

Reserve Message:

  • Created by the tail end router in the MPLS TE domain and used to confirm the reservation request, which was sent earlier with the PATH messages.
  • Therefore, PATH messages function as reservation requests and RESERVATION messages function as reservation confirmations for the availability of requested resources.
  • The RSVP RESERVATION message performs the function of label assignment for a particular LSP mapping to the TE tunnel.
  • As the MPLS domain label allocation and distribution is performed downstream on demand, the label mapping to a TE LSP is first generated by the tail end router or egress Edge LSR and then propagated upstream.
  • This process is repeated at each hop upstream where local labels mapping to a TE tunnel are assigned and propagated upstream until the headend router is reached.

Path Tear/Resv Tear: This are optional messages, used same as path/resv messages (path is also same). They enhance network performance because they release network resources quickly. If Path Tear messages are lost or not generated, path states eventually time out when they are not refreshed and the resources associated with the path are released.

Path ERR/ Resv ERR: During the PATH/RESV stage, the reservation could fail and lead to a PATH_ERR or RESV_ERR message being generated. This is usually because of parameter problems in the path.

ResvConfirm: Receivers can request confirmation of a reservation request, and this confirmation is sent with a ResvConfirm message. Because of the complex RSVP flow-merging rules, a confirmation message does not necessarily provide end-to-end confirmation of the entire path. Therefore, ResvConfirm messages are an indication, not a guarantee, of potential success.

RSVP HELLO

Hello Messages are optional in both cisco and Juniper, but we can manually configure hello for faster convergence, IGP itself can detect fast failures this days with BFD, FRR that can also benefit RSVP, so this is optional parameters.

RSVP Lab basic

  • If you do not specify the bandwidth then by default RSVP will use up to 75% of the interface bandwidth for reservations. I am telling RSVP that it can only use up to 128 kbps for reservations and that the largest flow which can be reserved is 64 kbps.
  • R1 is the host here and R4 is the receiver.

Path Message:

ON host:  ip rsvp sender-host 192.168.34.4 192.168.12.1 TCP 23 0 64 32

Resv Message:

Destination/Receiver: ip rsvp reservation-host 192.168.34.4 192.168.12.1 TCP 23 0 FF RATE 64 32

Find the config Below along with troubleshooting commands:

R1Download R2Download R3Download R4Download troubleshooting_commandsDownload

Wireshark Capture : https://drive.google.com/file/d/1cjwpaAFk6LsBUCx6Na-zLeOk4Mk1PQ7E/view?usp=sharing

Related blog posts