Local Area Network (LAN) Technologies

Overview

To successfully troubleshoot Transmission Control Protocol/Internet Protocol (TCP/IP) problems on a local area network (LAN), it is important to understand how IP datagrams and Address Resolution Protocol (ARP) messages are encapsulated when sent by a computer running a member of the Microsoft Windows Server 2003 family or Windows XP on LAN technology links such as Ethernet, Token Ring, Fiber Distributed Data Interface (FDDI), and Institute of Electrical and Electronics Engineers (IEEE) 802.11. For example, IP datagrams sent over an Ethernet network segment can be encapsulated two different ways. If two hosts are not using the same encapsulation, communication cannot occur. It is also important to understand LAN technology encapsulations to correctly interpret the Ethernet, Token Ring, and FDDI portions of the frame when using Microsoft Network Monitor.

LAN Encapsulations

Because IP datagrams are an Open Systems Interconnection (OSI) Network Layer entity, IP datagrams must be encapsulated with a Data Link Layer header and trailer before being sent on the physical medium. The Data Link Layer header and trailer provide the following services:

• DelimitationFrames at the Data Link Layer must be distinguished from each other. For each frame, the start and end of the frame are indicated and the frame's payload is distinguished from the Data Link Layer header and trailer.
• Protocol identificationBecause many organizations use multiple protocol suites such as TCP/IP, Internetwork Packet Exchange (IPX), or AppleTalk, the protocols must be distinguished from each other.
• AddressingFor shared-access LAN technologies such as Ethernet, the source node and destination node must be identified.
• Bit-level integrity checkTo detect bit-level errors in the entire frame received by the hardware, a bit-level integrity check in the form of a checksum is needed. The checksum is computed by the source node and included in the frame header or trailer. The destination recalculates the checksum and checks it against the included checksum. If the checksums match, the frame is considered free of bit-level errors. If the checksums do not match, the frame is silently discarded. This frame checksum is in addition to the checksums provided by upper layer protocols such as IP or TCP.

The particular way a network type (such as Ethernet or Token Ring) encapsulates data to be transmitted is called a frame format. The frame format corresponds to the information placed on the frame at the Logical Link Control (LLC) and Media Access Control (MAC) sublayers of the OSI Data Link Layer, and the frame format manifests itself as a header and trailer. If multiple frame formats exist for a given network type (such as Ethernet), the frame formats represent different header and trailer structures and are therefore incompatible with each other. In other words, all the nodes on the same network segment (bounded by routers) must use the same frame format to communicate.

This chapter is a discussion of Ethernet, Token Ring, FDDI, and IEEE 802.11 LAN technologies and their frame formats for IP datagrams and ARP messages. ARCnet is not discussed, as it is not a widely used networking technology.

Ethernet

Ethernet evolved from a 9.6 kilobit-per-second (Kbps) radio transmission system developed at the University of Hawaii called ALOHA. A key feature of ALOHA was that all transmitters shared the same channel and contended for access to the channel to transmit. This became the basis for the contention-based Ethernet that we know today.

In 1972, the Xerox Corporation created a 2.94-megabit-per-second (Mbps) network based on the principles of the ALOHA system. This new network, called Ethernet, featured carrier sense, in which the transmitter listens before attempting to transmit. In 1979, Digital, Intel, and Xerox (DIX) created an industry standard 10-Mbps Ethernet known as Ethernet II. In 1981, the IEEE Project 802 formed the 802.3 subcommittee to make 10-Mbps Ethernet an international standard. In 1995, the IEEE approved a 100-Mbps version of Ethernet called Fast Ethernet.

Ethernet existed before the IEEE 802.3 specification and, because there are multiple Ethernet standards, there are multiple ways of encapsulating data to be transmitted on an Ether-net network. This can be very confusing when two hosts on an Ethernet network segment cannot communicate, even though they are using the correct communication protocol (such as TCP/IP) and Application Layer protocol (such as File Transfer Protocol [FTP]).

More Info

IP datagrams and ARP messages sent on an Ethernet network segment use either Ethernet II encapsulation (described in RFC 894) or IEEE 802.3 Sub-Network Access Protocol (SNAP) encapsulation (described in RFC 1042). These RFCs are included in the Rfc folder on the companion CD-ROM.

Ethernet II

The Ethernet II frame format was defined by the Ethernet specification created by Digital, Intel, and Xerox before the IEEE 802.3 specification. The Ethernet II frame format is also known as the DIX frame format. Figure 1-1 shows Ethernet II encapsulation for anIP datagram.

Figure 1-1: The Ethernet II frame format showing the Ethernet II header and trailer.

Ethernet II Header and Trailer

The fields in the Ethernet II header and trailer are defined as follows:

• PreambleThe Preamble field is 8 bytes long and consists of 7 bytes of alternating 1s and 0s (each byte is the bit sequence 10101010) to synchronize areceiving station and a 1-byte 10101011 sequence that indicates the start of a frame. The Preamble provides receiver synchronization and frame delimitation services.

  Note

  The Preamble field is not visible with Network Monitor.

• Destination AddressThe Destination Address field is 6 bytes long and indicates the destination's address. The destination can be a unicast, a multicast,or the Ethernet broadcast address. The unicast address is also known as anindividual, physical, hardware, or MAC address. For the Ethernet broadcastaddress, all 48 bits are set to 1 to create the address 0xFF-FF-FF-FF-FF-FF.
• Source AddressThe Source Address field is 6 bytes long and indicates the sending node's unicast address.
• EtherTypeThe EtherType field is 2 bytes long and indicates the upper layer protocol contained within the Ethernet frame. After the network adapter passes the frame to the host's network operating system, the EtherType field's value is used to pass the Ethernet payload to the appropriate upper layer protocol. If no upper layer protocols have registered interest in receiving the payload at the frame's EtherType field value, it is silently discarded.

  The EtherType field acts as the protocol identifier for the Ethernet II frame format. For an IP datagram, the field is set to 0x0800. For an ARP message, the EtherType field is set to 0x0806. The current list of defined EtherType field values can be found at http://www.iana.org/assignments/ethernet-numbers.

