Ethernet Packets and Protocols
The following section is a brief introduction to the concepts of packets and protocols. For a list of recommended readings on networking topics, please visit our website at: https://www.liveaction.com/support/
Ethernet was invented at Xerox PARC and developed jointly by Digital Equipment Corporation, Intel and Xerox. Introduced in 1980, Ethernet was distinguished by its high speed (10 Mbps), its unusual signaling methodology (the latest version of which is now referred to as Carrier Sense Multiple Access with Collision Detection or CSMA/CD), and by the physical medium on which it ran: a thick, high-quality coaxial cable with a bright yellow braided sheath.
Today, the term Ethernet refers to a whole family of closely related protocols characterized by their raw data rates (10 Mbps, 100 Mbps, 1 Gbps or 10 Gbps) and the physical medium on which they operate. Ethernet now runs on a wide variety of physical media. Among the most common are: coaxial cable (thick or thin), many types of copper cable called twisted pair, and several types of fiber-optic cables using a variety of signalling methods and light wavelengths.
The CSMA/CD approach is used by any form of Ethernet operating in half-duplexmode-that is, the mode in which transmit (Tx) and receive (Rx) signals can be sent on the same wire or data path. In full-duplex mode, transmit and receive signals are separated onto dedicated, one-way channels. This eliminates the need for CSMA/CD, as all the transmissions on a single data path will be coming from a single device. Half-duplex mode is seldom used in versions of Ethernet running on fiber and is not supported at all in the 10 Gbps standards.
Each piece of information transmitted on an Ethernet network is sent in something called a packet. A packet is simply a chunk of data enclosed in one or more wrappers that help to identify the chunk of data and route it to the correct destination. Destination in this sense means a particular application or process running on a particular machine. These wrappers consist of headers, or sometimes headers and trailers. Headers are simply bits of data added to the beginning of a packet. Trailers are added to the end of a packet.
Packets are created at the machine sending the information. The application generating the data on the sending machine passes the data to a protocol stackrunning on that machine. The protocol stack breaks the data down into chunks and wraps each chunk in one or more wrappers that will allow the packets to be reassembled in the correct order at the destination. The protocol stack on the sending machine then passes the packets to the Ethernet hardware: the NIC(Network Interface Card). The Ethernet hardware adds its own wrapper (the Ethernet header and trailer) to each packet to direct it to the correct destination on the local network.
If the packet’s ultimate destination is somewhere off the local network, the Ethernet header added by the sending machine will point to a router or switch as its destination address. The router will open the packet, strip off the Ethernet wrapper, read far enough to find the ultimate destination address and re-wrap the packet, giving it a new header that will send it on the next hop of its journey.
At the receiving end, the process is reversed. The packet is read by the NIC at the receiving machine which strips off the Ethernet header and passes the packet up to the appropriate protocol stack. The protocol stack reads and strips off its headers and passes the remaining packet contents on up to the application or process to which it was addressed, reassembling the chunked data in the correct order as it arrives.
The packet diagramed in Figure A.1 above is shown in a Packet Decode window in Figure A.2 below. The Decode view shows four fields calculated by Omnipeek at the top of the window, then shows each of the layers of the packet. In this view, the +plus signs in the margin indicate that the details for each part of the packet are hidden under their headings. Omnipeek displays the packet contents in the same order in which it appears in the packet: Ethernet header, IP header, then the TCP and the HTTP payload.
Networking protocols specify what types of data can be sent, how each type of message will be identified, what actions can or must be taken by participants in the conversation, precisely wherein the packet header or trailer each type of required information will be placed, and more.
Omnipeek understands protocols by examining the contents of the packets those protocols create. Each protocol has a variety of forms of headers and sometimes trailers that it uses, either to transmit data for other applications, or to transmit control and information messages that support its own functionality. The exact form of these wrappers or headers tends to be unique, not only among functions within a given protocol, but also across protocols.
Omnipeek essentially acts as if it were a combination of all of the various protocol stacks: AppleTalk, TCP/IP, DECnet, NetWare or others. Instead of acting on the messages, Omnipeek decodes the packets in order to identify as precisely as possible what function each packet serves within its protocol. Savvius’ ProtoSpecs technology refers to these various functions as sub-protocols. In other, more formal views of networking, TCP and UDP may be seen as protocols in their own right, HTTP may be seen as an application running under TCP/IP, and so on. ProtoSpecs side-steps all these largely formal naming conventions and simply treat all of them-UDP, TCP, and HTTP-as sub-protocols of IP. ProtoSpecs does preserve the correct functional relationships among the various sub-protocols, however. HTTP, for instance, is shown as a sub-protocol of TCP which is itself a sub-protocol of IP.
Ethernet is the collective name for a variety of closely related network standards. As a network standard, each version of Ethernet includes specifications for the physical network layer: how the signals will be sent and received. Protocols like IP or NetWare, in contrast, define communications without reference to the physical transport medium. Omnipeek is only interested in that aspect of each version of Ethernet that is reflected in the construction of Ethernet packets or network frames. It treats the various Ethernet standards as if they were protocols, discriminating among them based on the unique form each one gives to packet headers and trailers.
ProtoSpecs nests protocols, one under the other, in a hierarchy from broadest to most specific. ProtoSpecs places the various Ethernet standards at the top of the hierarchy of protocols, as they are certainly the broadest. The 802.3 Ethernet standard and the older Ethernet Type 2 standard form parallel hierarchies in ProtoSpecs. Many protocol stacks are still written for the older Ethernet Type 2. Most IP implementations, for example, use the older standard. The net effect is that protocols may appear twice in the ProtoSpecs hierarchy: once under the older Ethernet Type 2 and again under the newer 802.3 standard.
This section describes the various types of Ethernet packet headers and the clues they contain to the protocols found in the network data which they frame. Ethernet packets use a format like that shown in Figure A.3.
Note: Omnipeek captures FCS bytes only from adapters that are under the control of a driver that supports the Savvius API. The Packet Decode window shows FCS bytes as Calculated when these bytes were not captured directly from the network. You can find the latest information about supported cards and drivers for Omnipeek in the Supported Hardware section of our website, at LiveAction Support
Ethernet packets are sometimes called network frames because they add both a header and a trailer to the packets, thus framing the network data being transmitted. The older Ethernet standards and the newer 802.3 standards are largely the same. Both types begin with a 6-byte destination (MAC) address followed by a 6-byte source (MAC) address, and both add a 4-byte frame check sequence (FCS) to the end of the packet to help detect any errors introduced during packet transmission.
Note: The MAC (Media Access Control) address is the physical address of a particular Network Interface Card (NIC) or other Ethernet device. For more information on addressing, please see Appendix B, “Ethernet Addresses and Names”.
The difference between the two standards is in how they describe the contents of the packet itself. The older standard uses a 2-byte hexadecimal number to denote the protocol Type of the network data framed by the packet. This information is placed in a 2-byte field at offset 12, immediately following the source address.
The 802.3 standard takes advantage of further work done by the IEEE in establishing more powerful tools for describing the contents and function of Ethernet packets. This work resulted in the 802.2 standards for Logical Link Control and created a new part of an Ethernet packet known as the LLC header. The 802.2 standard permits this field to be of varying length (3 bytes or 8 bytes), so 802.3 packets use the old Type field at offset 12 to describe the length of this new header.
The standard Ethernet frame (Figure A.3) is from 64 to 1518 bytes in length, excluding the preamble, start delimiter, and end delimiter. The maximum transmission unit (MTU) is sometimes expressed as 1500 bytes, but this excludes the destination and source address fields (six bytes each), the length/type field (two bytes), and the four bytes of FCS.
Packets smaller than the 64 byte minimum are described as runt packets. Those larger than 1518 bytes (with the exceptions noted below) are described as oversized. The vast majority of Ethernet implementations in the field today will reject packets outside the 64-1518 byte range.
As Ethernet data rates increased, vendors began to consider using Ethernet beyond the LAN in metropolitan area networks (MANs) and wide-area networks (WANs). The conditions in these new environments prompted two changes in the Ethernet standards, each of which permitted longer packets.
The first change was the adoption of an optional set of fields in the Ethernet header to accommodate virtual local area networks (VLANs). This method is covered in the IEEE 802.1Q and 802.3ac standards. The two fields, shown in Figure A.4, increase the Ethernet MTU from 1518 to 1522 bytes for protocol stacks that support the new option. Packets that conform to this standard are sometimes referred to as Baby Jumbo or Baby Giant frames.
So-called Jumbo frames have a theoretical MTU of 9180 bytes. This is the largest packet that can be verified using a four byte FCS. The actual maximums vary from one vendor to another, with many vendors choosing the intermediate size of 4470 bytes, which is compatible with FDDI/IP. On networks with a very high data rate (> 1 Gbps), the use of Jumbo packets can reduce overhead and improve throughput.
As a practical matter, the largest packets found on any network path tend to conform to the smallest MTU permitted by any router or switch on that network path. Even on Ethernet backbone segments that are “Jumbo clean” (that is, those on which all directly connected devices are able to send and receive Jumbo frames), it is not unusual to find very few, or even no frames larger than 1518 bytes.
The 802.2 Header, usually called the LLC (Logical Link Control), contains information about the protocol type of the packet. These 802.2 headers are either 3 bytes or 8 bytes long. The first section of the LLC header is 3 bytes long and contains two LSAP values and one LSAP command. These LSAP values can either contain information about the protocol of the packet, or they can point to the optional 5-byte SNAP section that follows. If they point to the SNAP section of the header then the protocol is described by this 5-byte Protocol Discriminator or SNAP ID.
- The first byte is the Destination Service Access Point (DSAP), which designates a destination protocol.
- The second byte is the Source Service Access Point (SSAP), which designates a source protocol, most often set to the same value as the DSAP.
Note: The 1-byte hexadecimal number in these fields can be used to identify the specific 802.2 LSAP protocol in a filter. For example, XNS uses this LSAP value: 0x80.
When both the DSAP and SSAP are set to 0xAA, the type is interpreted as a protocol not defined by IEEE and the LSAP is referred to as SubNetwork Access Protocol (SNAP).
In Omnipeek, protocol type specifications found in this optional 5-byte SNAP section of the 802.2 header are referred to as 802.2 SNAP IDs. The following figure shows an example of an 802.2 header with a SNAP ID.
Figure A.6 802.2 Header with SNAP ID