|
0:00:13
|
The last QoS mechanism we have on the routers is the
|
|
0:00:17
|
resource reservation protocol or RSVP
|
|
0:00:21
|
that was designed to be used with the integrated
|
|
0:00:24
|
services model in order for the actual application to make a
|
|
0:00:28
|
reservation of the network.
|
|
0:00:32
|
So the key point is that the source application and the
|
|
0:00:36
|
receiving application they both would need to support RSVP
|
|
0:00:39
|
The sender that wants to do the reservation is going to initiate
|
|
0:00:43
|
an RSVP path message asking the devices in the transit path
|
|
0:00:48
|
'Can you support this specific type of reservation?'
|
|
0:00:52
|
So specifically it has two variables: the spec and the rspec
|
|
0:00:58
|
where the tspec is the traffic parameters like what's the
|
|
0:01:03
|
particular rate that I want to apply
|
|
0:01:06
|
and the rspec is the reservation or what is the specific type of
|
|
0:01:09
|
traffic that is going to be sent.
|
|
0:01:13
|
If the devices in the transit path agree with that
|
|
0:01:16
|
they will reply with the reserve message
|
|
0:01:21
|
from the destination back to the source.
|
|
0:01:25
|
So the reservation goes on a hop by hop basis from the
|
|
0:01:27
|
source all the way to the destination, if the destination
|
|
0:01:30
|
agrees, it applies with reserve and reserve happens in the reverse
|
|
0:01:34
|
path on the way back to the source.
|
|
0:01:36
|
Now once the end application does this reservation in the control
|
|
0:01:41
|
plane, the router is automatically going to enforce this in the data plane
|
|
0:01:47
|
through the weighted fair queuing.
|
|
0:01:50
|
So in order for RSVP to work, it implies that we need either
|
|
0:01:55
|
class based weighted fair queuing or regular weighted
|
|
0:01:57
|
fair queuing because the RSVP flow is going to get
|
|
0:02:02
|
a separate weight as one of the weighted fair queues.
|
|
0:02:06
|
So technically, there's only one command that we need to
|
|
0:02:09
|
do on the router in order to support this
|
|
0:02:11
|
which is the ip rsvp bandwidth command at the interface level.
|
|
0:02:15
|
This simply says that I am available to receive a reservation
|
|
0:02:21
|
on my interface.
|
|
0:02:23
|
So if I receive a path message and assuming I have enough bandwidth
|
|
0:02:27
|
left over, then the router should be able to send a
|
|
0:02:30
|
reserve message back to the originator.
|
|
0:02:35
|
But since the router is keeping track of the individual flows that
|
|
0:02:38
|
have been reserved, if too much bandwidth is reserved
|
|
0:02:42
|
then it's going to not tell the source or it will to the
|
|
0:02:46
|
source, but it will tell the source that I cannot do this reservation.
|
|
0:02:51
|
So it's going to reply back with an error message saying
|
|
0:02:53
|
that reservation cannot be achieved as opposed to
|
|
0:02:57
|
the reserve message which is the normal response to
|
|
0:03:00
|
the path. Now the problem with RSVP is that
|
|
0:03:04
|
most of this is considered legacy application
|
|
0:03:07
|
because again, it's going to assume that the routers
|
|
0:03:10
|
in the transit path would need to keep the state for
|
|
0:03:13
|
all of the individual flows in the network.
|
|
0:03:16
|
Additionally, there's no way to say that a single
|
|
0:03:20
|
host cannot do every single reservation, so a lot of times
|
|
0:03:23
|
it's not actually used in production.
|
|
0:03:26
|
Ok, really the only thing that this is used for nowadays
|
|
0:03:29
|
is for MPLS traffic engineering for the routers to ask for
|
|
0:03:33
|
a specific bandwidth value associated with an individual
|
|
0:03:36
|
traffic engineering tunnel.
|
|
0:03:39
|
Now since we need weighted fair queuing in order to enforce
|
|
0:03:44
|
the data plane queuing, it means that the other
|
|
0:03:47
|
HQF mechanisms or the other MQC mechanisms
|
|
0:03:50
|
are not going to work with RSVP
|
|
0:03:55
|
It can work with legacy frame relay traffic shaping
|
|
0:03:59
|
on a per virtual circuit basis
|
|
0:04:01
|
but the key is that the PVC's queue needs to be
|
|
0:04:05
|
weighted fair queuing.
|
|
0:04:08
|
So depending on how the shaper is configured if
|
|
0:04:10
|
it was configured through the hierarchical queuing framework
|
|
0:04:14
|
remember that the individual sub queues of that are FIFO by default
|
|
0:04:19
|
which means that RSVP wouldn't be able to work
|
|
0:04:22
|
because it needs weighted fair queuing in order to
|
|
0:04:26
|
specify what is the weight for the RSVP reservation.
|
|
0:04:31
|
So it's trying to do the automatic allocation of the
|
|
0:04:35
|
bandwidth based on the weighting that the RSVP
|
|
0:04:38
|
queue has reserved. Now you can technically
|
|
0:04:41
|
configure the router as the originator of the path message
|
|
0:04:46
|
and then the responder to the reserve message
|
|
0:04:49
|
with the ip rsvp sender and the ip rsvp reservation
|
|
0:04:54
|
but typically, it's the end application that does the
|
|
0:04:57
|
reservation itself.
|
|
0:04:59
|
So in the case of MPLS traffic engineering, it would be that
|
|
0:05:02
|
the tunnel's head end that's actually configuring the tunnel
|
|
0:05:05
|
that does the reservation
|
|
0:05:08
|
then the routers in the transit path the only thing that they need
|
|
0:05:10
|
to be configured with is the ip rsvp bandwidth.
|
|
0:05:17
|
So I really wouldn't spend too much time on this topic
|
|
0:05:20
|
but if you needed to reference it under the documentation
|
|
0:05:23
|
if you went to the configuration guides and then under quality of
|
|
0:05:27
|
service, this should be
|
|
0:05:31
|
under signaling
|
|
0:05:35
|
and RSVP
|
|
0:05:47
|
so if we look at the configuration examples,
|
|
0:06:25
|
it says example configuring RSVP bandwidth.
|
|
0:06:28
|
The following example shows how to configure an absolute
|
|
0:06:31
|
value for RSVP bandwidth in a percentage of the interface
|
|
0:06:35
|
as a flow bandwidth.
|
|
0:06:37
|
So we basically say that the total reservable amount
|
|
0:06:41
|
is 1 Megabit per second
|
|
0:06:44
|
in an individual flow, it cannot take more than 50 percent of this.
|
|
0:06:51
|
So this would stop one individual end host from reserving more than
|
|
0:06:54
|
500 K
|
|
0:06:56
|
and as a total, all of the flows can reserve no more than
|
|
0:06:59
|
1 Megabit per second.
|
|
0:07:02
|
But technically, this command on its own this is the only thing
|
|
0:07:04
|
that's needed to support RSVP in the transit path of the network.
|