• PayloadThe Payload field for an Ethernet II frame consists of a protocol data unit (PDU) of an upper layer protocol. Ethernet II can send a maximum-sized payload of 1500 bytes. Because of Ethernet's collision detection facility, Ethernet II frames must send a minimum payload size of 46 bytes. If an upper layer PDU is less than 46 bytes long, it must be padded so that it is at least46 bytes long. The Ethernet minimum frame size is discussed in greater detail in the section entitled "Ethernet Minimum Frame Size," later in this chapter.
• Frame Check SequenceThe Frame Check Sequence (FCS) field is 4 bytes long and provides bit-level integrity verification on the bits in the Ethernet II frame. The FCS is also called a cyclical redundancy check (CRC). The source node calculates the FCS and places the result in this field. When the destination receives the FCS, it runs the same CRC algorithm and compares its own value with the one placed in the FCS field by the source node. If the two values match, the frame is considered valid and the destination node processes it. If the two values do not match, the frame is silently discarded.

  The FCS calculation consists of dividing a 33-bit prime number into the number consisting of the bits in the frame (not including the Preamble and FCS fields). The result of the division is a quotient and a remainder. The 4-byte FCS field is set to the remainder, which is always a 32-bit value. The FCS can detect 100 percent of all single-bit errors. Although it is mathematically possible to selectively change multiple bits in the frame without invalidating the value of the FCS field, it is highly improbable that the type of random noise and damage that occurs on networks will result in a frame with bits that are changed, but retains a valid FCS.

  The FCS calculation provides only a bit-level integrity service, not a data integrity or authentication service. A valid FCS does not imply that only the node with the unicast address stored in the Source Address field could have sent it and that it was not modified in transit. The FCS calculation is well known and an intermediate node could easily intercept the frame, alter its contents, perform the FCS calculation, and place the new value in the FCS field before forwarding the frame. The receiver of the frame could not detect that the frame contents were altered using just the FCS field. For data integrity and authentication services, use Internet Protocol Security (IPSec). For more information on IPSec, see Chapter 22, "Internet Protocol Security (IPSec)."

  The FCS field provides only bit-level error detection, not error recovery. When the receiver-calculated FCS value does not match the value of the FCS storedin the frame, the only conclusion that can be reached is that, somewhere in the frame, a bit or bits were changed. The FCS calculation does not produce any information on where the error occurred or how to correct it, but other types of CRC calculations do provide this information. An example of such a CRC calculation is the 1-byte Header Checksum field in the Asynchronous Transfer Mode (ATM) cell header, which provides error detection and limited errorrecovery services for the bits in the ATM header.

  Note

  The FCS field is not visible with Network Monitor.

The following Network Monitor trace (Capture 01-01, included in the Captures folder on the companion CD-ROM) shows the Ethernet II frame format for an IP datagram:

+ Frame: Base frame properties
 ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
 + ETHERNET: Destination address : 001054CAE140
 + ETHERNET: Source address : 00600852F9D8
 ETHERNET: Frame Length : 74 (0x004A)
 ETHERNET: Ethernet Type : 0x0800 (IP: DOD Internet Protocol)
 ETHERNET: Ethernet Data: Number of data bytes remaining = 60 (0x003C)
+ IP: ID = 0xAE09; Proto = ICMP; Len: 60
+ ICMP: Echo: From 192.168.160.186 To 192.168.160.01

Note

The ETHERNET: Frame Length and ETHERNET: Ethernet Data fields are Network Monitor informational fields, and do not correspond to fields that are physically present in the Ethernet header.

The Ethernet Interframe Gap

Unlike Token Ring and FDDI, Ethernet frame formats do not have a way to explicitly indicate the end of the frame. Rather, Ethernet frames use an implied postamble by leaving a gap between each Ethernet frame. This gap, known as the Ethernet interframe gap, is used to space Ethernet frames. The Ethernet interframe gap is a specific measure of the time required to send 96 bits of data (9.6 s on a 10-Mbps Ethernet network segment).

The Ethernet interframe gap is used as a postamble; after receiving bits of a frame, if the wire falls silent for 96 bit times, the last bit in the received frame occurred 96 bit times ago.

Ethernet Minimum Frame Size

All Ethernet frames must carry a minimum payload of 46 bytes. The Ethernet minimum frame size is a result of the Ethernet collision detection scheme applied to a maximum-extent Ethernet network. To detect a collision, Ethernet nodes must be transmitting long enough for the signal indicating the collision to be propagated back to the sending node. The maximum-extent Ethernet network consists of Ethernet segments configured using 10Base5 cabling and the IEEE 802.3 Baseband 5-4-3 rule.

The IEEE 802.3 Baseband 5-4-3 rule states that there can be a maximum of five physical segments between any two nodes, with four repeaters between the nodes. However, only three of these physical segments can have connected nodes (populated physical segments). The other two physical segments can be used only to link physical segments to extend the network length. Repeaters count as a node on the physical segment. When using 10Base5 cabling, each physical segment can be up to 500 meters long. Therefore, an Ethernet network's maximum linear length is 2500 meters.

Figure 1-2 shows Ethernet Node A and Ethernet Node B at the farthest ends of a 5-4-3 network using 10Base5 cabling.

Figure 1-2: The maximum-extent Ethernet network and the slot time.

When Node A begins transmitting, the signal must propagate the network length. In the worst-case collision scenario, Node B begins to transmit just before the signal for Node A's frame reaches it. The collision signal of Node A and Node B's frame must travel back to Node A for Node A to detect that a collision has occurred.

The time it takes for a signal to propagate from one end of the network to the other is known as the propagation delay. In this worst-case collision scenario, the time that it takes for Node A to detect that its frame has been collided with is twice the propagation delay. Node A's frame must travel all the way to Node B, and then the collision signal must travel all the way from Node B back to Node A. This time is known as the slot time. An Ethernet node must be transmitting a frame for the slot time for a collision with that frame to be detected. This is the reason for the minimum Ethernet frame size.

The propagation delay for this maximum-extent Ethernet network is 28.8 s. Therefore, the slot time is 57.6 s. To transmit for 57.6 s with a 10 Mbps bit rate, an Ethernet node must transmit 576 bits. Therefore, the entire Ethernet frame, including the Preamble field, must be a minimum size of 576 bits, or 72 bytes long. Subtracting the Preamble (8 bytes), Source Address (6 bytes), Destination Address (6 bytes), EtherType (2 bytes), and FCS (4 bytes) fields, the minimum Ethernet payload size is 46 bytes.

Upper layer PDUs smaller than 46 bytes are padded to 46 bytes, ensuring the minimum Ethernet frame size. This padding is not part of the IP datagram or the ARP message, and is not included in any length indicator fields within the IP datagram or ARP message. For example, this padding is not included in the IP header's Total Length field, which indicates only the size of the IP datagram, and is used to discard the padding bytes.

IEEE 802 3

The IEEE 802.3 frame format is the result of the IEEE 802.2 and 802.3 specifications, and consists of an IEEE 802.3 header and trailer and an IEEE 802.2 LLC header. Figure 1-3 shows the IEEE 802.3 frame format.

Figure 1-3: The IEEE 802.3 frame format showing the IEEE 802.3 header and trailer and the IEEE 802.2 header.

IEEE 802.3 Header and Trailer

The fields in the IEEE 802.3 header and trailer are defined as follows:

• PreambleThe Preamble field is 7 bytes long and consists of alternating 1s and 0s that synchronize a receiving station. Each byte is the bit sequence 10101010.
• Start DelimiterThe Start Delimiter field is the 1-byte bit sequence 10101011, which indicates the start of a frame. The combination of the IEEE 802.3 Preamble and Start Delimiter fields is the exact same bit sequence as the Ethernet IIPreamble field.

  Note

  The Preamble and Start Delimiter fields are not visible with Network Monitor.

