[MUSIC PLAYING]
So now that we've discussed why we want MPLS Traffic
Engineering, now it's time to talk about some
of the things that have to happen in order for MPLS TE
to actually work.
So the first is we're going to need a separate control plane
protocol.
We'll talk about that.
And of course, we'll talk about those changes that
had to be made to both OSPF and IS-IS
in order to be able to support MPLS Traffic Engineering.
So let's go ahead and jump in to talking
about the details of what we need to get MPLS Traffic
Engineering up and running.
So for the control plane, MPLS Traffic Engineering
uses Resource Reservation Protocol, or RSVP,
to exchange labels.
Now, RSVP is not a new protocol by any means.
We've been using it for quite some time for QoS.
It's not a popular option in QoS.
However, it has been around for a while.
And now we're using it for MPLS Traffic Engineering
as the control plane.
And we use it to exchange the labels used for our traffic
engineering tunnels.
Now, these labels that are created
are used to create an LSP, or a Label Switch Path, which
is really just another word for the TE tunnel.
The tunnel is based on constraint-based SPF, or CSPF.
This is that idea that we're going
to be using IS-IS or OSPF to perform the calculation
within certain constraints.
We'll be talking about this in more detail.
Now, as we mentioned, the tunnel itself is a Label Switch Path.
Even if you have two parallel tunnels,
they're going to use different labels.
Because again, a label is a path, or is a tunnel.
They're one and the same.
Also keep in mind that these tunnels can be rerouted.
And this could be for a variety of reasons.
Maybe our traffic pattern changes.
Maybe there's a failure in the network.
Any of these things could cause the tunnel to be rerouted.
If that happens, there will be a new Label Switch
Path, and therefore a new label for the tunnel.
Once our tunnel is up, network engineers,
that would be you, then direct the traffic--
or we call it traffic steering.
We steer the traffic into these TE tunnels
using, most commonly, the IGP.
We'll talk about traffic steering in more detail
as well.
This is an introduction to most of these topics.
Now, we have mentioned a few times
that the only routing protocols we can use here
are OSPF or IS-IS.
And both of those need extensions in order to work.
The reason we need these extensions is it
has to carry this resource information,
such as available bandwidth.
So that's essentially tracking load.
Again, this is not something these routing protocols
normally do.
We can also use these extended routing protocols
to direct the traffic--
or again, we call it traffic steering--
into these TE tunnels once they're up and running.
This will create additional FIB entries,
and is accomplished by applying the correct label stack.
And of course, the other thing these extensions do
is they implement that constraints-based SPF.
Meaning, it can look at things like the load on the interface,
and things like that.
So just to add more detail.
What does SPF consider?
Well, the first thing, of course,
is the information in the traffic engineering database,
or the TED.
This would be that information that we got above,
such as things like the available bandwidth,
and things associated with that.
Also, policies put in place by the network engineers.
And this, honestly, really is the key factor here.
This is something that we, as the engineers,
want to do, hence why it's called traffic engineering.
If we were to do all of this without any kind of a policy--
well, at that point, it's basically just regular
routing again.
There's really no point in going to traffic engineering.
So again, even if we're talking about the load on the circuits,
we still have to put that together
with this policy in order to tell it
what we actually want it to do under these certain conditions.
So the policy really is key for all of this to work.
And that policy, of course, is what's
being engineered by us network administrators.
Now, we do have some special names
that we've set aside for the Label Switch Routers that
are involved in the TE LSP.
First, we have the headend LSR.
This, of course, is the beginning of the tunnel.
Keeping in mind, as we go over these terms,
all tunnels are unidirectional.
So even if we're going to have a tunnel for return traffic going
the other way--
well, that's a separate tunnel.
It would have its own headend.
So think about it from the perspective
that all of these tunnels are one way.
Makes these terms make a lot more sense.
Tail-end, of course, is the opposite of the headend.
This would be the end of the tunnel
where the traffic comes back out.
And then a midpoint LSR is, of course,
just any router that's in the middle of this particular path.
Now, keep in mind these tunnels can
be based on many different criteria, some of which
we have the ingress point for the traffic, the egress point,
what class of service or QoS marking that traffic has.
So there's quite a few different things
that we can do for the criteria for the tunnel.
Another very important point, particularly
for the network engineer.
In order for us to properly configure TE--
and this goes with other things as well, of course,
like Quality of Service, things along those lines.
We really, really do have to understand the traffic that's
on the network.
If we don't understand the traffic properly,
then how can we manage it properly?
Keep in mind, we're not talking about just standard routing
here.
We're not just talking about getting traffic from point A
to point B. We honestly don't have
to know much about the traffic in order to just deliver it
properly.
However, it is very important to understand what the traffic is,
if we want to put it into a particular tunnel,
treat it a certain way, send it across a certain circuit.
That sort of thing.
So that's why understanding the actual traffic
is so critical when it comes to MPLS TE.
Now, we did already mention this point.
But make sure we remember that all tunnels are unidirectional.
So if you need traffic to go in both directions,
you're going to need a tunnel in both directions as well.
All traffic is one way through the tunnel.
Again, flowing from the headend to the tail-end.
Now, this could be an issue.
What we mean by that is, of course, scalability,
the number of tunnels that we're going to have.
But it's not usually the case.
And the reason we say that is, headends are normally
at the network edge.
So probably the PE routers.
We're not generally going to have these set up on the core.
Most traffic also would not require a full mesh.
If it did, yes, scalability could start becoming an issue.
However, a star topology would be far more likely,
particularly in a service provider core.
So again, scalability, not usually an issue here,
because of how these are normally used.
It is however, something that we want
to keep in mind if our environment starts getting more
complex, and these rules that we just talked about
don't necessarily apply.
So in this video, we got an introduction
to the moving parts of MPLS Traffic Engineering.
We talked a bit about RSVP, how we're using that
from the QoS world to be our control plane for MPLS Traffic
Engineering.
We also talked about the extensions and the changes
that have to happen to our IGPs in order to support this.
Now, as we dig deeper in, there are six TE processes
that we need to talk about.
And that's exactly what you and I get to do next.
We'll do that in the next video.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.