WEBVTT 0:00:05.680000 --> 0:00:09.260000 So far in this video series, I've referenced this term, Ethernet frame 0:00:09.260000 --> 0:00:12.440000 quite a bit, but we haven't really looked at what is that. 0:00:12.440000 --> 0:00:16.460000 In other words, I've said that when your NIC card sends out its bits, 0:00:16.460000 --> 0:00:20.520000 it gathers them and formats them into this thing, the structure, this 0:00:20.520000 --> 0:00:23.980000 protocol data unit called an Ethernet frame. 0:00:23.980000 --> 0:00:27.860000 Then it uses carrier sense, multiple access to know when it can send the 0:00:27.860000 --> 0:00:31.300000 frame, and if the frame has collided with anything else. 0:00:31.300000 --> 0:00:32.860000 But was the frame actually look like? 0:00:32.860000 --> 0:00:35.960000 Well, let's take a look at them. 0:00:35.960000 --> 0:00:40.800000 So in the original Ethernet implementation and then an Ethernet version 0:00:40.800000 --> 0:00:47.020000 2, which is called Ethernet Dix here for digital Intel and Xerox, we can 0:00:47.020000 --> 0:00:50.240000 see the original Ethernet frame structure up top. 0:00:50.240000 --> 0:00:51.940000 And then when Dr. 0:00:51.940000 --> 0:00:56.900000 Robert Metcalf and some of his engineering friends formed the 802.comity, 0:00:56.900000 --> 0:01:00.540000 the 802. And then they formed the 802.3 working group. 0:01:00.540000 --> 0:01:07.220000 They modified a little bit and 802.3 looks almost the same as Ethernet, 0:01:07.220000 --> 0:01:10.260000 but you can see here the main change is that while Ethernet had a type 0:01:10.260000 --> 0:01:13.300000 code, 802.3 has a length field. 0:01:13.300000 --> 0:01:16.540000 So let's dig into each one of these fields here and see what do these 0:01:16.540000 --> 0:01:17.580000 fields represent? 0:01:17.580000 --> 0:01:18.920000 What are they used for? 0:01:18.920000 --> 0:01:24.720000 So let's start with the first field, the pre-ed. 0:01:24.720000 --> 0:01:30.940000 So the preamble is 7 bytes of this recurring pattern called 10101010. 0:01:30.940000 --> 0:01:32.040000 So that's the preamble. 0:01:32.040000 --> 0:01:35.620000 And the purpose of the preamble is simply so that the receiving device 0:01:35.620000 --> 0:01:37.920000 can synchronize its clocking. 0:01:37.920000 --> 0:01:42.820000 In other words, the receiving device will know exactly when to scan the 0:01:42.820000 --> 0:01:47.940000 wire, probe the wire to make sure it picks up a 1, picks up a 0. 0:01:47.940000 --> 0:01:53.080000 Because remember the way Ethernet works is that I'm going to hold my voltage 0:01:53.080000 --> 0:01:58.300000 up to a certain level for a certain amount of time to represent a 1. 0:01:58.300000 --> 0:01:59.900000 Then I'm going to let it go. 0:01:59.900000 --> 0:02:03.240000 I'm going to wait a few nanoseconds and then hold it up to a different 0:02:03.240000 --> 0:02:06.900000 level for a amount of time for a 0. 0:02:06.900000 --> 0:02:13.360000 So if I'm sending this to you, your receiving circuitry has to be monitoring 0:02:13.360000 --> 0:02:19.260000 that wire at the precise time to look when to get that voltage level, 0:02:19.260000 --> 0:02:21.020000 to know when to see the 1s and 0s. 0:02:21.020000 --> 0:02:22.600000 So the clocking has to be the same. 0:02:22.600000 --> 0:02:26.080000 If I'm putting the bits on the wire at this rate, you have to be sampling 0:02:26.080000 --> 0:02:28.920000 the bits off the wire at the same rate. 0:02:28.920000 --> 0:02:34.080000 So in order to ensure that, we have the 7 bytes here of the preamble. 0:02:34.080000 --> 0:02:38.560000 And after that, we have one more byte called the start of frame delimiter, 0:02:38.560000 --> 0:02:40.740000 the start of frame delimiter. 0:02:40.740000 --> 0:02:45.120000 Now what does 543 rule have to do? 0:02:45.120000 --> 0:02:48.940000 This is just some sort of like historic artifact, but I thought you might 0:02:48.940000 --> 0:02:51.620000 find an interesting case you ever ran across it. 0:02:51.620000 --> 0:02:57.840000 So in the old days of Ethernet, the 543 rule simply said this. 0:02:57.840000 --> 0:03:02.280000 That, you know, Ethernet when it was developed, one of the things they 0:03:02.280000 --> 0:03:11.800000 had to determine was, when I put a bit on the wire, a 1 or a 0, how far 0:03:11.800000 --> 0:03:13.200000 do I want it to go? 0:03:13.200000 --> 0:03:16.680000 Because think about how this is actually happening at the physical layer. 0:03:16.680000 --> 0:03:20.240000 It's like I'm putting some electrical energy on the wire, and my rule 0:03:20.240000 --> 0:03:24.760000 state has to be a certain level held at a certain amount of time, so that 0:03:24.760000 --> 0:03:28.740000 you can recognize it as a 1 or a 0. 0:03:28.740000 --> 0:03:31.320000 Here's the thing with electrical energy though. 0:03:31.320000 --> 0:03:35.640000 If you put electrical energy on the wire, the farther and farther it gets 0:03:35.640000 --> 0:03:40.100000 away from the source, it becomes what's called attenuated. 0:03:40.100000 --> 0:03:43.500000 Attenuated means that electrical energy gets more and more dissipated 0:03:43.500000 --> 0:03:46.540000 less and less what it looked like at the beginning. 0:03:46.540000 --> 0:03:50.460000 So if I put a nice, nice solid wave on the wire, you know, I'm holding 0:03:50.460000 --> 0:03:54.460000 it a nice solid consistency for a certain amount of time, then I let it 0:03:54.460000 --> 0:04:01.660000 go, that wave gets sort of distorted the further and further you go away 0:04:01.660000 --> 0:04:02.840000 from the source. 0:04:02.840000 --> 0:04:05.660000 That's called attenuation. 0:04:05.660000 --> 0:04:10.200000 So if I have two things that are really close to each other, there's not 0:04:10.200000 --> 0:04:11.620000 much attenuation there. 0:04:11.620000 --> 0:04:14.040000 So I don't have to use a whole lot of electrical energy. 0:04:14.040000 --> 0:04:18.280000 I don't have to use a big massive battery or a big electrical source to 0:04:18.280000 --> 0:04:21.980000 put energy on that wire because the receiving device is so close to me 0:04:21.980000 --> 0:04:25.820000 that the electrical energy won't change much between point A and point 0:04:25.820000 --> 0:04:31.720000 B. But if point A and point B are really far apart, and I know that that 0:04:31.720000 --> 0:04:35.080000 electrical energy is going to dissipate by a 3. 0:04:35.080000 --> 0:04:37.900000 So if I have to think to myself, okay, well if they're going to be really 0:04:37.900000 --> 0:04:40.780000 far apart, that means the electrical energy at the beginning has to be 0:04:40.780000 --> 0:04:44.780000 really strong. So that by the time it gets here, even though it's gotten 0:04:44.780000 --> 0:04:49.380000 weaker, it's still strong enough for point B to be able to receive it 0:04:49.380000 --> 0:04:52.580000 and to be able to tell that it's a 1 or a 0. 0:04:52.580000 --> 0:04:54.360000 So it's a trade-off, it's a balance. 0:04:54.360000 --> 0:04:59.280000 So the desires of ethernet said, well, we could make it to where we support 0:04:59.280000 --> 0:05:04.020000 really long cables of like a mile or two miles but our electrical source 0:05:04.020000 --> 0:05:08.560000 is going to be huge, huge electrical battery or lots of voltage so that 0:05:08.560000 --> 0:05:10.300000 it goes that far. 0:05:10.300000 --> 0:05:13.120000 Or we could take the opposite approach. 0:05:13.120000 --> 0:05:15.720000 We could design this as a technology of, well, it's really only meant 0:05:15.720000 --> 0:05:19.940000 to connect two devices sitting on a table that are like two feet apart 0:05:19.940000 --> 0:05:20.860000 from each other. 0:05:20.860000 --> 0:05:24.900000 That way we won't have to use very much electrical energy. 0:05:24.900000 --> 0:05:28.960000 So they decided that based on certain ethernet standards, the cables would 0:05:28.960000 --> 0:05:29.660000 be certain lengths. 0:05:29.660000 --> 0:05:33.580000 So we'll actually see that coming up right here in just a moment. 0:05:33.580000 --> 0:05:37.380000 But so what I had to do with the 543 rule. 0:05:37.380000 --> 0:05:39.720000 So let's take the original implementation of ethernet. 0:05:39.720000 --> 0:05:43.580000 The original implementation of ethernet specified that a single cable 0:05:43.580000 --> 0:05:48.020000 due to electrical attenuation and everything could be no more than about 0:05:48.020000 --> 0:05:54.860000 185 meters, 185 meters end to end, which is actually pretty long. 0:05:54.860000 --> 0:05:59.420000 But what if you had a really large company like a skyscraper of 20 or 0:05:59.420000 --> 0:06:04.560000 30 stories? One cable of 185 meters wouldn't cut it. 0:06:04.560000 --> 0:06:06.340000 You needed something longer than that. 0:06:06.340000 --> 0:06:09.400000 So that's when they invented ethernet hubs or ethernet repeaters where 0:06:09.400000 --> 0:06:10.920000 you could repeat the signal. 0:06:10.920000 --> 0:06:14.560000 The idea with the repeater was, okay, when the signal comes in, strengthen 0:06:14.560000 --> 0:06:21.920000 it, refresh it and then send it out on another 185 meters of cable, potentially. 0:06:21.920000 --> 0:06:24.080000 Well, here's the problem though. 0:06:24.080000 --> 0:06:29.640000 Is that imagine I have all these cables with repeater, repeater, repeater. 0:06:29.640000 --> 0:06:33.940000 The way the repeater works is that the repeater, just like the net card 0:06:33.940000 --> 0:06:39.040000 on your laptop or PC, is listening to that cable and it's listening for 0:06:39.040000 --> 0:06:45.640000 this preamble. And the first five to maybe six bits of the preamble are 0:06:45.640000 --> 0:06:50.300000 sort of like ignored while the repeater says, okay, I think that's something. 0:06:50.300000 --> 0:06:51.800000 Yes, okay, that's a one and a zero. 0:06:51.800000 --> 0:06:54.620000 So by the time the repeater says, yeah, I got it. 0:06:54.620000 --> 0:06:56.460000 That's a one and a zero coming in. 0:06:56.460000 --> 0:06:59.680000 The first five or six bits of that preamble have been what they called 0:06:59.680000 --> 0:07:02.900000 consumed. It's sort of been dropped off. 0:07:02.900000 --> 0:07:06.240000 And so now when the repeater is taking that fame and copying it and repeating 0:07:06.240000 --> 0:07:10.360000 it, it can only copy and repeat what it could record. 0:07:10.360000 --> 0:07:13.700000 So if it wasn't able to recognize those first five or six bits at the 0:07:13.700000 --> 0:07:17.040000 front end, it can't copy and repeat them. 0:07:17.040000 --> 0:07:20.140000 So now you've got a frame that came in and now the one that's being repeated 0:07:20.140000 --> 0:07:24.120000 is a tiny little bit shorter because the first five or six bits of the 0:07:24.120000 --> 0:07:26.040000 preamble were sort of wiped out. 0:07:26.040000 --> 0:07:27.760000 It couldn't really see those. 0:07:27.760000 --> 0:07:31.720000 Now, if I've got lots of repeaters, one after the other, what does that 0:07:31.720000 --> 0:07:35.540000 mean? That means that preamble is getting shorter and shorter and shorter 0:07:35.540000 --> 0:07:38.860000 and shorter and you run the risk that by the time that ethanate frame 0:07:38.860000 --> 0:07:43.540000 gets to the destination, the preamble might not be long enough for the 0:07:43.540000 --> 0:07:47.960000 destination to lock onto it and be able to actually start sampling that 0:07:47.960000 --> 0:07:51.160000 frame. It might miss the frame entirely because there weren't enough preamble 0:07:51.160000 --> 0:07:55.580000 bits left because all these long string of repeaters consumed them one 0:07:55.580000 --> 0:07:57.180000 after the other. 0:07:57.180000 --> 0:08:01.060000 So the 543 rule was designed to solve that problem. 0:08:01.060000 --> 0:08:02.980000 They said, okay, here's what we're going to do. 0:08:02.980000 --> 0:08:07.640000 Our rule is going to state that you can have a maximum of five segments. 0:08:07.640000 --> 0:08:11.840000 That's it. No more than five segments end to end and then you're done. 0:08:11.840000 --> 0:08:16.440000 Those five segments can be connected by no more than four repeaters or 0:08:16.440000 --> 0:08:21.560000 four hubs. And only three of those five segments can actually have hosts 0:08:21.560000 --> 0:08:26.120000 on them. Two of them should just be used for transport, repeater to repeater, 0:08:26.120000 --> 0:08:27.260000 nothing in the middle. 0:08:27.260000 --> 0:08:30.280000 Three of them can have hosts connected to it. 0:08:30.280000 --> 0:08:35.300000 So that was the 543 rule and it was all designed to avoid the situation 0:08:35.300000 --> 0:08:37.800000 of what I just described. 0:08:37.800000 --> 0:08:42.360000 But that was with coaxial cable, cable that was only 185 meters. 0:08:42.360000 --> 0:08:45.760000 With today's ethanate, that's not so much of a big deal anymore. 0:08:45.760000 --> 0:08:49.740000 But just in case you ever came across that term, the 543 rule, I want 0:08:49.740000 --> 0:08:52.300000 you to know what it was talking about. 0:08:52.300000 --> 0:08:55.920000 Okay, so that's the preamble and the start of frame delimiter. 0:08:55.920000 --> 0:09:05.640000 The next field, actually the next two fields, go to something called the 0:09:05.640000 --> 0:09:10.380000 addressing fields, which is what's called a MAC address. 0:09:10.380000 --> 0:09:15.760000 So Dr. Metcalf and his friends, when they were designing the ethanate 0:09:15.760000 --> 0:09:20.400000 frame, they said, okay, this is going to be a technology where there's 0:09:20.400000 --> 0:09:22.600000 multiple devices tapped into a wire. 0:09:22.600000 --> 0:09:26.140000 Remember, the original ethanate was this big long coaxial cable stretching 0:09:26.140000 --> 0:09:31.200000 down a hallway, going up and down through floors and all these Alto Xerox 0:09:31.200000 --> 0:09:34.180000 PCs were physically tapped into it. 0:09:34.180000 --> 0:09:39.060000 So the idea was, okay, if I have multiple devices on this wire, if device 0:09:39.060000 --> 0:09:43.840000 A wants to send something to device B, device B needs to have an address. 0:09:43.840000 --> 0:09:47.780000 We need to have some way of saying, hey, this frame is for you, all the 0:09:47.780000 --> 0:09:51.940000 other devices in the wire that are also going to see the electrical energy, 0:09:51.940000 --> 0:09:55.460000 it's not for you, ignore it, it's for PCB. 0:09:55.460000 --> 0:09:59.400000 So they said, okay, that is a media access control address. 0:09:59.400000 --> 0:10:02.200000 In other words, how do we access the media? 0:10:02.200000 --> 0:10:06.160000 Media access control address, a MAC address. 0:10:06.160000 --> 0:10:11.640000 So the MAC address, they decided was going to be 48 bits long, so 48 bits 0:10:11.640000 --> 0:10:17.260000 end to end. And while laptops and PCs and everything see that as a binary 0:10:17.260000 --> 0:10:20.580000 number, of course, we as human beings can't deal with binaries, we have 0:10:20.580000 --> 0:10:22.840000 to translate that into something we can use. 0:10:22.840000 --> 0:10:26.900000 And so we see that represent as hexadecimal numbers. 0:10:26.900000 --> 0:10:32.380000 Now in the event that you have never worked with hexadecimal before, let's 0:10:32.380000 --> 0:10:34.740000 just do a quick tutorial on that. 0:10:34.740000 --> 0:10:37.500000 And if you're already familiar with hexadecimal, you can fast-frode the 0:10:37.500000 --> 0:10:42.240000 video past this section. 0:10:42.240000 --> 0:10:46.060000 So to explain hexadecimal, I briefly want to go back to something that 0:10:46.060000 --> 0:10:49.520000 you already know, which is decimal. 0:10:49.520000 --> 0:10:52.620000 So any numbers divide up by placeholders, right? 0:10:52.620000 --> 0:10:55.380000 If I have a three digit number, that means I've got a placeholder for 0:10:55.380000 --> 0:11:01.100000 three digits. And the value of those digits depends on the value of the 0:11:01.100000 --> 0:11:05.380000 placeholder. So for example, this right here, this placeholder, if we're 0:11:05.380000 --> 0:11:07.260000 talking about decimal, is the ones position. 0:11:07.260000 --> 0:11:12.940000 I can put a number from zero to nine there, and that is the ones position. 0:11:12.940000 --> 0:11:16.400000 So I could put the number, for example, seven, and that means seven times 0:11:16.400000 --> 0:11:24.880000 one. Now if we're talking decimal, which is base 10, that means every 0:11:24.880000 --> 0:11:28.740000 subsequent placeholder is a multiplier of 10. 0:11:28.740000 --> 0:11:32.780000 So we take the previous one, multiply it by 10, that gives us the tens 0:11:32.780000 --> 0:11:40.040000 position. So if I put another seven here, that means seven times 10, instead 0:11:40.040000 --> 0:11:41.420000 of seven times one. 0:11:41.420000 --> 0:11:45.700000 And then we multiply that by 10 again, and we get the hundreds. 0:11:45.700000 --> 0:11:53.400000 So now we've got 700 plus 70 plus seven, 777. 0:11:53.400000 --> 0:11:55.220000 So that's decimal. 0:11:55.220000 --> 0:12:02.320000 Now if we're talking about hexadecimal, we still have placeholders. 0:12:02.320000 --> 0:12:10.520000 But hexadecimal is a base 16 counting system, base 16. 0:12:10.520000 --> 0:12:13.880000 So the first placeholder is still the ones position. 0:12:13.880000 --> 0:12:15.920000 That doesn't change. 0:12:15.920000 --> 0:12:17.560000 But here's what's different. 0:12:17.560000 --> 0:12:29.020000 In a base 10 system, each placeholder could have a single digit ranging 0:12:29.020000 --> 0:12:31.940000 from zero to zero. 0:12:31.940000 --> 0:12:37.440000 To nine. There were 10 different combinations that could be placed in 0:12:37.440000 --> 0:12:38.960000 each one of these digits. 0:12:38.960000 --> 0:12:41.340000 In each one of these placeholders. 0:12:41.340000 --> 0:12:53.860000 Well in hexadecimal, each placeholder could have a single digit ranging 0:12:53.860000 --> 0:13:00.440000 from zero to F. You say F, what's that? 0:13:00.440000 --> 0:13:10.160000 Well in hexadecimal, you still start out with your decimal digits, zero 0:13:10.160000 --> 0:13:12.700000 through nine. That only gives us 10 digits. 0:13:12.700000 --> 0:13:14.000000 And this is a base 16. 0:13:14.000000 --> 0:13:17.380000 We need 16 things, 16 digits. 0:13:17.380000 --> 0:13:23.620000 So now we start going into letters A, B, C, D, E, and F. 0:13:23.620000 --> 0:13:30.620000 So in hexadecimal, A would be the equivalent of 10 in decimal, B would 0:13:30.620000 --> 0:13:32.520000 be the equivalent of 11. 0:13:32.520000 --> 0:13:34.640000 C would be the equivalent of 12. 0:13:34.640000 --> 0:13:39.280000 And if we keep going on up, F is the equivalent of 15. 0:13:39.280000 --> 0:13:44.100000 So in a single placeholder here, I could have from zero to F. 0:13:44.100000 --> 0:13:52.000000 So if I put, let's say, A right here, well we know that's A times one, 0:13:52.000000 --> 0:13:54.080000 well A is really the number 10 in decimal. 0:13:54.080000 --> 0:13:56.900000 So that's 10 times one, that's 10. 0:13:56.900000 --> 0:14:06.620000 If I put, let's say, three right here, well in decimal, we multiplied 0:14:06.620000 --> 0:14:11.200000 by 10. Each placeholder was a multiple of 10 from the previous placeholder. 0:14:11.200000 --> 0:14:14.600000 Well in hexadecimal, we're talking about base 16. 0:14:14.600000 --> 0:14:20.000000 So we multiply by 16, so we got one times 16, which is the 16's position. 0:14:20.000000 --> 0:14:28.660000 The next position is going to be 16 times 16, which is the 256's. 0:14:28.660000 --> 0:14:37.520000 So 3A in hexadecimal is 3 times 16, which is 48, plus 10, plus A times 0:14:37.520000 --> 0:14:38.440000 one, which is 10. 0:14:38.440000 --> 0:14:42.000000 So 48 plus 10, this is 58. 0:14:42.000000 --> 0:14:45.600000 So the hexadecimal number, hexadecimals are usually represented as zero 0:14:45.600000 --> 0:14:47.100000 X, but not always. 0:14:47.100000 --> 0:14:55.880000 So zero X3A in hexadecimal is equal to 58 in decimal. 0:14:55.880000 --> 0:15:05.200000 If I put a 2 right here, that'd be 256 times 2, plus 16 times 3, plus 0:15:05.200000 --> 0:15:10.640000 10 times 1. So why do they do it this way? 0:15:10.640000 --> 0:15:20.660000 Well when it comes to MAC addresses, I'm not going to do all of it, but 0:15:20.660000 --> 0:15:25.500000 what have we got here? 0:15:25.500000 --> 0:15:33.040000 So right now, 8 times 4, so this is 32 bits right now, out of my 48. 0:15:33.040000 --> 0:15:38.620000 So if this was the first 32 bits of my 48-bit MAC address, and I want 0:15:38.620000 --> 0:15:42.440000 to represent this in some way that was meaningful, they decide to use 0:15:42.440000 --> 0:15:47.520000 hexadecimal. So they said every 4 bits is going to be represented by hexadecimal 0:15:47.520000 --> 0:15:51.320000 character. So that number right there, 0010 and binary. 0:15:51.320000 --> 0:15:55.720000 If that were a decimal number, that'd be the number 2. 0:15:55.720000 --> 0:16:01.440000 Well we know that in hexadecimal, 2 is the same, it's still 2. 0:16:01.440000 --> 0:16:08.060000 In binary, 1111, what is that in decimal? 0:16:08.060000 --> 0:16:11.140000 Wasn't that the number 15? 0:16:11.140000 --> 0:16:18.360000 8 plus 4 plus 2 plus 1 is 15, but in hexadecimal, 15 is F. 0:16:18.360000 --> 0:16:26.540000 This here's the number 1, this here's the number 13, so it'll be D. 0:16:26.540000 --> 0:16:35.160000 So your MAC addresses are always going to be represented like this. 0:16:35.160000 --> 0:16:38.940000 The 48 bits in binary are going to be showing up to you in whatever show 0:16:38.940000 --> 0:16:43.900000 command you use as a hexadecimal number. 0:16:43.900000 --> 0:16:50.160000 So for example, here's an example of a MAC address, aaaa.aaaa, so on and 0:16:50.160000 --> 0:16:55.860000 so forth. Now depending on the device you're on, they will sometimes display 0:16:55.860000 --> 0:16:59.700000 MAC addresses differently, some devices will show MAC addresses like this. 0:16:59.700000 --> 0:17:08.360000 For every 4 characters, hex characters, it'll be separated by a dot. 0:17:08.360000 --> 0:17:15.620000 Sometimes that same thing will be separated by colons, sometimes every 0:17:15.620000 --> 0:17:21.260000 2 will be separated by colons, it just depends on the device that you're 0:17:21.260000 --> 0:17:27.660000 on. The main thing is, is that these are hexadecimal characters and they 0:17:27.660000 --> 0:17:35.760000 add up to a total of 48 bits in binary. 0:17:35.760000 --> 0:17:42.300000 So of our MAC address, the first half of it, the first 24 bits is what's 0:17:42.300000 --> 0:17:45.480000 called an organizationally unique identifier. 0:17:45.480000 --> 0:17:46.980000 What's that mean? 0:17:46.980000 --> 0:17:51.760000 Let's say for example that I had a machine shop in my garage and I thought, 0:17:51.760000 --> 0:17:55.480000 you know what? I have all the equipment necessary to create my own Ethernet 0:17:55.480000 --> 0:17:59.940000 adapters. I want to start making my own Ethernet adapters and sell them 0:17:59.940000 --> 0:18:04.080000 on the open market and compete against Intel and some of these other big 0:18:04.080000 --> 0:18:09.680000 companies. In order to do that, all of the adapters that I create in my 0:18:09.680000 --> 0:18:14.580000 garage and my machine shop, the first half of them have to have an organizationally 0:18:14.580000 --> 0:18:18.760000 unique identifier that is unique to my organization. 0:18:18.760000 --> 0:18:19.440000 So what would I do? 0:18:19.440000 --> 0:18:23.180000 Well, I would go to the IEEE and I'd pay them something like 500 American 0:18:23.180000 --> 0:18:25.000000 dollars or something like that. 0:18:25.000000 --> 0:18:29.500000 And once I pay them some money, they will give me an OUI. 0:18:29.500000 --> 0:18:33.880000 And now every single NIC card that I create in my machine shop will have 0:18:33.880000 --> 0:18:36.040000 my OUI at the front half. 0:18:36.040000 --> 0:18:37.600000 They will all have the same number. 0:18:37.600000 --> 0:18:41.460000 And then the second half of the address, as you can see here, will be 0:18:41.460000 --> 0:18:48.060000 unique. So every single NIC card should have its own unique MAC address 0:18:48.060000 --> 0:18:52.420000 burned into it at the time of manufacture that is unchanging. 0:18:52.420000 --> 0:18:56.560000 So the manufacturer's stamp, the OUI will be the first half and then the 0:18:56.560000 --> 0:19:01.780000 second half will be a unique number just for that MAC address, just for 0:19:01.780000 --> 0:19:09.000000 that NIC card. And you can see here, if you're curious, I have up here, 0:19:09.000000 --> 0:19:35.800000 you can go to this website, wireshark.org. 0:19:35.800000 --> 0:19:38.600000 00.00.00c. Who owns that? 0:19:38.600000 --> 0:19:43.700000 Search. Cisco. Cisco owns that one. 0:19:43.700000 --> 0:19:46.900000 You can type in, you know, you can look at the OUI of your own NIC card 0:19:46.900000 --> 0:19:48.980000 on your laptop or your PC. 0:19:48.980000 --> 0:19:53.220000 Maybe you own 00.002.11. 0:19:53.220000 --> 0:19:55.300000 Does anybody own that? 0:19:55.300000 --> 0:19:58.040000 Nature Worldwide Technology Corporation. 0:19:58.040000 --> 0:20:01.060000 So this is kind of a, and there are other websites that do the same type 0:20:01.060000 --> 0:20:04.220000 of thing where you can plug in an OUI and it will tell you what company 0:20:04.220000 --> 0:20:13.220000 owns that OUI. But we're not done with the MAC address just yet. 0:20:13.220000 --> 0:20:20.840000 So the MAC address here, we know that this is the first 24 bits, first 0:20:20.840000 --> 0:20:25.900000 3 bytes. Let me go back to the whiteboard here for a moment. 0:20:25.900000 --> 0:20:29.120000 So let's say this was my MAC address, this is the first 32 bits of my 0:20:29.120000 --> 0:20:32.480000 MAC address. Let me get rid of some of this. 0:20:32.480000 --> 0:20:38.700000 Well, the first byte is this. 0:20:38.700000 --> 0:20:41.360000 That's the first byte, the first 8 bits. 0:20:41.360000 --> 0:20:48.880000 In every MAC address, in the first byte, this least significant bit right 0:20:48.880000 --> 0:20:51.620000 here. I'll put a little box around that. 0:20:51.620000 --> 0:20:54.580000 That bit has a special meaning. 0:20:54.580000 --> 0:21:03.820000 That is called the individual slash group bit. 0:21:03.820000 --> 0:21:12.280000 If that bit is a zero, that means this MAC address belongs to an individual 0:21:12.280000 --> 0:21:17.780000 device. This is a unique MAC address that doesn't belong to anybody else. 0:21:17.780000 --> 0:21:20.580000 Clearly, this one is not a zero. 0:21:20.580000 --> 0:21:26.640000 If it's a one, that means this MAC address is a group address. 0:21:26.640000 --> 0:21:30.160000 You might be wondering, what do you mean by a group address? 0:21:30.160000 --> 0:21:32.640000 Well, think of the concept of a broadcast. 0:21:32.640000 --> 0:21:34.060000 What is a broadcast? 0:21:34.060000 --> 0:21:38.460000 A broadcast is I put one data unit on the wire and it's meant for everybody 0:21:38.460000 --> 0:21:43.500000 to see. Well, if I'm going to put that data unit into an Ethernet frame, 0:21:43.500000 --> 0:21:47.460000 the destination MAC address of that frame has to indicate this is not 0:21:47.460000 --> 0:21:50.760000 for anybody in particular, this is for everybody. 0:21:50.760000 --> 0:22:04.520000 Well, the broadcast MAC address looks like this. 0:22:04.520000 --> 0:22:09.200000 Or in binary, it's just 48 bits of all ones. 0:22:09.200000 --> 0:22:11.040000 That is the broadcast MAC address. 0:22:11.040000 --> 0:22:13.480000 And you can see here that if we actually convert that into binary, which 0:22:13.480000 --> 0:22:19.840000 I did, and I take a look at the first byte, 1, 2, 3, 4, 1, 2, 3, 4, I 0:22:19.840000 --> 0:22:21.900000 think I've got all four of them there. 0:22:21.900000 --> 0:22:28.000000 We can see here that the individual group bit is set to a one, because 0:22:28.000000 --> 0:22:29.800000 that is a group address. 0:22:29.800000 --> 0:22:33.960000 If you have any experience with multicasts at layer two, there are special 0:22:33.960000 --> 0:22:36.000000 MAC addresses for multicasts. 0:22:36.000000 --> 0:22:38.040000 Those are also group addresses. 0:22:38.040000 --> 0:22:42.040000 So their least significant bit will also be turned on as a one. 0:22:42.040000 --> 0:22:45.540000 So any MAC address that has a one bit here means it does not belong to 0:22:45.540000 --> 0:22:47.080000 a specific NIC card. 0:22:47.080000 --> 0:22:50.460000 It belongs to a group of devices. 0:22:50.460000 --> 0:22:53.420000 That is the individual group bit. 0:22:53.420000 --> 0:23:03.640000 Now, in addition to that, the bit right next to it, right here, that bit 0:23:03.640000 --> 0:23:04.840000 also has a special significance. 0:23:04.840000 --> 0:23:14.260000 That's called the universal or global local bit. 0:23:14.260000 --> 0:23:23.040000 If that is a zero, that means this address is universally slash globally 0:23:23.040000 --> 0:23:29.160000 unique. That means nobody else in the entire world should have that MAC 0:23:29.160000 --> 0:23:31.280000 address. It belongs to you. 0:23:31.280000 --> 0:23:36.780000 It is yours. Now, if I was to go into a device and change its MAC address, 0:23:36.780000 --> 0:23:41.200000 which you actually can do on most devices, there's nothing that forces 0:23:41.200000 --> 0:23:45.000000 me to do this, but if I'm changing my MAC address, what certainty do I 0:23:45.000000 --> 0:23:48.700000 have that the new MAC address I'm putting on there manually isn't already 0:23:48.700000 --> 0:23:50.240000 out there in the world somewhere. 0:23:50.240000 --> 0:23:51.800000 That's reserved for somebody else. 0:23:51.800000 --> 0:23:56.160000 I don't know. So if I change it, I should take that second bit and flip 0:23:56.160000 --> 0:24:01.920000 it to a one, which means that I have now a little bit of a memory. 0:24:01.920000 --> 0:24:05.380000 Now, I created what's called a locally administered address. 0:24:05.380000 --> 0:24:08.480000 I mean, this MAC address is not the MAC address that was burned on here 0:24:08.480000 --> 0:24:11.580000 from the manufacturer has been locally modified. 0:24:11.580000 --> 0:24:15.640000 No guarantees anymore that this MAC address is unique. 0:24:15.640000 --> 0:24:19.200000 So those two bits have special meaning there. 0:24:19.200000 --> 0:24:25.380000 And that's what this slide is referring to. 0:24:25.380000 --> 0:24:30.220000 All right. So within the Ethernet frame, Ethernet version two, after our 0:24:30.220000 --> 0:24:34.180000 MAC addresses, after we have a destination MAC and a source MAC, we have 0:24:34.180000 --> 0:24:36.440000 a type field, two bytes long. 0:24:36.440000 --> 0:24:41.320000 And this indicates what type of upper layer data is this carrying, some 0:24:41.320000 --> 0:24:46.480000 common type codes you might see. 0:24:46.480000 --> 0:24:48.800000 I'll just say them verbally here to you. 0:24:48.800000 --> 0:24:49.860000 Actually, let's see here. 0:24:49.860000 --> 0:24:52.080000 Do I have a way of doing this? 0:24:52.080000 --> 0:24:58.980000 No, not let me do it. 0:24:58.980000 --> 0:25:06.940000 Okay. Okay. Okay. 0:25:06.940000 --> 0:25:11.380000 So if the type code you see is, actually, I want to go ahead and type 0:25:11.380000 --> 0:25:21.180000 this out. Here's some common ether types. 0:25:21.180000 --> 0:25:25.180000 These are probably the three most common ones that you'll ever see. 0:25:25.180000 --> 0:25:34.760000 0x800. That means this Ethernet frame is carrying an IP version four packet. 0:25:34.760000 --> 0:25:40.000000 0x806 means it's carrying an ARP, either an ARP request or an ARP response. 0:25:40.000000 --> 0:25:47.380000 And 0x86DD means we're carrying an IPV6 packet. 0:25:47.380000 --> 0:25:51.520000 There are many, many other ones as well. 0:25:51.520000 --> 0:25:57.300000 And if you're curious about those, you can go to this website right here. 0:25:57.300000 --> 0:26:00.380000 Go ahead and make this a little bit larger so you can see it. 0:26:00.380000 --> 0:26:07.700000 kbear.com. Archive, kbear, ethernet, slash type. 0:26:07.700000 --> 0:26:11.000000 You can pause this video for a moment if you want to write that down. 0:26:11.000000 --> 0:26:12.720000 There are other websites that do this as well. 0:26:12.720000 --> 0:26:16.220000 You can just Google Ethernet type value or type code. 0:26:16.220000 --> 0:26:21.020000 And from here you can see all the different type values and what they've 0:26:21.020000 --> 0:26:22.520000 been assigned to. 0:26:22.520000 --> 0:26:32.260000 Now with the 802.3 frame, they decide to change that into a length field. 0:26:32.260000 --> 0:26:38.200000 And the length field that says how long is this yellow portion here, our 0:26:38.200000 --> 0:26:42.880000 802.2 header and our data. 0:26:42.880000 --> 0:26:46.500000 So I'm going to talk a little bit more about this as we, when we get into 0:26:46.500000 --> 0:26:50.580000 the section about the size of Ethernet frames and what are meant by runts 0:26:50.580000 --> 0:26:52.340000 and giants and things like that. 0:26:52.340000 --> 0:26:58.920000 But for now, the Ethernet specification says, then Ethernet frame, that 0:26:58.920000 --> 0:27:03.400000 the data of an Ethernet frame should be a minimum of 46 bytes in size 0:27:03.400000 --> 0:27:07.780000 up to a maximum of 1500 bytes in size. 0:27:07.780000 --> 0:27:13.000000 46 to 1500. That being the case, sometimes the question arises, okay, 0:27:13.000000 --> 0:27:16.900000 well after my source address, how does the net card that's receiving this 0:27:16.900000 --> 0:27:21.160000 frame know if the next two bytes are a type value or a length value? 0:27:21.160000 --> 0:27:22.480000 How does it know? 0:27:22.480000 --> 0:27:24.000000 Well, here's how it knows. 0:27:24.000000 --> 0:27:31.040000 All of the valid type codes are values that in decimal are greater than 0:27:31.040000 --> 0:27:33.700000 or equal to 1536. 0:27:33.700000 --> 0:27:36.780000 You might say 1536, what about 1501? 0:27:36.780000 --> 0:27:42.060000 Well, actually the values of 1501 through 1535 are undefined. 0:27:42.060000 --> 0:27:44.200000 They are sort of left there for future use. 0:27:44.200000 --> 0:27:51.260000 But the type values of 1536 and above are used for ARP and IPv4 and IPv6 0:27:51.260000 --> 0:28:02.540000 and all those things in that list I just showed you. 0:28:02.540000 --> 0:28:03.340000 So, what does that ever be? 0:28:03.340000 --> 0:28:10.440000 Greater than 1500 because 1500 is the maximum size of the frame. 0:28:10.440000 --> 0:28:15.440000 Now, for talking about 802.3, you might have been thinking, well, if we 0:28:15.440000 --> 0:28:20.080000 didn't have a type field, how does the receiving device know what the 0:28:20.080000 --> 0:28:24.700000 data is? If it should go to the IPv4 process, or the IPv6 process, or 0:28:24.700000 --> 0:28:30.420000 if it should go to ARP, well, this is where the 802.2 working group came 0:28:30.420000 --> 0:28:33.360000 into play. Remember, 802.2 was the working group that came up with the 0:28:33.360000 --> 0:28:38.620000 logical link control, that upper sublayer of the data link layer. 0:28:38.620000 --> 0:28:42.960000 And they said, okay, we're going to put three subfields in here. 0:28:42.960000 --> 0:28:47.060000 These three subfields comprise your logical link control. 0:28:47.060000 --> 0:28:52.260000 DSAAP stands for destination service access point. 0:28:52.260000 --> 0:28:54.500000 Destination service access point. 0:28:54.500000 --> 0:28:57.240000 It's basically the exact same thing as a type code. 0:28:57.240000 --> 0:29:02.280000 It's a value. And there's certain DSAAP values for IPv4, IPv6, and all 0:29:02.280000 --> 0:29:04.100000 sorts of other stuff too. 0:29:04.100000 --> 0:29:10.220000 SSAAP, as you can probably guess, is source service access point. 0:29:10.220000 --> 0:29:12.120000 Usually these two values are the same. 0:29:12.120000 --> 0:29:18.180000 Whatever the protocol number was that created this field at the source 0:29:18.180000 --> 0:29:22.960000 is going to be talking to the exact same protocol at the destination. 0:29:22.960000 --> 0:29:26.480000 It's not always the same, but the vast majority of time, these two numbers 0:29:26.480000 --> 0:29:29.300000 are the same. The control field. 0:29:29.300000 --> 0:29:33.180000 In modern day implementations of Ethernet, the control field really isn't 0:29:33.180000 --> 0:29:34.720000 used for anything. 0:29:34.720000 --> 0:29:40.840000 But what this is for is because remember, LLC, the 802.2 working group, 0:29:40.840000 --> 0:29:43.360000 didn't create LLC just for Ethernet. 0:29:43.360000 --> 0:29:47.480000 They said, we want lots of different types of layer two protocols to make 0:29:47.480000 --> 0:29:54.640000 use of LLC. So they said, okay, well, we want LLC to be used in some protocols 0:29:54.640000 --> 0:29:58.860000 that layer two are connection oriented. 0:29:58.860000 --> 0:30:02.920000 So for example, LLC designs basically what's called three different types 0:30:02.920000 --> 0:30:07.500000 of services. There's what's called unacknowledged connectionless mode 0:30:07.500000 --> 0:30:09.560000 that's like Ethernet. 0:30:09.560000 --> 0:30:12.800000 When you send out an Ethernet frame, do you get an acknowledgment back 0:30:12.800000 --> 0:30:25.700000 for it? No you don't. 0:30:25.700000 --> 0:30:29.060000 So Ethernet is unacknowledged connectionless mode, which means the control 0:30:29.060000 --> 0:30:31.600000 field really doesn't do anything. 0:30:31.600000 --> 0:30:35.340000 But if you're using another type of layer two protocol off the top of 0:30:35.340000 --> 0:30:36.760000 my head, I can't think of what they would be. 0:30:36.760000 --> 0:30:40.820000 Maybe some like mainframe IBM SNA type protocols. 0:30:40.820000 --> 0:30:45.620000 You might have connection mode, which means you actually establish a connection 0:30:45.620000 --> 0:30:47.200000 first. You get acknowledgments back. 0:30:47.200000 --> 0:30:49.020000 So you get the other type of layer two protocols that are like TCP at 0:30:49.020000 --> 0:30:50.200000 the transport layer. 0:30:50.200000 --> 0:30:54.560000 And there's a third mode called acknowledged connectionless mode. 0:30:54.560000 --> 0:30:57.420000 We actually do get acknowledgments back even though you're connectionless. 0:30:57.420000 --> 0:31:00.300000 I don't know what layer two protocols actually use that. 0:31:00.300000 --> 0:31:03.660000 So if you're using one of those other types of layer two protocols, which 0:31:03.660000 --> 0:31:07.740000 I don't know what they are, that are either doing connection mode or acknowledged 0:31:07.740000 --> 0:31:11.680000 connectionless mode, that's when the control field would actually take 0:31:11.680000 --> 0:31:13.020000 on significance. 0:31:13.020000 --> 0:31:15.500000 But in the world of Ethernet, it doesn't really mean anything. 0:31:15.500000 --> 0:31:17.100000 Doesn't do anything. 0:31:17.100000 --> 0:31:26.020000 And at the end, we have a trailer, which consists of our frame check sequence. 0:31:26.020000 --> 0:31:31.280000 So this is used for error detection, not error correction. 0:31:31.280000 --> 0:31:35.300000 So the FCS field, so if you receive an Ethernet frame by looking at the 0:31:35.300000 --> 0:31:39.620000 FCS field, you can tell if any of the bits in that frame have been modified 0:31:39.620000 --> 0:31:44.940000 or changed. But you can't tell which bits have been modified or changed. 0:31:44.940000 --> 0:31:48.300000 All you know is that the frame does not look the same as when the source 0:31:48.300000 --> 0:31:54.280000 sent it. So basically the way this works is that when the originator, 0:31:54.280000 --> 0:31:58.440000 the source of the frame, put this frame together, it runs a cyclic redundancy 0:31:58.440000 --> 0:32:02.380000 check, a CRC, which is a special algorithm, where it takes all the bits 0:32:02.380000 --> 0:32:06.740000 starting with the destination address all the way through to the end of 0:32:06.740000 --> 0:32:10.160000 the data. So from the DA, all the way to the end of the data, it takes 0:32:10.160000 --> 0:32:13.760000 all those bits, runs them through an algorithm called a cyclic redundancy 0:32:13.760000 --> 0:32:19.280000 check, which then computes some sort of number, like let's say A123, and 0:32:19.280000 --> 0:32:22.380000 it puts that number into the FCS. 0:32:22.380000 --> 0:32:27.520000 So the idea is, when I send you this frame, you're going to take the exact 0:32:27.520000 --> 0:32:31.820000 same bits from the destination address to the end of the data, and you're 0:32:31.820000 --> 0:32:35.320000 going to run it through the exact same cyclic redundancy check. 0:32:35.320000 --> 0:32:38.720000 And you're going to compare the number that you came up with, with the 0:32:38.720000 --> 0:32:40.440000 number that's in the FCS here. 0:32:40.440000 --> 0:32:44.600000 Now if you come up with A123 and it matches this, you say, great! 0:32:44.600000 --> 0:32:48.160000 Clearly none of these bits have been modified, because if they did, your 0:32:48.160000 --> 0:32:51.740000 cyclic redundancy check would not come up with the same number. 0:32:51.740000 --> 0:32:56.160000 And if that happened, that would be considered an FCS or a CRC error, 0:32:56.160000 --> 0:32:57.900000 and you would just simply throw away the frame. 0:32:57.900000 --> 0:33:00.340000 There's no way to figure out what changed. 0:33:00.340000 --> 0:33:02.660000 All you know is that that frame is no longer reliable. 0:33:02.660000 --> 0:33:04.300000 Something has been modified. 0:33:04.300000 --> 0:33:06.560000 There has been an error. 0:33:06.560000 --> 0:33:11.740000 So that concludes this section on the various fields and components of 0:33:11.740000 --> 0:33:13.100000 the Ethernet frame. 0:33:13.100000 --> 0:33:16.200000 In the next section, we're going to look at Ethernet frame sizes and talk 0:33:16.200000 --> 0:33:19.640000 about things like Runtz, Giants, and Jumbo frames.