• Destination AddressThe Destination Address field is the same as the Ethernet II Destination Address field except that IEEE 802.3 allows both 6-byte and 2-byte addresses. IEEE 802.3 2-byte addresses are not commonly used.
• Source AddressThe Source Address field is the same as the Ethernet II Source Address field except that IEEE 802.3 allows both 6-byte and 2-byte addresses.
• LengthThe Length field is 2 bytes long and indicates the number of bytes from the LLC header's first byte to the payload's last byte. The Length field does not include the IEEE 802.3 header or the FCS field. This field's minimum value is 46 (0x002E), and its maximum value is 1500 (0x05DC).
• Frame Check SequenceThe FCS field is 4 bytes long and is identical to the Ethernet II FCS field.

IEEE 802.2 LLC Header

The fields in the IEEE 802.2 LLC header and trailer are defined as follows:

• DSAPThe Destination Service Access Point (DSAP) field is 1 byte long and indicates the destination upper layer protocol for the frame.
• SSAPThe Source Service Access Point (SSAP) field is 1 byte long and indicates the source upper layer protocol for the frame.

  The DSAP and SSAP fields act as protocol identifiers for the IEEE 802.3frame format. The defined value for the DSAP and SSAP fields for IP is 0x06. However, it is not used in the industry. Instead, the SNAP header is used to encapsulate IP datagrams with an IEEE 802.3 header. The SNAP header is discussed in greater detail in the section entitled "IEEE 802.3 SNAP," later in this chapter. The current list of defined DSAP and SSAP values can be found at http://www.iana.org/assignments/ieee-802-numbers.

• ControlThe Control field can be 1 or 2 bytes long depending on whether the LLC-encapsulated data is an LLC datagram, known as a Type 1 LLC operation, or part of an LLC session, known as a Type 2 LLC operation.

  A Type 1 LLC operation (a 1-byte Control field) is a connectionless, unreliable LLC datagram. With an LLC datagram, LLC is not providing reliable delivery service on behalf of the upper layer protocol. A Type 1 LLC datagram is known as an Unnumbered Information (UI) frame and is indicated by setting the Control field to the value 0x03.

  A Type 2 LLC operation (a 2-byte Control field) is a connection-oriented, reliable LLC session. Type 2 LLC frames are used when LLC is providing reliable delivery service for the upper layer protocol.

  For IP datagrams and ARP messages, reliable LLC services are never used. Therefore, IP datagrams and ARP messages are always sent as a Type 1 LLC datagram with the Control field set to 0x03 to indicate a UI frame.

Differentiating an Ethernet II Frame from an IEEE 802.3 Frame

It is common for a network operating system to support multiple frame formats simultaneously. TCP/IP for the Windows Server 2003 family and Windows XP supports both Ethernet II and IEEE 802.3 frame formats for IP datagrams and ARP messages. There are many similarities between the Ethernet II and IEEE 802.3 frame formats, such as the following:

• The Ethernet II Preamble field is identical to the IEEE 802.3 Preamble andStart Delimiter fields.
• With the exception of the 2-byte address allowed by IEEE 802.3, the Source Address and Destination Address fields are identical.
• The FCS is identical.

The ability to differentiate between the Ethernet II and the IEEE 802.3 frame formats lies in the first 2 bytes past the Source Address field. For the Ethernet II frame format, these 2 bytes are the EtherType field. For the IEEE 802.3 frame format, these 2 bytes are the Length field. The following algorithm is used to determine whether these 2 bytes are an EtherType field or a Length field:

• If the value of these 2 bytes is greater than 1500 (0x05DC), it is an EtherType field and an Ethernet II frame format.
• If the value of these 2 bytes is less than or equal to 1500 (0x05DC), it is a Length field and an IEEE 802.3 frame.

This comparison can be made because there are no defined EtherType values less than 0x05DC. The lowest EtherType value is 0x0600, used to indicate the Xerox Network Systems (XNS) protocol.

IEEE 802 3 SNAP

Although there is a defined value of 0x06 for the Service Access Point (SAP) for IP, it is not used in the industry. RFC 1042 states that IP datagrams and ARP frames sent over IEEE 802.3, 802.4, and 802.5 networks must use the SNAP encapsulation.

The IEEE 802.3 SNAP was created as an extension to the IEEE 802.3 specification to allow protocols that were designed to operate with an Ethernet II header to be used in an IEEE 802.3–compliant environment. Figure 1-4 shows the IEEE 802.3 SNAP frame format.

Figure 1-4: The IEEE 802.3 SNAP frame format showing the SNAP header and an IP datagram.

To denote a SNAP frame, the DSAP and SSAP fields are set to the SNAP-defined value of 0xAA within the LLC header. Because all SNAP-encapsulated payloads are not using reliable LLC services, every SNAP frame is an LLC datagram. Therefore, the Control field is set to 0x03 to indicate a UI frame.

The SNAP header consists of the following two fields:

• The Organization Code field is 3 bytes long and is used to indicate the orga-nization that maintains the meaning of the 2 bytes that follow. For IP data-grams and ARP messages, the Organization Code field is set to 0x00-00-00.
• For the Organization Code field set to 0x00-00-00, the next 2 bytes of the SNAP header are the 2-byte EtherType field. The same values for IP (0x0800) and ARP (0x0806) are used.

Because of the increased overhead of the LLC header (3 bytes total) and the SNAP header (5 bytes), the payload for an IEEE 802.3 SNAP frame has a maximum size of 1492 bytes and a minimum size of 38 bytes. Padding is added when needed to ensure that the payload is at least 38 bytes long.

The following Network Monitor trace (Capture 01-02, included in the Captures folder on the companion CD-ROM) shows the IEEE 802.3 SNAP frame format for an ARPRequest frame:

+ Frame: Base frame properties
 ETHERNET: 802.3 Length = 50
 + ETHERNET: Destination address : FFFFFFFFFFFF
 + ETHERNET: Source address : 00AA004BB147
 ETHERNET: Frame Length : 50 (0x0032)
 ETHERNET: Data Length : 0x0024 (36)
 ETHERNET: Ethernet Data: Number of data bytes remaining = 36 (0x0024)
 LLC: UI DSAP=0xAA SSAP=0xAA C
 LLC: DSAP = 0xAA : INDIVIDUAL : Sub-Network Access Protocol (SNAP)
 LLC: SSAP = 0xAA: COMMAND : Sub-Network Access Protocol (SNAP)
 LLC: Frame Category: Unnumbered Frame
 LLC: Command = UI
 LLC: LLC Data: Number of data bytes remaining = 33 (0x0021)
 SNAP: ETYPE = 0x0806
 SNAP: Snap Organization code = 00 00 00
 SNAP: Snap etype : 0x0806
 SNAP: Snap Data: Number of data bytes remaining = 28 (0x001C)
