 When introducing data communications and computer networking, one of the things we often refer to is packets. This short presentation is trying to explain what we mean by a packet, some different terms that are used to describe packets and also give some examples of different packets. So I'll first talk about the terminology, define a packet, talk about the structure of a packet, and also introduce some other terms that may come up when we talk about packets. Then I'll give a detailed example using the internet protocol showing the structure of an IP datagram, one example of a packet. Towards the end I'll give a few more examples. And we'll also discuss one of the design issues is how big should a packet be, so look at the packet size. Communication protocols are about sending data, and the data can be treated as a sequence of bits, zeros and ones. However most communication protocols don't just look at a continuous sequence of bits, they group those bits into separate pieces. And each piece of data is called a packet. A packet can be broken into three main parts. We can say a packet has a header, payload, and a trailer. The payload first is the actual data we're trying to communicate. So if we're sending data from A to B, the payload part of the packet contains that data. The header and the trailer don't contain the user data, they can contain some extra information needed to make sure the protocol works correctly. So depending upon the purpose of the protocol, the header and trailer can be included to include control information. The difference between the two is that the header comes at the start of the packet while the trailer is at the end. The payload is in the middle. However not all parts are needed. So depending upon the protocol, some packets may contain a header plus payload, but no trailer. In other cases there may be a trailer included or there may be no payload at all than just a header. Unfortunately like many topics in technology, there's no one standard for the terminology used when we talk about packets. Even the word packets is not a standard. There may be other names used by other sources, other people. Frames, a datagram, segments, packages, messages. And it differs amongst different protocols and sometimes amongst different layers. So if we look at a layered perspective, we may hear of an application message. At the transport layer, talk about TCP segments whereas UDP talks about datagrams. At the network layer, considering the internet protocol, commonly refers to datagrams. And maybe at the data link layer frames are more common. So depending upon the protocol, the layer, different names are used. I think the more general name is a packet. And I will usually use the word packet or maybe if talking about a specific protocol use the word that that protocol uses like a TCP segment. We often care about the packet size. Commonly we say we talk about the packet size in bytes or bits. But if you look at standards, often they use another word to talk about the size, octets. What's an octet? An octet is eight bits. How does that differ from a byte? Because normally we assume one byte is eight bits. Well, in the past, in very special cases, it was the case that one byte wasn't always eight bits. So therefore to be precise, the word octet is used. However, when I talk about packets, I'll usually use the more informal word byte. So we'll talk about bytes. And whenever I say a byte, I mean exactly eight bits. So we've said a packet contains header, payload and trailer. Well, what's the purpose of the header and trailer? As we said, they contain some extra information, not the actual data. Some extra information to help the protocol work correctly. And that's quite broad because it actually depends upon what the purpose of the protocol is. Is it an application layer protocol to support web browsing? Then that extra information may be some information about the web browser or the request being made. Or is it a protocol about the wireless LAN data link layer where the extra information may be MAC addresses? So the sender when they send a packet includes information in the header. So the receiver when they receive that packet can correctly process the data. And when needed, respond correctly. When we talk about a header or a trailer, we usually define the information in the header or trailer into a separate set of fields. And each field we can say has some value. So a header is made up of fields and each field has a value. The number, what the fields mean and how big those fields are is defined in a standard. So a standard that defines a particular protocol specifies those values. For example, the IETF RFC 793 defines TCP. And in that document, there's a picture and description of the TCP segment header fields. Many protocols define a default header, usually for fixed size. For example, with TCP, there's a default header of 20 bytes. And those 20 bytes are always required in a TCP segment. But often protocols also support optional extra fields. So further fields which increase the size of the header. They may not be included in all packets sent, but they may be used depending upon the features of that protocol being used. For example, IEEE 802.11 wireless LANs. In the MAC data frame, there's typically a 24 byte header, a 4 byte trailer. But in fact, there may be other sizes possible depending upon how the wireless LAN is used. When we talk about packets, we often want to visualize or to draw to communicate the structure of a packet. So the top diagram, we draw a packet as a simple rectangle where we think is the first bit as the leftmost part of the rectangle and the last bit of that packet at the rightmost end. We read left to right. Where a packet we can split into three parts, header, payload, and trailer. Noting that not all those parts are always included. And the header and trailer may contain a set of fields and those fields have values. So why do we have both a header and a trailer? They both contain information to support the protocol operation. The difference being the header is at the start of the packet before the payload, while the trailer is at the end after the payload. Again, why do we need both? Well, it depends upon how devices process and can give some different performance characteristics. Devices typically process the packet as it is received. So the header is received first, then the payload, and then the trailer. That means as the device starts receiving the packet, it can start processing the information in the header. Even before the rest of the packet has fully arrived, so before the data and the trailer has arrived, the device can be doing something based upon what's in the header. One example is a router. A router is a device that receives packets and sends them on to another link. It normally doesn't care about the contents of the data. So in that case, what the router can do is as it starts receiving the packet, it looks at the header fields to determine where to send the packet, even before the entire packet has been received. That's why putting the information at the start is beneficial. So why would we need information at the end in the trailer? Well, sometimes we need extra control information that's dependent upon the data. A common example is a checksum. We perform some error detection. So we calculate a checksum across the data. So the receiver, the device that receives the packet, needs to read the entire header, the data, before it checks the checksum contained in the trailer. So it makes sense then to include that checksum information in the trailer at the end. Most protocols use a header. Some use both a header and a trailer. To keep things simple in the diagrams and the examples I show, I'll usually just consider a header. So what's in a header or a trailer? Some examples, addresses. Who sent the packet? Who are they sending the packet to? So IP addresses, MAC addresses, the length of the packet or the length of the payload or the header. In the case we have different lengths header, headers possible, we may need to specify how long it is. Sequence numbers, ACT numbers, the version of the protocol being used, checksums, error detection codes. Sometimes packets have different meanings or different types. So we include in the header some value that indicates the type of packet. That's commonly performed using a flag. A flag is normally a single bit value. So it's either zero or one. Zero meaning off, one being on. Or false and true. So if that single bit value is one, and it means that feature indicated by that flag is on or is being used. We'll see some examples of packet structures in the next when we look at the internet protocol on the IP datagram.