WEBVTT 1 00:00.000 --> 00:04.680 So as we mentioned, we need a tag that can last end to end. 2 00:04.680 --> 00:10.120 And the answer to that is going to reside on layer three tags. 3 00:10.120 --> 00:11.440 So how are we going to do this? 4 00:11.440 --> 00:17.360 Well, we need something that's going to go into both the IPv4 and IPv6 header 5 00:17.360 --> 00:19.000 since it's layer three. 6 00:19.000 --> 00:23.560 And we're going to find that they actually end up using the same mechanism. 7 00:23.560 --> 00:30.480 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 7 00:23.560 --> 00:30.480 So within the world of IPv4, we have this field known as type of service. 8 00:30.480 --> 00:35.280 And the type of service as an entire field, this is a one byte field, 9 00:35.280 --> 00:40.220 this was defined very early on in the world of networking in the world of diff 10 00:40.220 --> 00:41.000 serve. 11 00:41.000 --> 00:45.600 The idea was to allow us to tag the packet, but we didn't really know how we 12 00:45.600 --> 00:46.360 wanted to do it. 13 00:46.360 --> 00:50.920 So originally we were only given three bits. 14 00:50.920 --> 00:56.670 So three out of the eight, we're going to be used as a tag and the rest was 15 00:56.670 --> 00:59.000 reserved. 16 00:59.000 --> 01:02.840 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 16 00:59.000 --> 01:02.840 Now what we're going to find in the modern network is we've actually used all 17 01:02.840 --> 01:03.560 of these bits. 18 01:03.560 --> 01:06.960 And so we're going to talk about all of these, but this was the original 19 01:06.960 --> 01:09.600 implementation of this field. 20 01:09.600 --> 01:13.720 And we'll often see it referred to as the TOS or the type of service. 21 01:13.720 --> 01:16.200 So be aware of that terminology. 22 01:16.200 --> 01:22.130 So again, in this original world, we took these three bits and we called this 23 01:22.130 --> 01:25.040 IP precedence. 24 01:25.040 --> 01:30.490 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 24 01:25.040 --> 01:30.490 A way of saying that we want to be able to show preference or precedence, I 25 01:30.490 --> 01:33.880 suppose, to specific packets. 26 01:33.880 --> 01:37.360 And so three bits, well, this seems familiar. 27 01:37.360 --> 01:41.520 This is going to result in eight numbers from zero to seven. 28 01:41.520 --> 01:47.400 And we'll find that this pretty well aligns with class of service. 29 01:47.400 --> 01:51.400 So for example, five is going to be used for voice over IP. 30 01:51.400 --> 01:56.440 Zero is going to be used for best effort and so on and so forth. 31 01:56.440 --> 02:01.810 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 31 01:56.440 --> 02:01.810 I worked out really well to align the two so that if we had a packet and this 32 02:01.810 --> 02:02.480 packet, 33 02:02.480 --> 02:07.520 well, technically an ethernet frame, I suppose, has a COS of five here in the 34 02:07.520 --> 02:09.520 ethernet header. 35 02:09.520 --> 02:15.050 Well, then we create the IPV forehead and inside of that type of service, we 36 02:15.050 --> 02:20.160 insert an IP precedence value of five as well. 37 02:20.160 --> 02:24.050 And so these values match and we have something that works for layer two 38 02:24.050 --> 02:24.720 devices. 39 02:24.720 --> 02:28.780 We have something that works for layer three devices and provides the end end 40 02:28.780 --> 02:29.440 mechanism. 41 02:29.440 --> 02:35.040 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 41 02:29.440 --> 02:35.040 Even if we were to send this frame across a non-trunk link where we lose COS, 42 02:35.040 --> 02:36.960 IP precedence is going to stay. 43 02:36.960 --> 02:41.040 Even if we send it across something like a T1, yeah, we lose the ethernet frame 44 02:41.040 --> 02:41.680 header, 45 02:41.680 --> 02:44.680 but we do keep the IPV forehead of course. 46 02:44.680 --> 02:47.800 And therefore we keep IP precedence. 47 02:47.800 --> 02:54.400 Well, eventually we decided as part of this whole diff serve mechanism that we 48 02:54.400 --> 02:56.480 needed a few more bits. 49 02:56.480 --> 03:02.800 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 49 02:56.480 --> 03:02.800 And so the industry said, you know, we're going to add three bits inside of 50 03:02.800 --> 03:05.440 this type of service field. 51 03:05.440 --> 03:11.740 And we're going to call this the differentiated services, which I'm abbrevi 52 03:11.740 --> 03:15.200 ating because of the fact that this is part of the diff serve model, 53 03:15.200 --> 03:20.920 but the differentiated services code point, quite a mouthful. 54 03:20.920 --> 03:24.080 And we refer to this as DSCP. 55 03:24.080 --> 03:29.570 So because we add three bits, this, I guess we'll write it down here, has a 56 03:29.570 --> 03:33.520 total now of six bits, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 56 03:29.570 --> 03:33.520 total now of six bits, 57 03:33.520 --> 03:40.480 which gives us a full range of zero to 63 for 64 total values. 58 03:40.480 --> 03:42.440 Yeah, that is a whole lot. 59 03:42.440 --> 03:49.000 It allows for us to have up to 64 different traffic classes in our network. 60 03:49.000 --> 03:54.360 So if we wanted, for example, to use class of service, we know that we lost COS 61 03:54.360 --> 03:57.840 of six and seven to being reserved and COS of zeros, 62 03:57.840 --> 04:02.460 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 62 03:57.840 --> 04:02.460 at a fault and best effort. And so right away, we only had five values, one of 63 04:02.460 --> 04:04.720 which is reserved for voice over IP. 64 04:04.720 --> 04:08.340 And so we could argue we only get half of the values, really just four 65 04:08.340 --> 04:13.140 additional traffic classes on top of voice over IP when we're talking about 66 04:13.140 --> 04:14.960 only having three bits. 67 04:14.960 --> 04:20.070 Well, six bits now, even with all of those gone, we've still got so many more 68 04:20.070 --> 04:20.960 classes. 69 04:20.960 --> 04:32.280 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 69 04:20.960 --> 04:32.280 Now, do we actually need that many? Well, that's a good question. In fact, 70 04:32.280 --> 04:32.280 using these many values, just as raw methods of tagging our packets could get a 71 04:32.280 --> 04:32.320 little bit cumbersome. 72 04:32.320 --> 04:39.220 And try to keep track of what's the difference between a tag of 41 and 32 and 73 04:39.220 --> 04:40.160 17. 74 04:40.160 --> 04:44.160 And I mentioned earlier, like a consultant coming in and coming in and seeing 75 04:44.160 --> 04:48.610 all of these maybe different tags that we have deployed in our network and 76 04:48.610 --> 04:50.920 trying to figure out which tag means which. 77 04:50.920 --> 04:58.810 And so once again, the industry has provided us with basically some 78 04:58.810 --> 05:05.640 standardized values that get mapped to human readable names. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 78 04:58.810 --> 05:05.640 standardized values that get mapped to human readable names. 79 05:05.640 --> 05:12.350 Kind of like how I know that I can go to www.cisco.com, but I don't know the 80 05:12.350 --> 05:17.520 value behind it. I don't know the IP address of Cisco.com, but I do know the 81 05:17.520 --> 05:18.120 names. 82 05:18.120 --> 05:25.080 This is for the sake of human readability and us humans to be able to remember 83 05:25.080 --> 05:27.400 the different names. 84 05:27.400 --> 05:36.840 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 84 05:27.400 --> 05:36.840 And so these names have a term that we refer to as per hop behaviors or PHBs. 85 05:36.840 --> 05:43.080 This name should sound familiar because we referred to this earlier as part of 86 05:43.080 --> 05:47.640 that diff serve model to say that if we're going to have independent routers 87 05:47.640 --> 05:47.840 and 88 05:47.840 --> 05:53.860 independent devices take traffic and send them on to other devices that we need 89 05:53.860 --> 05:57.160 to deploy what we called per hop behavior. 90 05:57.160 --> 06:02.480 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 90 05:57.160 --> 06:02.480 So now we're sort of zooming out and globally suggesting that we have per hop 91 06:02.480 --> 06:04.200 behaviors defined. 92 06:04.200 --> 06:09.360 For example, a particular behavior, I might want to have 15% of network traffic 93 06:09.360 --> 06:09.440 . 94 06:09.440 --> 06:13.980 This would be a per hop behavior, but I need to deploy that on all of these 95 06:13.980 --> 06:14.880 devices. 96 06:14.880 --> 06:21.360 And so now I can look at a particular DSCP value based on a name, not a number, 97 06:21.360 --> 06:25.400 and know a little bit more about what's happening there. 98 06:25.400 --> 06:34.400 The most common example of this is known as expedited forwarding or EF. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 98 06:25.400 --> 06:34.400 The most common example of this is known as expedited forwarding or EF. 99 06:34.400 --> 06:40.360 Expedited forwarding is simply put a value taken from the DSCP range and that 100 06:40.360 --> 06:41.960 value is 46. 101 06:41.960 --> 06:48.890 This value is to be assigned to voice over IP because it maps out a very high 102 06:48.890 --> 06:52.400 level of priority on the network. 103 06:52.400 --> 06:58.720 Now I still have to configure my routers to have that policy and to enforce 104 06:58.720 --> 06:59.880 that policy. 105 06:59.880 --> 07:04.860 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 105 06:59.880 --> 07:04.860 But now we have this sort of industry standard option of saying I'm going to 106 07:04.860 --> 07:08.280 use this DSCP value, which is sort of arbitrary. 107 07:08.280 --> 07:14.450 I mean there's probably some good reasons for picking 46 rather, as opposed to 108 07:14.450 --> 07:16.080 47 I was going to say. 109 07:16.080 --> 07:20.320 But at the same time it is just a number to us. 110 07:20.320 --> 07:24.760 But once we configure that number and say, hey, you know what, these routers 111 07:24.760 --> 07:28.880 need to look for a DSCP value that matches EF. 112 07:28.880 --> 07:35.350 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 112 07:28.880 --> 07:35.350 And yes, Cisco syntax allows us to specify a value of EF and it will know and 113 07:35.350 --> 07:39.200 understand that we're talking about DSCP 46. 114 07:39.200 --> 07:44.570 So again, the name in this case would be EF, the value would be 46 and I as a 115 07:44.570 --> 07:49.400 human can more likely remember expedited forwarding or EF. 116 07:49.400 --> 07:54.780 We're also going to see that we have the concept of assured forwarding and this 117 07:54.780 --> 07:55.960 would be AF. 118 07:55.960 --> 08:00.480 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 118 07:55.960 --> 08:00.480 And then these have a bunch of numbers after it and so say X and Y here and we 119 08:00.480 --> 08:03.840 'll see exactly how that works coming up in the next video. 120 08:03.840 --> 08:08.990 But ultimately DSCP allows for extremely granular control over our QOS because 121 08:08.990 --> 08:11.600 of the sheer number of traffic classes. 122 08:11.600 --> 08:17.040 We can have up to 64 of those and so it does help us to have some names carved 123 08:17.040 --> 08:22.170 out that we can use rather than trying to track 64 different classes in our own 124 08:22.170 --> 08:22.960 networks. 125 08:22.960 --> 08:28.110 Now lastly, just worth noting that if we're doing our math here, we might 126 08:28.110 --> 08:30.720 remember that we've got two more bits here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 126 08:28.110 --> 08:30.720 remember that we've got two more bits here. 127 08:30.720 --> 08:40.210 And so those last two bits in the type of service field, these are now part of 128 08:40.210 --> 08:44.360 an explicit congestion notification mechanism. 129 08:49.800 --> 08:56.370 The idea of ECN is for TCP to be able to react to congestion before packets are 130 08:56.370 --> 08:57.160 lost. 131 08:57.160 --> 09:02.030 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 131 08:57.160 --> 09:02.030 If we think about how TCP operates, I send packets and send packets and I'm 132 09:02.030 --> 09:05.480 ramping up my window size and thinking everything is good. 133 09:05.480 --> 09:08.290 But then all of a sudden a packet doesn't go through and a packet doesn't go 134 09:08.290 --> 09:14.060 through and then I ramp down my window size because things are clearly congest 135 09:14.060 --> 09:14.520 ed. 136 09:14.520 --> 09:20.320 Well, ECN asks the question basically, why do we have to lose these packets 137 09:20.320 --> 09:22.720 before we tune things down? 138 09:22.720 --> 09:28.430 This router knows that it's congested and because it's congested, it should be 139 09:28.430 --> 09:33.160 able to inform this device that, hey, we have some congestion happening. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 139 09:28.430 --> 09:33.160 able to inform this device that, hey, we have some congestion happening. 140 09:33.160 --> 09:39.850 And so when that congestion ends up happening, we do send a packet marked with 141 09:39.850 --> 09:44.360 those ECN bits as those last two bits in the type of service field. 142 09:44.360 --> 09:50.070 A device that is equipped to process that will recognize that and perform the 143 09:50.070 --> 09:55.200 drop down of services as far as how its window sizes are, etc. 144 09:55.200 --> 09:59.400 And that way we can hopefully keep sending traffic and not actually have to 145 09:59.400 --> 10:01.640 lose this data in order to see that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 145 09:59.400 --> 10:01.640 lose this data in order to see that. 146 10:01.640 --> 10:05.060 So kind of a nifty feature, thought I would mention it because we might be 147 10:05.060 --> 10:07.320 wondering what those last two bits are for. 148 10:07.320 --> 10:13.090 Now, the other thing we mentioned was IPv6. So is there any difference in all 149 10:13.090 --> 10:14.840 of this with IPv6? 150 10:14.840 --> 10:21.880 And the answer is largely no. IPv6 is the exact same with its IP precedence, 151 10:21.880 --> 10:27.730 with its DSEP, with its expedited or not expedited forwarding, but the ECN, the 152 10:27.730 --> 10:34.000 explicit congestion notifications, the difference is that the name is no longer WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 152 10:27.730 --> 10:34.000 explicit congestion notifications, the difference is that the name is no longer 153 10:34.000 --> 10:35.320 type of service. 154 10:35.320 --> 10:40.360 Instead, that byte is now known as the traffic class. 155 10:40.360 --> 10:45.640 So the only thing we have different with IPv6 is the name of the field. And so 156 10:45.640 --> 10:48.000 everything else fortunately is the same. 157 10:48.000 --> 10:53.320 And we can carry this information between IPv4 and IPv6 types of deployments.