+ ARP_RARP: ARP: Request, Target IP: 192.168.50.2

Note

The ETHERNET: Data Length, ETHERNET: Ethernet Data, LLC: Frame Category, LLC: LLC Data, and SNAP: Snap Data fields are Network Monitor informational fields and do not correspond to fields that are physically present in the Ethernet header.

By default, TCP/IP for the Windows Server 2003 family and Windows XP uses Ether-net II encapsulation when sending and receiving frames on an Ethernet network.TCP/IP for the Windows Server family 2003 and Windows XP receives both types offrame formats but, by default, only responds with Ethernet II encapsulated frames. To send IEEE 802.3 SNAP encapsulated IP and ARP messages, use the following registry setting:

ArpUseEtherSNAP

Location: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices
TcpipParameters
Data type: REG_DWORD
Valid range: 0–1
Default value: 0
Present by default: No

ArpUseEtherSNAP either enables (when set to 1) or disables (when set to 0) the use of the IEEE 802.3 SNAP frame format when sending IP and ARP frames. ArpUseEtherSNAP is disabled by default, meaning that IP and ARP frames are sent with Ethernet II encapsulation. Regardless of the ArpUseEtherSNAP setting, both types of frame formats are received.

With ArpUseEtherSNAP disabled, TCP/IP for the Windows Server 2003 family andWindows XP recognizes a SNAP-encapsulated ARP Request message and responds with an Ethernet II–encapsulated ARP Reply frame. The assumption is that the node sending the ARP Request message will recognize the Ethernet II encapsulation on the ARP Reply and use Ethernet II encapsulation for subsequent communications. If the node sending the ARP Request does not switch, IP communication between the node sending the ARP Request and the node sending the ARP Reply is impossible.

With ArpUseEtherSNAP enabled, TCP/IP for the Windows Server 2003 family andWindows XP switches to Ethernet II encapsulation if one of the following two scenarios occurs: a SNAP-encapsulated ARP Request frame is responded to with an Ethernet II–encapsulated ARP Reply frame, or an Ethernet II–encapsulated ARP Request is received.

Special Bits on Ethernet MAC Addresses

Within the Source Address and Destination Address fields of the Ethernet II and IEEE 802.3 frame formats, special bits are defined, as Figure 1-5 shows.

Figure 1-5: The special bits defined for Ethernet source and destination MAC addresses.

The Individual/Group Bit

The Individual/Group (I/G) bit is used to indicate whether the address is a unicast(individual) or multicast (group) address. For a unicast address, the I/G bit is set to 0. For a multicast address, the I/G bit is set to 1. The broadcast address is a special case of multicast and its I/G bit is set to 1. The I/G bit is also known as the multicast bit.

The Universal/Locally Administered Bit

The Universal/Locally (U/L) Administered bit is used to indicate whether the IEEE allocated the address. For a universal address allocated by the IEEE, the U/L bit is set to 0. Universal addresses are guaranteed to be universally unique because network adapter manufacturers obtain universally unique vendor identifiers from the IEEE and assign unique 3-byte serial numbers to each network adapter. The 6-byte physical address of a network adapter, as programmed into the adapter during the manufacturing process, is a universally administered address.

For a locally administered address, the U/L bit is set to 1. Some network adapters allow you to override the network adapter's physical address and specify a new physicaladdress. In this case, the new address must have the U/L bit set to 1 to indicate that it is locally administered.

The U/L bit is significant only for unicast addresses (the I/G bit is set to 0). When the I/G bit is set to 1, this bit does not imply a locally or universally administered address. The U/L bit is relevant for both the Source Address and Destination Address.

Routing Information Indicator Bit

The Routing Information Indicator bit indicates whether MAC-level routing information is present. This bit is meaningful only for Token Ring addresses. Token Ring has a MAC-level routing mechanism known as Token Ring source routing. Even though this bit is meaningless for Ethernet addresses, it is still reserved and set to 0 to prevent problems when employing a translating bridge or Layer 2 switch between an Ethernet segment and a Token Ring ring.

For example, suppose the Routing Information Indicator bit is not reserved at the value of 0 for Ethernet addresses, and this bit is set to 1 through a universal or locally administered address. When the address is translated to a Token Ring address, the Routing Information Indicator bit is set to 1 when there is no source routing information present, which can cause the Token Ring node to drop the frame.

The following Network Monitor trace (Capture 01-03, included in the Captures folder on the companion CD-ROM) shows the special bits for Ethernet MAC addresses:

+ Frame: Base frame properties
 ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
 ETHERNET: Destination address : 01005E400009
 ETHERNET: .......1 = Group address
 ETHERNET: ......0. = Universally administered address
 ETHERNET: Source address : 00E034C0A060
 ETHERNET: .......0 = No routing information present
 ETHERNET: ......0. = Universally administered address
 ETHERNET: Frame Length : 591 (0x024F)
 ETHERNET: Ethernet Type : 0x0800 (IP: DOD Internet Protocol)
 ETHERNET: Ethernet Data: Number of data bytes remaining = 577 (0x0241)
+ IP: ID = 0xDBD2; Proto = UDP; Len: 577
+ UDP: IP Multicast: Src Port: Unknown, (3985); Dst Port: Unknown (20441);
 Length = 557 (0x22D)

Token Ring

Token Ring is a ring access network technology originally proposed by Olaf Soderblum in 1969. IBM purchased the rights to the original design and created and released its Token Ring product in 1984. Key elements of the original IBM design were the use of proprietary connectors, twisted-pair cable out to the network node, and structured wiring systems using centralized active hubs.

In 1985, the IEEE Project 802 created the 802.5 subcommittee and Token Ring became an international standard. IBM created Token Ring to replace Ethernet as the most popular LAN technology. Although Token Ring is in many ways a superior technology to Ethernet, a combination of cost issues and marketing has made it less popular than Ethernet.

The original specification was for a 4 Mbps transmission rate, but that was followed by an additional specification at 16 Mbps. On the same ring, all nodes must operate at the same speed. Common implementations use 4-Mbps rings connected together, using 16-Mbps rings as a high-speed backbone.

More Info

IP and ARP encapsulation over Token Ring networks are described in RFC 1042, which can be found in the Rfc folder on the companion CD-ROM.

IEEE 802 5

The IEEE 802.5 frame format is the result of the IEEE 802.2 and 802.5 specifications, and consists of an IEEE 802.5 header and trailer and an IEEE 802.2 LLC header. The IEEE 802.5 frame format is shown in Figure 1-6.

Figure 1-6: The IEEE 802.5 frame format showing the IEEE 802.5 header and trailer and the IEEE 802.2 header.

IEEE 802.5 Header and Trailer

The fields in the IEEE 802.5 header and trailer are defined as follows:

