QoS RSVP Resv message

There are two fundamental RSVP message types Resv and Path.

Refer to the following diagram.

RSVP-router-topology.png

Assume R1 is the source and R4 is the receiver of the intended traffic for which RSVP will be employed.

RSVP requires that each and every router in the intended path participates in reserving the appropriate resources. In order to achieve this, the ultimate receiver, R4, will send a RESV message upstream, all the way back to the original sender, R1. R1 will then send an RESV CONFIRM message back downstream all the way to R4. These RESV messages create a "reservation state" in each node along the path.

When looking at the debugs of the operation of RSVP within a transit router, such as R2, or R3 in the above example, we will see something like this:

start requesting 64 kbps FF reservation for 192.168.12.1(0) TCP-> 192.168.34.4(80) on FastEthernet0/0 neighbor 192.168.12.1
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Refresh RESV, req=674BDE94, refresh interval=0mSec [cleanup timer is not awake]
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Sending Resv message to 192.168.12.1
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: RESV CONFIRM Message for 192.168.34.4 (FastEthernet0/0) from 192.168.12.1
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Sending RESV CONFIRM message to 192.168.23.3

Notice that the router will receive an RESV message from the receiver destined for the source, and will then forward it towards the source. Similarly, when the RESV CONFIRM comes from the source, it will receive it and forward it to the receiver.

For more information about Quality of Service in general, take a look at QoS.

https://networklessons.com/quality-of-service/introduction-to-rsvp https://datatracker.ietf.org/doc/html/rfc2205#page-8

Links to this page: