[AUDIO LOGO]
So now it's time to jump in and take a closer look at RSVP,
or Resource Reservation Protocol.
Now, as we mentioned in one of the previous videos,
this is not a new protocol for MPLS traffic engineering.
We're actually taking this from the IntServ model of QoS.
Now, this is not a model that's commonly implemented.
And the reason for that is simply scalability.
We have the DiffServ model, which we're probably
very familiar with.
That scales much better, where we're prioritizing and doing
QoS to our traffic based on classes
and what type of traffic it is, where the IntServ
model actually set up a dedicated or reserved path
for the traffic through the network.
So I'm sure you can imagine that setting aside
a certain amount of bandwidth per each flow, again,
doesn't scale real well.
But that's exactly what we want to do for our tunnels.
And that's why we borrow or take RSVP from the QoS IntServ model
and use it here in traffic engineering.
And we'll see, as we go through this discussion,
how we use its signaling and, really, its main function,
which is to do path reservations,
to make these tunnels possible.
So let's go ahead and jump in and take a look
at how MPLS traffic engineering uses RSVP.
So the job of RSVP in traffic engineering
is once the path has been selected, again,
that's up to the IGP.
That's up to the routing protocol.
But then we use RSVP from the head end
to signal all of the intermediate routers
what the intended path is and what
the requirements are for the reservation for this tunnel.
As long as all of the intermediate routers agree,
RSVP then reserves that bandwidth
for the specific tunnel to prevent oversubscription.
This prevents us from setting up more tunnels
than we actually have bandwidth to make sure that we're
fulfilling the requirement.
Now, of course, it would be possible, particularly
in the event of a failure, that we end up with more tunnels
than we have bandwidth for, in which case,
we do need to have a way to deal with that because, of course,
in most environments, some tunnels are going to be more
important than others.
It could depend on what type of traffic
it is, that sort of thing.
So we do have a way to handle that.
The way we handle that is by using tunnel priority.
Tunnel priorities allow one tunnel to preempt a lower
priority tunnel.
Some of the guidelines here--
the priorities are a range of zero to seven.
And the lowest value wins, meaning
a two priority would be able to preempt a four
priority, for example.
And when we say preempt, just so we're clear,
yes, this does mean that if the other tunnel is,
in fact, already up, we will take that tunnel down
for the higher priority tunnel.
It's not just a matter of preventing it
from being established.
But again, if a failure occurs and we're suddenly
short of bandwidth, it will actually take down
the lower priority tunnels.
Now, the signaling used for this--
it's going to use a path message.
That's what's going to be sent from the head end
to the tail end.
And this carries the explicit path of the label switch
routers that we're going to be going through.
The message itself will follow that explicit path
that we intend to use.
This carries in it the label request.
We're requesting a label from the tail end
to know which label to use for this LSP.
Each intermediate router-- so every router this has to pass
through--
is going to perform admission control.
This is where those routers get to say, yes,
I have enough bandwidth.
Let's build this tunnel.
Or no, I don't have enough bandwidth available.
We can't do this.
That's the admission control happening along the way.
As long as the path message gets all the way to the tail,
we are then going to send a reserve message
from the tail back to the head.
So this is, of course, going to be
sent along the reverse path from the path message.
This actually carries the requested label
that was generated by the tail end router.
And each intermediate router then actually sets up
the reservation.
So far, it only agreed.
Now it actually reserves it and creates a label.
Once this reserve message gets back up to the head end,
the tunnel is now up.
That's what constitutes the tunnel
being up and ready to be used.
So these are the main communications that
are going to happen in RSVP.
Now, there are some other messages that do get used.
You want to be aware of them.
But we don't necessarily have to know the detail on them.
So we have the path teardown message.
We have a reservation error message if there's not
enough reservation on the path.
We have an actual path error message
if something goes wrong with the path
itself, A reservation confirmation
message, and a reservation teardown message.
So like I said, there are several other message types
that are used here.
Just be aware that RSVP is using these messages
to do tunnel management.
So in this video, we took a closer look
at RSVP, that protocol that we borrowed from the IntServ
model of QoS, and how we're using
it pretty much for the same purpose
that it was used in the IntServ model, which
is to reserve bandwidth for a specific traffic flow.
Just in this case, that traffic flow is our tunnel.
And of course, we added the functionality
of exchanging the label that we're
going to use into RSVP as well.
Now, we also know that there have been major changes
to the routing protocols as well, specifically
the use of CSPF.
And we need to take a closer look at that as well.
That's exactly what we're going to do next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.