• Start Delimiter The Start Delimiter field is 1 byte long and identifies thestart of the frame. The Start Delimiter field contains nondata symbols known as J and K symbols that are deliberate violations of the Token Ring signal encoding scheme. The J symbol is an encoding violation of a 1 and the K symbol is an encoding violation of a 0. The Start Delimiter field provides a very explicit preamble. Unlike Ethernet, Token Ring frames do not have an interframe gap to separate frames on the wire. The Start Delimiter field also provides synchronization for the receiver.

  Note

  The Start Delimiter field is not visible with Network Monitor.

• Access Control The Access Control field is 1 byte long and contains bits for the following:
  • Setting the current priority of the token (3 bits). An interesting facility of Token Ring is its ability to prioritize access to the token and, therefore, the right to transmit data based on seven priority levels.
  • Setting the token reservation level (3 bits). The token reservation bits set the priority of the token once the station that is currently transmittingreleases it.
  • Indicating whether the frame has passed the ring monitor station (1 bit). As the frame passes the ring monitor station, the Monitor bit is set to 1. If the ring monitor station sees a frame with the Monitor bit set to 1, the frame has already been sent on the ring. The ring monitor station removes the frame from the ring and then purges the ring.
  • Indicating whether the frame that follows is a token or a frame (1 bit). If set to 0, what follows is a token. If set to 1, what follows is a frame.
• Frame ControlThe Frame Control field is 1 byte long and contains bits for the following:
  • Indicating whether the frame that follows is a Token Ring MAC management frame or an LLC frame (2 bits).
  • Indicating the type of Token Ring MAC management frame such as Purge, Claim Token, and Beacon (4 bits).

  Two bits within the Frame Control field are reserved.

• Destination AddressThe Destination Address field is 6 bytes long and indicates the address of the destination. For Token Ring, the Destination Address field can be the following:
  • A universal or locally administered unicast address.
  • The universal broadcast address (0xFF-FF-FF-FF-FF-FF).
  • The Token Ring broadcast address (0xC0-00-FF-FF-FF-FF). A frame using the Token Ring broadcast address is designed to remain on a single ring and is not forwarded by Token Ring source-route bridges.
  • A multicast address.
  • A Token Ring functional address. A functional address is a type of multicast address that is specific to Token Ring and is typically used by Token Ring MAC management frames.
• Source AddressThe Source Address field is 6 bytes long and indicates the sending node's unicast address.
• PayloadThe Payload field for a Token Ring frame consists of a PDU of an upper layer protocol. Unlike Ethernet, there is no minimum frame size and the maximum transmission unit (MTU) for Token Ring is not a defined number, but dependent on factors such as the bit rate and the token holding time. Token ring MTUs are further complicated by the presence of Token Ring source-routing bridges. More information on Token Ring MTUs for IP datagrams can be found in the section entitled "IEEE 802.5 SNAP," later in this chapter.
• Frame Check SequenceThe FCS field is a 4-byte CRC that uses the same algorithm as Ethernet to provide a bit-level integrity check of all fields in the Token Ring frame, from the Frame Control field to the Payload field. The FCS does not provide bit-level integrity for the Access Control or Frame Status fields. This allows bits in these fields, such as the Monitor bit, to be set without forcinga recalculation of the FCS.

  The FCS is checked as it passes each node on the ring. If the FCS fails at any node, the Error bit in the End Delimiter field is set to 1 and the receiving node does not copy the frame.

• End DelimiterThe End Delimiter is a 1-byte field that identifies the end of the frame. Like the Start Delimiter, the End Delimiter contains J and K nondata symbols to provide an explicit postamble. The End Delimiter field also contains the following:
  • An Intermediate Frame indicator (1 bit), used to indicate whether this frame is the last frame in the sequence (when set to 0) or more frames are to follow (when set to 1).
  • An Error Detected indicator (1 bit), used to indicate whether this frame has failed the FCS calculation.

  Because there is no Length field in the IEEE 802.5 frame, the End Delimiter is used to locate the end of the payload and the position of the FCS and Frame Status fields.

• Frame StatusThe Frame Status field is a 1-byte field that contains thefollowing:
  • Two copies of the Address Recognized indicator. The destination node sets the Address Recognized indicators to indicate that the address in the Destination Address field was recognized.
  • Two copies of the Frame Copied indicator. The destination node sets the Frame Copied indicators to indicate that the frame was successfully copied into a buffer on the network adapter.

  Two copies of each indicator are needed because the FCS field does not protect the Frame Status field.

  The Address Recognized and Frame Copied indicators are not used as acknowledgments for reliable data delivery. The sending Token Ring network adapter uses these indicators to retransmit the frame, if necessary.

  Note

  The FCS, End Delimiter, and Frame Status fields are not visible withNetwork Monitor.

IEEE 802.2 LLC Header

The fields in the IEEE 802.2 LLC header are defined and used in the same way as theIEEE 802.2 LLC header for the IEEE 802.3 frame format, as discussed in the sectionentitled "IEEE 802.3," earlier in this chapter.

IEEE 802 5 SNAP

As described earlier in this chapter, the value of 0x06 is defined as the SAP for IP. However, it is not defined for use in RFC 1042 and not used in the industry. Therefore, similar to the case of IEEE 802.3 frames, to send an IP datagram over an IEEE 802.5 network, the IP datagram must be encapsulated using SNAP, as Figure 1-7 shows.

Figure 1-7: The IEEE 802.5 SNAP frame format showing the SNAP header and an IP datagram.

The following Network Monitor trace (Capture 01-04, included in the Captures folder on the companion CD-ROM) shows the IEEE 802.5 SNAP frame format for an IP datagram:

+ Frame: Base frame properties
 TOKENRING: Length = 66, Priority Normal (No token) LLC Frame
 TOKENRING: Access control = 16 (0x10) Original, Frame, Priority: Normal
 (No token)
 TOKENRING: .....000 Reservation bits: Reservation = Normal, No
 token needed.
 TOKENRING: ....0... Monitor bit = Original (non-repeated)
 TOKENRING: ...1.... Token bit = Frame
 TOKENRING: 000..... Priority bits: Priority = Normal, No token
 needed.
 TOKENRING: Frame control = 64 (0x40), LLC Frame
 TOKENRING: ....0000 Control bits = Normal Buffered
 TOKENRING: 01...... Frame type = LLC Frame
 + TOKENRING: Destination address : 400030370AF4
 + TOKENRING: Source address : 10007038213A
 TOKENRING: Frame length : 66 (0x0042)
 TOKENRING: Tokenring data: Number of data bytes remaining = 52 (0x0034)
 LLC: UI DSAP=0xAA SSAP=0xAA C
 LLC: DSAP = 0xAA : INDIVIDUAL : Sub-Network Access Protocol (SNAP)
 LLC: SSAP = 0xAA: COMMAND : Sub-Network Access Protocol (SNAP)
 LLC: Frame Category: Unnumbered Frame
 LLC: Command = UI
 LLC: LLC Data: Number of data bytes remaining = 49 (0x0031)
 SNAP: ETYPE = 0x0800
 SNAP: Snap Organization code = 00 00 00
 SNAP: Snap etype : 0x0800
 SNAP: Snap Data: Number of data bytes remaining = 44 (0x002C)
