So as we mentioned, we need a tag that can last end to end.
And the answer to that is going to reside on layer three tags.
So how are we going to do this?
Well, we need something that's going to go into both the IPv4 and IPv6 header
since it's layer three.
And we're going to find that they actually end up using the same mechanism.
So within the world of IPv4, we have this field known as type of service. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So within the world of IPv4, we have this field known as type of service.
And the type of service as an entire field, this is a one byte field,
this was defined very early on in the world of networking in the world of diff
serve.
The idea was to allow us to tag the packet, but we didn't really know how we
wanted to do it.
So originally we were only given three bits.
So three out of the eight, we're going to be used as a tag and the rest was
reserved.
Now what we're going to find in the modern network is we've actually used all WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now what we're going to find in the modern network is we've actually used all
of these bits.
And so we're going to talk about all of these, but this was the original
implementation of this field.
And we'll often see it referred to as the TOS or the type of service.
So be aware of that terminology.
So again, in this original world, we took these three bits and we called this
IP precedence.
A way of saying that we want to be able to show preference or precedence, I WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
A way of saying that we want to be able to show preference or precedence, I
suppose, to specific packets.
And so three bits, well, this seems familiar.
This is going to result in eight numbers from zero to seven.
And we'll find that this pretty well aligns with class of service.
So for example, five is going to be used for voice over IP.
Zero is going to be used for best effort and so on and so forth.
I worked out really well to align the two so that if we had a packet and this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I worked out really well to align the two so that if we had a packet and this
packet,
well, technically an ethernet frame, I suppose, has a COS of five here in the
ethernet header.
Well, then we create the IPV forehead and inside of that type of service, we
insert an IP precedence value of five as well.
And so these values match and we have something that works for layer two
devices.
We have something that works for layer three devices and provides the end end
mechanism.
Even if we were to send this frame across a non-trunk link where we lose COS, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Even if we were to send this frame across a non-trunk link where we lose COS,
IP precedence is going to stay.
Even if we send it across something like a T1, yeah, we lose the ethernet frame
header,
but we do keep the IPV forehead of course.
And therefore we keep IP precedence.
Well, eventually we decided as part of this whole diff serve mechanism that we
needed a few more bits.
And so the industry said, you know, we're going to add three bits inside of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so the industry said, you know, we're going to add three bits inside of
this type of service field.
And we're going to call this the differentiated services, which I'm abbrevi
ating because of the fact that this is part of the diff serve model,
but the differentiated services code point, quite a mouthful.
And we refer to this as DSCP.
So because we add three bits, this, I guess we'll write it down here, has a
total now of six bits, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
total now of six bits,
which gives us a full range of zero to 63 for 64 total values.
Yeah, that is a whole lot.
It allows for us to have up to 64 different traffic classes in our network.
So if we wanted, for example, to use class of service, we know that we lost COS
of six and seven to being reserved and COS of zeros,
at a fault and best effort. And so right away, we only had five values, one of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
at a fault and best effort. And so right away, we only had five values, one of
which is reserved for voice over IP.
And so we could argue we only get half of the values, really just four
additional traffic classes on top of voice over IP when we're talking about
only having three bits.
Well, six bits now, even with all of those gone, we've still got so many more
classes.
Now, do we actually need that many? Well, that's a good question. In fact, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, do we actually need that many? Well, that's a good question. In fact,
using these many values, just as raw methods of tagging our packets could get a
little bit cumbersome.
And try to keep track of what's the difference between a tag of 41 and 32 and
17.
And I mentioned earlier, like a consultant coming in and coming in and seeing
all of these maybe different tags that we have deployed in our network and
trying to figure out which tag means which.
And so once again, the industry has provided us with basically some
standardized values that get mapped to human readable names. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
standardized values that get mapped to human readable names.
Kind of like how I know that I can go to www.cisco.com, but I don't know the
value behind it. I don't know the IP address of Cisco.com, but I do know the
names.
This is for the sake of human readability and us humans to be able to remember
the different names.
And so these names have a term that we refer to as per hop behaviors or PHBs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so these names have a term that we refer to as per hop behaviors or PHBs.
This name should sound familiar because we referred to this earlier as part of
that diff serve model to say that if we're going to have independent routers
and
independent devices take traffic and send them on to other devices that we need
to deploy what we called per hop behavior.
So now we're sort of zooming out and globally suggesting that we have per hop WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now we're sort of zooming out and globally suggesting that we have per hop
behaviors defined.
For example, a particular behavior, I might want to have 15% of network traffic
.
This would be a per hop behavior, but I need to deploy that on all of these
devices.
And so now I can look at a particular DSCP value based on a name, not a number,
and know a little bit more about what's happening there.
The most common example of this is known as expedited forwarding or EF. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The most common example of this is known as expedited forwarding or EF.
Expedited forwarding is simply put a value taken from the DSCP range and that
value is 46.
This value is to be assigned to voice over IP because it maps out a very high
level of priority on the network.
Now I still have to configure my routers to have that policy and to enforce
that policy.
But now we have this sort of industry standard option of saying I'm going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But now we have this sort of industry standard option of saying I'm going to
use this DSCP value, which is sort of arbitrary.
I mean there's probably some good reasons for picking 46 rather, as opposed to
47 I was going to say.
But at the same time it is just a number to us.
But once we configure that number and say, hey, you know what, these routers
need to look for a DSCP value that matches EF.
And yes, Cisco syntax allows us to specify a value of EF and it will know and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And yes, Cisco syntax allows us to specify a value of EF and it will know and
understand that we're talking about DSCP 46.
So again, the name in this case would be EF, the value would be 46 and I as a
human can more likely remember expedited forwarding or EF.
We're also going to see that we have the concept of assured forwarding and this
would be AF.
And then these have a bunch of numbers after it and so say X and Y here and we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then these have a bunch of numbers after it and so say X and Y here and we
'll see exactly how that works coming up in the next video.
But ultimately DSCP allows for extremely granular control over our QOS because
of the sheer number of traffic classes.
We can have up to 64 of those and so it does help us to have some names carved
out that we can use rather than trying to track 64 different classes in our own
networks.
Now lastly, just worth noting that if we're doing our math here, we might
remember that we've got two more bits here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
remember that we've got two more bits here.
And so those last two bits in the type of service field, these are now part of
an explicit congestion notification mechanism.
The idea of ECN is for TCP to be able to react to congestion before packets are
lost.
If we think about how TCP operates, I send packets and send packets and I'm WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we think about how TCP operates, I send packets and send packets and I'm
ramping up my window size and thinking everything is good.
But then all of a sudden a packet doesn't go through and a packet doesn't go
through and then I ramp down my window size because things are clearly congest
ed.
Well, ECN asks the question basically, why do we have to lose these packets
before we tune things down?
This router knows that it's congested and because it's congested, it should be
able to inform this device that, hey, we have some congestion happening. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
able to inform this device that, hey, we have some congestion happening.
And so when that congestion ends up happening, we do send a packet marked with
those ECN bits as those last two bits in the type of service field.
A device that is equipped to process that will recognize that and perform the
drop down of services as far as how its window sizes are, etc.
And that way we can hopefully keep sending traffic and not actually have to
lose this data in order to see that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
lose this data in order to see that.
So kind of a nifty feature, thought I would mention it because we might be
wondering what those last two bits are for.
Now, the other thing we mentioned was IPv6. So is there any difference in all
of this with IPv6?
And the answer is largely no. IPv6 is the exact same with its IP precedence,
with its DSEP, with its expedited or not expedited forwarding, but the ECN, the
explicit congestion notifications, the difference is that the name is no longer WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
explicit congestion notifications, the difference is that the name is no longer
type of service.
Instead, that byte is now known as the traffic class.
So the only thing we have different with IPv6 is the name of the field. And so
everything else fortunately is the same.
And we can carry this information between IPv4 and IPv6 types of deployments.