So let's talk about DSCP. DSCP is a 6-bit field inside of the IP header, so this
applies to actually IPv4 and IPv6. And if we do our binary math there, 2 to the 6
power, that means we have 64 different values which range from 0 to 63. So
remember, the goal is to tag our packets with a value, one of these decimal values
0 to 63, leveraging these 6 binary bits. And we're going to inform our devices
what type of traffic it is based on the DSCP tag. So now I can take a traffic
type, let's say again voice over IP, and I can give it a tag. And this tag is
technically arbitrary. I could give it a tag of 10, as long as my device, my
router in this case, knows that a tag of 10 gets placed into, let's say the low
latency queue, queue number whatever that is, in our policy. As long as the
router knows this, then it's going to apply or be able to apply the packet
into the correct queue. However, what is, or do we want this to be completely
arbitrary? I guess that's the question we need to ask. Because if I'm a network
admin and I'm going around to different jobs, let's say I take a new job and I'm
working on a new network, or maybe I'm a consultant and I'm going from network
to network, well if it's a tag of 10 represents voice over IP at one location
and a tag of 20 is used at a completely different location, and for that matter
if I'm a network admin working for one network and I'm applying a tag of 10 at
a subset of sites and another network admin is applying a tag of 20, well that
starts to cause a lot of problems. And so what we want to do is to create a
little bit of standardization to create some standard values for specific
purposes. And these standard values are known in DSCP as per hop behaviors.
Again, to be clear, the routers don't care what values we use. They're just
going to apply whatever policy that we define. This is for the sake of us humans.
We want to be able to look at a value and know that value usually means XYZ,
whatever that is. So we don't just want to use an arbitrary value of 20 or an
arbitrary value of 10. For example, we have a PHB, a per hop behavior, of
expedited forwarding, we call it, or EF. And EF is matched to DSCP-46. That
chosen, but either way it's a fairly high value and this typically is used for
voice over IP. So DSCP-46, we could look at that and say, okay, well again,
that's great that we're all agreeing that DSCP-46 should match to voice over
IP, but human readability becomes a slight problem because I might be able to
memorize one value, but what if I have to memorize 12 different values? How do I
keep track of them all? Well, rather than memorizing specific values, I can
memorize a name. It's sort of like how we have IP addresses that map to URLs.
It's a lot easier for me to remember google.com than it is for me to remember
the IP address to google.com, even though the IP address is what really gets me
there on the back end. So I can configure my router to say, hey, let's apply this
policy to traffic marked with EF and it knows on the back end that it's looking
for a tag of 46. And of course the router itself is not looking for 46, it's
looking for binary bits of 101, 110. That would be the binary value of DSCP-46.
So this is cool. We know that we've now got the ability to create lots of
different per-hop behaviors here, and so let's go ahead and talk about how these
work. There's two other primary categories of per-hop behaviors besides EF, which
is sort of in a category of its own, by the way. So we have EF and next we should
learn about Assured Forwarding, or AF. So when we're looking at learning the
different PHBs, we're typically focusing on EF as a standalone value and then a
series of values within the Assured Forwarding category. There is one other
category that we'll talk about, but it's not really used. It's a little more
legacy, but we'll still talk about it. Either way, we want to focus in on
Assured Forwarding. This is going to give us 12 different classes, and usually
this is enough. I mean, we've got one class over here with EF, we have 12
different Assured Forwarding classes, and if we need more than that we might ask,
okay, well how many do we really need? I mean, yeah, we're given 64 different
values that we can use, but how many traffic classes do we actually have in
our network that we need to worry about assigning? Usually we have six or seven
or eight. That's typically what we see in our network, so having 13 classes
available is usually plenty. Now Assured Forwarding follows a specific format.
The format is this. We say it's AF and then XY with two different values. X is
the priority value or priority level, and it ranges from 1 to 4, and the higher
the value, the higher the priority. So we want this to be high. The other value, Y,
is our drop likelihood, or maybe we call it dropability. Sure, we'll call it
dropability. So how likely are we to drop this packet compared to other values or
other packets that are in the same priority level? So we start with a
priority level of, let's say, 1, but then we can have a dropability range from 1
to 3, and what's interesting here is the higher the value, it's the higher the
drop rate. So we have to be a little bit careful here because we might think that
a value of 3 means it's a higher priority level and therefore it shouldn't be
dropped as much, but we're actually saying that a 3 is likely to be dropped more
well, probably the treatment compared to other priority levels. We'll look at a few
examples of this coming up, but the first thing we need to recognize is that there
is a relationship between a DSCP value, again, that 0 to 63, and the AF-AFXY
value that we just talked about. This has to do with these 6 bits, and again, we
don't want to drill too deep into this, but we're going to find that we have 6
bits, and we'll just say, let's just say something like 010 and 010. So when it
comes to assured forwarding, X is going to say what these 3 bits are. Now I'm not,
I'm basically treating these bits like they're not there, so I'm just going to
read this as 010, so this would mean X equals 2. Over here, Y is going to look at
these 2 bits, so in this case, Y would equal 1, because I'm just looking at these
2 bits, treating all the other bits like they're not there. This last bit right
here is always a 0, and that's why we're going to find that when we start breaking
down assured forwarding values, that it's always a multiple of 2, because in order
kind of interesting how this pans out. The Y value is independently a value that
is multiplied by the 2's position, whereas the X value is an independent value,
again like we said it's 2, except it's multiplied by the 8's position. So again,
we've got the 1 and the 2 and the 4 and the 8's position, and then of course 16
and 32 and so on and so forth. Why do I bring that up? Well because if I want to
translate a value, let's say AF of, well we'll just say XY again, what decimal
value is that going to be? Well I've got a really cool formula for this. I simply
take my X value, multiply it by 8, so 8X, and then I add my Y value, which is
multiplied by 2, plus 2Y. A little bit of algebra feels like maybe in here, but in
the end this is going to give us a really simple formula that tells us how to
multiply this out. So for example, if I were to say it's an AF41, we're going to
take 8 times 4, plus 2 times 1. 4 here, 4 here, 1 here, 1 here, and it fits into
that formula. So that would be 32 plus 2. That is a decimal value of 34. A very
simple way to calculate this. And if I wanted to work in reverse, like starting
with 34, I just take out as many 8's as I could to start with, figure out how many
8's there are, and then whatever's left, divide by 2, and that tells me how many
2's there are. So it can work both ways. So that is how we can perform math
calculations, but just be aware of that concept. So in the end, though, we have
these 12 classes, and it's important for us to recognize this. So we've got, for
example, AF4D1 through AF43. So what is this used for? Typically, we are going to
be using AF40-whatever, 41, 42, 43, for our video traffic. So remember, VoiceOver
IP has its own category over here. We don't need to fit it into this. We usually
put video traffic in here or otherwise high-priority traffic. Always remember
again that 43 is going to be more likely to be dropped than 41. So I've got three
different classes within this priority level. And we're going to find that this
applies to all of these. So AF, I'll just start saying 3X here. So 31, 32, 33. This
is typically used for our critical traffic, and this is up to us as an organization
to define. AF2X is going to be transactional, so sort of data transfers
and whatnot, although we also have AF1X, which is for bulk traffic. So really
talking about backups and something that consumes lots of bandwidth and sends
very large packet sizes. Now at the end of all of this, we still have a DSCP value
of zero, and this is typically used to represent our best effort, or really what
we mean to say here is that it's all the rest of the traffic that's either unmarked
or uncategorized. So really, I said 13 classes earlier. We technically have a
14th class here that we're likely to use in every single one of our networks. Now
again, we're not likely to use all 12 of these, but they are available to us as much
as we would like to use them. So I mentioned that there's a third category.
This third category is known as Class Selector, which is abbreviated as CS.
Class Selector was created to allow us to migrate from IP precedent to DSCP,
and Class Selector is fairly straightforward. We are simply going to only use the first
three bits, which means whatever Class Selector we pick, it basically just represents
X, and it's multiplied by 8. What are we saying there? Well, if I have a CS of 1,
this is mapping to a DSCP value of 8. I simply multiply 1 by 8, and then I can have
CS of 2, which maps to 16, and so on and so forth. So we can go from CS0 all the way
to CS7, and now the only place primarily that we still see Class Selector in use is
occasionally we will see it used down here as sort of a bottom-of-the-barrel level
of priority, and truly worse even than best effort, and we refer to this as
scavenger class. This is typically marked as CS1, and what we are saying is kind of
going back to that concept. Remember, we said best effort is not traffic we don't
care about. We care greatly about our best effort traffic. It does need to go through.
We cannot starve it. Scavenger traffic, on the other hand, if our network has traffic
that fits into this category, is traffic that is very droppable. In fact, we would
even say that it's starvable. Like, if we are having network congestion, then
completely cut this traffic off. We do not want it on our network. So there are
certain processes and things like that that we might say, hey, that's traffic that
would fit into the scavenger class. Again, all of the assignment of all these
categories is going to be based on the organizational need, but generally
speaking, what we've done, again, is we've created a bunch of standard values that
we now have names for. We don't have to worry about the DSCP values. I don't have
to define it that way, although as a network engineer, I might want to be able
to translate it, but I don't have to worry too much about that. I can now look at a
value like an AF33 or an AF113 or 12. I should be able to know what exactly that
represents and how I can apply that into my network.