+ IP: ID = 0xCA3D; Proto = TCP; Len: 44
+ TCP: ....S., len: 0, seq:364446-364446, ack: 0, win: 16384, src:50982
 dst: 21

Note

The TOKENRING: Frame length, TOKENRING: Tokenring data, LLC: Frame Category, LLC: LLC Data, and SNAP: Snap Data fields are Network Monitor informational fields and do not correspond to fields that are physically present in the Token Ring header.

For a 10-millisecond (ms) token-holding time, the maximum sizes for IP datagrams are 4464 bytes for 4-Mbps Token Ring network adapters and 17,914 bytes for 16-Mbps Token Ring network adapters. If Token Ring source-routing bridges are present, the maximum size of IP datagrams can be 508, 1020, 2044, 4092, and 8188 bytes.

More Info

For more information on Token Ring MTUs, see RFC 1042 in the Rfc folder on the companion CD-ROM.

Special Bits on Token Ring MAC Addresses

Within the Source Address and Destination Address fields of the IEEE 802.5 frame format, special bits are defined, as shown in Figure 1-8.

Figure 1-8: The special bits defined on Token Ring source and destination MAC addresses.

The Individual/Group Bit

Identical to Ethernet, the I/G bit for Token Ring addresses is used to indicate whether the address is a unicast (individual) or multicast (group) address. For unicast addresses, the I/G bit is set to 0. For multicast addresses, the I/G bit is set to 1.

The Universal/Locally Administered Bit

Identical to Ethernet, the U/L Administered bit for Token Ring addresses is used to indicate whether the IEEE has allocated the address. For universal addresses allocated by the IEEE, the U/L bit is set to 0. For locally administered addresses, the U/L bit is set to 1. The U/L bit is relevant for both the Source Address and Destination Address fields.

Functional Address Bit

The Functional Address bit indicates whether the address is a functional address (when set to 0) or a nonfunctional address (when set to 1). Token Ring defines the following two types of multicast addresses:

• Functional addressesMulticast addresses that are specific to Token Ring. There are specific functional addresses for identifying the ring monitor, the ring-parameter server, and a source-routing bridge.
• Nonfunctional addressesGeneral multicast addresses that are not Token Ring–specific.

The Functional Address bit is significant only if the I/G bit is set to 1.

Routing Information Indicator Bit

The Routing Information Indicator bit indicates whether MAC-level routing information is present. In the case of Token Ring, the Routing Information Indicator bit indicates the presence of a source-routing header between the IEEE 802.5 header and the IEEE 802.2 LLC header. Token Ring source routing is not OSI Network Layer routing, but rather a MAC sublayer routing scheme that allows a sending node to discover and specify a route through a defined series of rings and bridges within a Token Ring network segment.

The following Network Monitor trace (Capture 01-04, included in the Captures folder on the companion CD-ROM) shows the special bits for Token Ring addresses:

+ Frame: Base frame properties
 TOKENRING: Length = 66, Priority Normal (No token) LLC Frame
 + TOKENRING: Access control = 16 (0x10) Original, Frame, Priority: Normal
 (No token)
 + TOKENRING: Frame control = 64 (0x40), LLC Frame
 TOKENRING: Destination address : 400030370AF4
 TOKENRING: Destination Address I/G Bit = Individual address
 TOKENRING: Destination Address U/L bit = Locally administered
 address
 TOKENRING: Destination Address Functional bit = Functional address
 TOKENRING: Source address : 10007038213A
 TOKENRING: Source Address Routing bit = No routing information
 present
 TOKENRING: Source Address U/L bit = Universally administered
 address
 TOKENRING: Frame length : 66 (0x0042)
 TOKENRING: Tokenring data: Number of data bytes remaining = 52 (0x0034)
+ LLC: UI DSAP=0xAA SSAP=0xAA C
+ SNAP: ETYPE = 0x0800 + IP: ID = 0x21E0; Proto = TCP; Len: 44
+ TCP: ....S., len: 0, seq:1891988225-1891988225, ack: 0,
 win: 8192, src:50982 dst: 3180

FDDI

FDDI is a network technology developed by the American National Standards Institute (ANSI). FDDI is an optical fiber-based token passing ring with a bit rate of 100 Mbps. It was designed to span long distances and, in most implementations, it acts as a campus-wide high-speed backbone. FDDI offers advanced features beyond Token Ring, such as the ability to self-heal a break in the ring and the use of guaranteed bandwidth.

Although not developed by the IEEE as part of the 802 standards, the FDDI specification is quite similar to the IEEE 802.3 and 802.5 specifications; it defines the MAC sublayer of the OSI Data Link Layer and the Physical Layer, and it uses the IEEE 802.2 LLC sublayer. Copper Data Distributed Interface (CDDI) is a version of FDDI that operates over twisted-pair copper wire.

More Info

RFC 1188 describes IP encapsulation over FDDI networks. You can find RFC 1188 in the Rfc folder on the companion CD-ROM.

FDDI Frame Format

The FDDI frame format is the result of the IEEE 802.2 and ANSI FDDI specifications, and consists of an FDDI header and trailer and an IEEE 802.2 LLC header. Figure 1-9 shows the FDDI frame format.

Figure 1-9: The FDDI frame format showing the FDDI header and trailer and IEEE 802.2 header.

FDDI Header and Trailer

The fields in the FDDI header and trailer are defined as follows:

• PreambleThe Preamble field is 2 bytes long and provides receiver synchronization.
• Start DelimiterThe Start Delimiter field is 1 byte long and identifies the start of the frame. Like Token Ring, the Start Delimiter field contains nondata symbols known as J and K symbols that are deliberate violations of the FDDI signal encoding scheme. The J symbol is an encoding violation of a 1 and the K symbol is an encoding violation of a 0.

  Note

  The Preamble and Start Delimiter fields are not visible with Network Monitor.

• Frame ControlThe Frame Control field is 1 byte long and contains bits for the following:
  • Setting the class of the frame (1 bit). FDDI frames can be sent as synchronous or asynchronous frames. Synchronous frames are used for guaranteed bandwidth and response time. Asynchronous frames are used for dynamic bandwidth sharing. The Class bit is set to 1 for synchronous frames and 0 for asynchronous frames.
  • Setting the length of the Destination Address and the Source Address fields (1 bit). Like IEEE 802.3, FDDI supports 2-byte and 6-byte addresses. The Address bit is set to 1 for 6-byte addresses and 0 for 2-byte addresses.
  • Indicating that what follows is a token (either nonrestricted or restricted), a station management frame, a MAC frame, an LLC frame, or an LLC frame with a specific priority (6 bits).
