[MUSIC PLAYING]
So now that we have a better understanding of the MPLS
header, how it carries the label, the EXP
bits, the bottom of Stack Indicator,
the TTL, and how that's a shim header writing between layers 2
and 3, we can start to think about this
as a way of tagging traffic, much in the same way
that we can tag routes.
Now, if you think about it.
We tagged routes for various different reasons.
The most common, of course, is to then filter on that tag.
But we can also use it to indicate
where that route came from.
So much like tagging routes is useful,
tagging traffic can be useful as well.
And not just for IP forwarding.
That's why these other applications also require MPLS.
But here's the thing.
You have one label that we're going
to be using for actually forwarding
the traffic through our core.
Then we have to have additional labels to give that information
to these other applications.
So that's what we're going to be focusing on in this video.
When one label is not enough, we then have a label stack.
So let's jump in and take a look at how this works,
and what applications actually need to use it.
So as we mentioned, the primary purpose of running MPLS
to begin with, is to support various different applications.
Some of those applications we have listed here.
One of them, of course, being IP and IPv6 unicast routing.
This is going to require a single label.
We usually call it the forwarding label.
And this label is going to be exchanged
using LDP, which we'll be taking a much deeper look
at in a future skill.
Also, we have IP and IPv6 multicast forwarding.
This will also be using just a single label.
So the regular forwarding, in and of itself,
is a single label.
But when we start adding on other applications,
such as traffic engineering, this
is going to require an additional label.
Differentiated QoS.
Again, we'll talk more about this in the future as well.
But this also requires a label.
Layer 2 and Layer 3 VPN.
Both of these require an additional label.
So when we add on these services,
we're having a minimum of two labels--
possibly three, if we start combining
these different services together.
Now, the reason this is important.
There's really no limit on the number of additional labels
we can have.
However, we do have to have a way
to deal with these additional labels.
Now, right off the bat, we simply
call this a label stack because there's,
of course, more than one label.
And this is what we had just mentioned,
that there's not really a limit on how many labels you can use.
Now, like I said, in most of today's applications,
we're going to be looking at two, maybe three.
But there's technically no limit.
We're hooking these together like a train of labels.
So really, there's no limit.
The real limit would be this next one,
which is we do have to ensure that the MTU allows
for those additional labels.
Keep in mind that if we have a standard Ethernet interface,
the MTU on that interface is generally 1500 bytes.
And if a device has sent a packet at the maximum
MTU size--
meaning, the frame is actually 1500 bytes--
and then we insert this label, which,
again, is a shim header, that's 32 bits or 4 additional bytes,
we have to add 4 bytes to this for every label
that we put on the stack.
Next thing you know, we're at 1508 just
to support two labels.
So we need to make sure that we increase
the MTU for however many labels we need in our label stack.
Just as a side note.
On a lot of environments today, we
turn on what's called jumbo frames on Ethernet, which
is in excess of 9000 bytes.
In which case, this really shouldn't be an issue.
However, if you are still running standard Ethernet
frames at 1500 bytes, we do have to make sure
that we adjust this MTU.
Now, since there's no set number of labels,
that means we have to have some way of knowing
where the label stack stops, and the next header begins.
So just as an example.
If I had my original Layer 2 header out here in the front,
and then I start stacking labels onto this.
How are the devices supposed to know
where those labels stop, and the original layer header begins?
There's nothing to indicate how many labels are actually
in here.
So what we do is we use this bottom-of-stack indicator
to let everybody know where the last label is.
Keep in mind that this is also referred to as the S-bit.
But the way it works is simply this.
Each of these labels would have an S-bit of 0,
except the last one.
This is a simple flag bit to indicate
which one is the last label.
And now the receiving devices know that the next bits are
the original Layer 3 header.
This is how we know where the label stack ends.
So while we're getting started with MPLS,
we will be focusing here on IPv4 and IPv6 forwarding.
Because again, this is the baseline
to get all of our other features up and running.
Again, this is needed to support all those other applications.
The way it works is, we create a label for every IP destination,
specifically in the RIB, or the routing information
base, commonly known as the routing table.
But each of these represents what's
called an F-E-C, or a FEC, which is a Forwarding Equivalency
Class.
As we mentioned before, we also support multicast forwarding.
This is supported with PIM, or Protocol Independent Multicast,
which is essentially the routing protocol for multicast.
We have skills on this coming up in future domains.
In this case, the FEC is going to be
the multicast destination.
In this video, we talked about how
we can use multiple labels in a stack
to support different applications running
on top of MPLS.
Keep in mind that IP forwarding, and IPv6 forwarding itself,
of course, uses a label as well.
And then the other applications have
to have additional labels to provide the needed information
to those applications.
One of the applications that needs that is MPLS VPNs.
And we're going to get an introduction to those coming up
next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.