• Destination AddressThe Destination Address field is either 2 bytes or 6 bytes long and indicates the address of the destination (2-byte addresses are seldom used). For 6-byte addresses, FDDI Destination Address fields are defined the same as Ethernet Destination Address fields to provide easy interoperability between bridged or Layer 2 switched Ethernet and FDDI segments. The destination address is a unicast, multicast, or broadcast address.
• Source AddressThe Source Address field is either 2 bytes or 6 bytes long and indicates the unicast address of the sending node (2-byte addresses are seldom used).
• Frame Check SequenceThe FCS field is a 4-byte CRC that uses the same algorithm as Ethernet to provide a bit-level integrity check of all fields in the FDDI frame, from the Frame Control field to the Payload field. The FCS is checked as it passes each node on the ring. If the FCS fails at any node, the Error bit in the Frame Status field is set to 1 and the receiving node does not copy the frame.
• End DelimiterThe End Delimiter field is 1 byte long and identifies the end of the frame. Like the Start Delimiter field, the End Delimiter field contains J and K nondata symbols to provide an explicit postamble. Because there is no Length field in the FDDI frame, the End Delimiter field is also used to locate the end of the payload, and the position of the FCS and Frame Status fields.
• Frame StatusThe Frame Status field is typically 2 bytes long and contains bits for the following:
  • The Address Recognized indicatorThe destination node sets the Address Recognized indicator to show that the address in the Destination Address field was recognized.
  • The Frame Copied indicatorThe destination node sets the Frame Copied indicator to show that the frame was successfully copied into a buffer on the network adapter.
  • The Error indicatorAny FDDI station sets the Error indicator to 1 when the FCS field is invalid.

  Similar to Token Ring, the Address Recognized and Frame Copied indicators are not used as acknowledgments for reliable data delivery. Rather, the sending FDDI network adapter uses these indicators to retransmit the frame if necessary.

  Note

  The FCS, End Delimiter, and Frame Status fields are not visible withNetwork Monitor.

IEEE 802.2 LLC Header

The fields in the IEEE 802.2 LLC header are defined and used in the same way as the IEEE 802.2 LLC header for the IEEE 802.3 and IEEE 802.5 frame format discussed earlier in this chapter.

Payload

The payload for an FDDI frame consists of a PDU of an upper layer protocol. The entire FDDI frame from the Preamble field to the Frame Status field can be a maximum size of 4500 bytes. Once you subtract the FDDI and IEEE 802.2 LLC headers, the maximum payload size is 4474 bytes with a 3-byte LLC header, and 4473 bytes with a 4-byte LLC header.

FDDI SNAP

As described earlier in this chapter, the value of 0x06 is defined as the SAP for IP.However, it is not defined for use in RFC 1188 and not used in the industry. Therefore, similar to the case of IEEE 802.3 frames and IEEE 802.5 frames, to send an IP datagram over an FDDI network, the IP datagram must be encapsulated using the SNAP header, as shown in Figure 1-10.

Figure 1-10: The FDDI SNAP frame format showing the SNAP header and an IP datagram.

The following Network Monitor trace (Capture 01-05, included in the Captures folder on the companion CD-ROM) shows the FDDI SNAP frame format for an IP datagram:

+ Frame: Base frame properties
 FDDI: Length = 81, type = 0x57 (LLC).
 FDDI: Frame control bits = 87 (0x57)
 FDDI: ..01.... = LLC frame
 FDDI: 0....... = Asynchronous frame
 FDDI: .1...... = 48-bit addresses
 + FDDI: Destination address : 00608C14AF25
 + FDDI: Source address : 00608C13182A
 FDDI: Frame Length : 81 (0x0051)
 FDDI: Fddi Data: Number of data bytes remaining = 68 (0x0044)
 LLC: UI DSAP=0xAA SSAP=0xAA C
 LLC: DSAP = 0xAA : INDIVIDUAL : Sub-Network Access Protocol (SNAP)
 LLC: SSAP = 0xAA: COMMAND : Sub-Network Access Protocol (SNAP)
 LLC: Frame Category: Unnumbered Frame
 LLC: Command = UI
 LLC: LLC Data: Number of data bytes remaining = 65 (0x0041)
 SNAP: ETYPE = 0x0800
 SNAP: Snap Organization code = 00 00 00
 SNAP: Snap etype : 0x0800
 SNAP: Snap Data: Number of data bytes remaining = 60 (0x003C)
+ IP: ID = 0xA665; Proto = ICMP; Len: 60
+ ICMP: Echo: From 192.168.44.01 To 192.168.44.254

Note

The FDDI: Frame Length, FDDI: Fddi Data, LLC: Frame Category, LLC: LLC Data, and SNAP: Snap Data fields are Network Monitor informational fields and do not correspond to fields that are physically present in the FDDI header.

The maximum-sized IP datagram that can be sent on an FDDI network is 4352 bytes. This number of bytes is the result of taking the maximum FDDI frame size of 4500 bytes and subtracting the FDDI header and trailer (22 bytes), the LLC header (3 bytes), and the SNAP header (5 bytes), and reserving 117 bytes for future purposes.

IP datagrams and ARP messages sent over FDDI networks also have the following constraints:

• Only 6-byte FDDI source and destination addresses can be used.
• All IP and ARP frames are transmitted as asynchronous class LLC frames using unrestricted tokens.

RFC 1188 does not define how frame priorities are used or how the FDDI node deals with the values of the Address Recognized and Frame Copied indicators.

FDDI nodes send ARP Requests using the Ethernet ARP Hardware Type value of 0x00-01, but can receive ARP Requests using the ARP Hardware Types of 0x00-01 and 0x00-06 (IEEE networks). The use of the Ethernet ARP Hardware Type value is designed to allow FDDI hosts and Ethernet hosts in a bridged or Layer 2 switched environment to send and receive ARP messages.

Special Bits on FDDI MAC Addresses

Because FDDI MAC addresses are defined in the same way as Ethernet MAC addresses, the special bits on FDDI MAC addresses are the same as those defined for Ethernet MAC addresses.

The Network Monitor trace shown in Capture 01-05 (included in the Captures folder on the companion CD-ROM) shows the special bits in the FDDI header.

IEEE 802 11

IEEE 802.11 is a set of standards for wireless LAN technologies. The original 802.11 standard defines wireless networking using either 1 Mbps or 2 Mbps bit rates in the Industrial, Scientific, and Medical (ISM) 2.54 gigahertz (GHz) frequency band. IEEE 802.11b defines a maximum bit rate of 11 Mbps in the 2.54 GHz ISM band. IEEE 802.11a defines a maximum bit rate of 54 Mbps in the 5.8 GHz band. IEEE 802.11b is by far the most widely deployed of the IEEE 802.11 standards.

At the MAC sublayer, IEEE 802.11 (all versions) uses a combination of congestion avoidance and Request to Send (RTS), Clear to Send (CTS), and Acknowledgment (ACK) frames to ensure that only one wireless node is transmitting at a time and that the sent frame is successfully received.

IEEE 802.11 wireless nodes can communicate in the following ways:

• Directly with each other using an operating mode known as ad hoc mode.
• With a wireless access point (AP) using an operating mode known as infrastructure mode. In infrastructure mode, the wireless AP acts as a transparent bridge connecting wireless nodes to a wired network.

To identify a wireless network in either operating mode, IEEE 802.11 uses a Service Set Identifier (SSID).

Because wireless networking uses broadcast radio waves, a wireless node within range of a transmitting wireless node can capture IEEE 802.11 frames and interpret the data. To provide a level of security that is equivalent to a wired network, IEEE 802.11 uses Wired Equivalent Privacy (WEP) to provide data confidentiality (encryption) for IEEE 802.11 payloads.

IEEE 802 11 Frame Format

The IEEE 802.11 frame format consists of an IEEE 802.11 header and trailer and an IEEE 802.2 LLC header. Figure 1-11 shows the IEEE 802.11 frame format.

Figure 1-11: The IEEE 802.11 frame format showing the IEEE 802.11 header and trailer and the IEEE 802.2 header.

IEEE 802.11 Header and Trailer

The fields in the IEEE 802.11 header and trailer for a data frame sent by wireless nodes or by a wireless AP to a wireless node are defined as follows:

• Frame ControlA 2-byte field that contains control information that defines the type of frame and how to process the frame. For more information, see the section entitled "Frame Control Field," later in this chapter.
• Duration/ID FieldA 2-byte field that is used to indicate the duration of time in microseconds needed to transmit the frame and the acknowledgment.
• Address 1A 6-byte field that contains either the destination MAC address of a wireless node (when sent by a wireless node to another wireless node in ad hoc mode or sent by the wireless AP to the wireless node) or the SSID (when sent by a wireless node to a wireless AP).
• Address 2A 6-byte field that contains either the MAC address of the send-ing node (when sent to another wireless node in ad hoc mode or sent to the wireless AP) or the SSID (when sent by the wireless AP to a wireless node).
• Address 3A 6-byte field that contains the SSID for frames sent to another wireless node in ad hoc mode, the source address for frames sent from the wireless AP to a wireless node, or the destination address for frames sent from a wireless node to the wireless AP.
• Sequence ControlA 2-byte field that contains a 4-bit Fragment Number field and a 12-bit Sequence Number field that, when used together, allow the receiver to discard duplicate frames. When a frame is fragmented, the Fragment Number field is used to indicate the number of the fragment. Otherwise, the Fragment Number field is set to 0. The Sequence Number field indicates the number of the frame starting at 0, incrementing to 4095, and then starting again at 0. All fragments of a frame have the same sequence number.
• Address 4A 6-byte field that contains the MAC address of the originating wireless node. This field is typically present only in frames in which both the To DS and From DS flags in the Frame Control field are set to 1, indicating inter-wireless AP communication.
• Frame Check SequenceA 4-byte CRC that uses the same algorithm as Ethernet to provide a bit-level integrity check of all fields in the IEEE 802.11 frame, from the Frame Control field to the Payload field.

IEEE 802.2 LLC Header

The fields in the IEEE 802.2 LLC header are defined and used in the same way as the IEEE 802.2 LLC header for the IEEE 802.3, IEEE 802.5, and FDDI frame formats discussed earlier in this chapter.

Payload

The payload for an IEEE 802.11 frame can be a maximum size of 2312 bytes. IEEE 802.11 payloads can be MAC management frames (such as beacon frames sent by wireless APs), control fames (such as RTS, CTS, and ACK frames), or data frames containing the PDU of an upper layer protocol (such as an IP datagram). If the payload of a data frame is encrypted with WEP, the upper layer PDU is preceded by a plaintext 4-byte Initialization Vector (IV) field and followed with an encrypted 4-byte Integrity Check Value (ICV) field, lowering the maximum upper layer PDU size to 2304 bytes. The IV and ICV fields are not shown in Figure 1-11.

Frame Control Field

Figure 1-12 shows the Frame Control field.

Figure 1-12: The Frame Control field in the IEEE 802.11 header.

The Frame Control field contains the following subfields:

• Protocol VersionA 2-bit field that indicates the version of the 802.11 protocol used to construct the frame. This field is set to 0 for the current versionof IEEE 802.11. If the Protocol Version field is set to a value that is not supported by the receiving wireless node, the frame is silently discarded.
• TypeA 2-bit field that indicates the type of IEEE 802.11 frame. There are three defined values: 00 for management frames, 01 for control frames, and 10 for data frames. The value of 11 is currently reserved.
• SubtypeA 4-bit field that indicates the specific type of management, control, or data frame.
• To DSA 1-bit flag that indicates (when set to 1) that the frame is destined for the distribution system (DS), the wired network that connects wireless APsand provides access to wired network nodes. Only wireless nodes that are operating in infrastructure mode set this flag.
• From DSA 1-bit flag that indicates (when set to 1) that the frame is originating from the wired network. This flag is only set by the wireless AP when forwarding a frame to a wireless node operating in infrastructure mode.
• More FragmentsA 1-bit flag that indicates (when set to 1) that there are more fragments of the frame for which this frame is also a fragment. If the frame is not fragmented or is the last fragment of a fragmented frame, the More Fragments flag is set to 0.
• RetryA 1-bit flag that indicates (when set to 1) that this frame is a retransmission of a previously transmitted frame.
• Power ManagementA 1-bit flag that indicates (when set to 1) that the transmitting wireless node is operating in a power-saving mode.
• More DataA 1-bit flag that indicates (when set to 1) that the wireless AP has at least one frame buffered to send to the wireless node.
• WEPA 1-bit flag that indicates (when set to 1) that the payload is encrypted with WEP.
• OrderA 1-bit flag that indicates (when set to 1) that the frames must be processed in order.

IEEE 802 11 SNAP

An IP datagram sent over an IEEE 802.11 network must be encapsulated with a SNAP header. Figure 1-13 shows SNAP encapsulation for IP datagrams sent over an IEEE 802.11 link (rather than between wireless APs).

Figure 1-13: The IEEE 802.11 SNAP frame format showing the SNAP header and an IP datagram.

Note

Because IEEE 802.11 network adapters are represented inside theWindows Server 2003 family and Windows XP as Ethernet adapters, IEEE 802.11 frames captured with Network Monitor are displayed with an Ethernet II header.

Summary

LAN technology encapsulations provide delimitation, addressing, protocol identification, and bit-level integrity services. IP datagrams and ARP messages sent over Ethernet links are encapsulated using either the Ethernet II or IEEE 802.3 SNAP frame formats.IP datagrams and ARP messages sent over Token Ring links are encapsulated using the IEEE 802.5 SNAP frame format. IP datagrams and ARP messages sent over FDDI links are encapsulated using the FDDI SNAP frame format. IP datagrams and ARP messages sent over IEEE 802.11 links are encapsulated using the IEEE 802.11 SNAP frame format.