|
|
Most people know that 802.11 provides wireless access to wired networks with the use of an access point (AP). In what is commonly referred to as ad-hoc or Independent Basic Service Set (IBSS) mode, 802.11 can also be used without an AP. Because those concerned about wireless security are not usually talking about ad-hoc networks, and because the details of the 802.11 protocol change dramatically when in ad-hoc mode, this section covers running 802.11 in infrastructure mode (with an AP), unless otherwise specified.
One of the most important aspects of the 802.11 standard is the rules laid down for Media Access Control (MAC). Regardless of the physical layer 802.11 is implemented on (2.4-GHz ISM band, 5-GHz UNII band, and so on), the MAC rules stay the same.
The 802.11 standard specifies two modes in which MAC can operate: contention free and contention based. In contention-based MAC, stations basically fight for access to the media. Similar to Ethernet, when a station wants to transmit first, it checks to see if another station is using the wire. In an Ethernet network, a station waits until the media is not in use and then transmits the packet. If another station transmits at the same time, it will detect the collision and randomly back off. This makes Ethernet a carrier sense multiple access/collision detection (CSMA/CD)–based algorithm.
When 802.11 is operating in contention-based mode, it uses a similar technique. The biggest difference is that most 802.11 cards only have one radio, which means they can transmit or receive, but not both at the same time, making collision detection impossible. Instead, 802.11 needs to employ collision avoidance, making the protocol CSMA/CA - based, not CSMA/CD. This mode, known as the Distributed Coordination Function (DCF), is the mode that almost all 802.11 networks operate under. In DCF mode, the station waits until the media is clear and then transmits data. After completing the transmission, the station waits for an acknowledgment message from the recipient to indicate the data was received successfully. If the acknowledgment message is not received, the data is retransmitted and marked to let the recipient know the station is sending the data again.
 |
While the DCF mechanism to transmit and wait for an acknowledgment is effective at ensuring a single destination host has received the transmitted data successfully, the mechanism fails to accommodate traffic with multiple recipients. If a station is sending data as a broadcast packet (destination MAC address is ff:ff:ff:ff:ff:ff) or a multicast packet (data sent to a group of recipients), it doesn't know how many hosts are on the network to identify if one or more stations missed the data. Further, if all the destination hosts were to return a positive acknowledgment simultaneously for a single received packet, it would cause massive collisions and pandemonium on the network. Appropriately, the IEEE 802.11 MAC specification indicates that positive acknowledgment messages should only be sent in response to unicast data, or traffic sent to a single destination host. This leaves stations transmitting broadcast or multicast traffic without an 802.11 mechanism to detect if their traffic was sent properly, instead relying on upper-layer protocols to determine if the station needs to retransmit, which is a performance detriment.
|
The other mode in which 802.11 MAC can operate is called Point Coordination Function (PCF). In this mode, the access point controls all access to the media. In some sense, this mode of operation is superficially similar to that of token ring; instead of stations passing around a token, however, the AP polls them to see if they have any data to transmit.
The biggest similarity between running an 802.11 network using the PCF and token ring is that of market share. I am unaware of any products that actually implement the PCF mode, but it persists in the standard. In the future, as 802.11 networks get more congested and collisions take up a significant amount of bandwidth, the PCF may be more widely deployed. Since there are no real-world networks using the PCF, its details are largely omitted from this chapter.
The 802.11 MAC is very complicated. There are two huge reasons for this. First, the standard is overly ambitious. The type of MAC that is well suited to embedded systems is not necessarily well suited to laptops. 802.11 tries to be everything to everyone, and it appears to be succeeding-at least in terms of market share. Second, it has problems that have no wired-side analogy. The biggest of these are noisy links due to interference and hidden nodes. All of these reasons provide motivation for a link layer standard brimming with features.
Unfortunately, this surplus of features makes the standard a huge burden to implement correctly, which has led to many implementation bugs that can actually result in remote code execution. This excess of features is only going to continue, however, as the IEEE continues to add features to an already overburdened protocol. Things to look for in the future include 802.11e Quality of Service (ratified as a standard in 2005) and 802.11k Radio Resource Management (still just a draft). Not all additional features being considered for 802.11 are bad, however. IEEE 802.11w is adding support for authenticated management frames, a feature that would greatly improve the overall security of wireless LANs.
Now that you understand the motivation for all of the 802.11 features (and you've been warned about the excessive features to come), let's look at the features currently implemented. This section focuses on the basics of the 802.11 protocol, as it can be found in the wild. For the sake of brevity, it largely ignores 802.11e QoS. If 802.11e is in use, things get significantly more complex.
In 802.11, almost every frame sent is acknowledged. Usually positive acknowledgment is found in transport (layer four) protocols, such as TCP. Though it is true that reliable higher-layer protocols, such as TCP, would eventually cause a dropped 802.11 packet to be retransmitted, the 802.11 committee decided this would cause too much delay.
A big advantage to having positive acknowledgment at the link layer is that it can be combined with fragmentation (or simply a small maximum transmission unit to begin with) to ensure only small amounts of data need to be retransmitted in case of a collision. Radio interference is quite often in small bursts. If these bursts occur during transmission of one small fragment instead of a large packet, less time is wasted on retransmission.
One thing that makes 802.11 unique is that it is a link layer protocol with support for fragmentation. Most network layer protocols (including IP) have support for fragmentation. When fragmenting at the network layer, however, the final destination must perform reassembly. Fragmenting at the link layer forces the next hop to perform reassembly.
Using fragmentation can help increase throughput across a noisy link. Instead of having to retransmit a single large frame when there is a collision or noise, the sender can break up the frame into many smaller fragments and only retransmit the fragments that get corrupted. Of course, having an MTU set to small, or sending unnecessarily small fragments, negatively impacts throughput.
Here's something you won't find in very many link layer protocols: built-in support for power savings. Because the designers knew that most clients on a wireless network would be running on batteries, they included features to improve battery life for clients.
Power savings in 802.11 works by letting clients turn their radios off during periods of inactivity. Basically, the clients inform the AP that they are disabling their radio, at which point the AP will buffer frames for the client. Sleeping stations must wake up periodically and examine beacon frames. These beacon frames carry a Traffic Indication Map (TIM), which is a bitmap that indicates what stations have buffered packets.
Once a station realizes that a packet is waiting for it, it transmits a PS-Poll frame. When the AP receives a PS-Poll, it transmits a single buffered frame back to the station. This process is repeated until all buffered frames have been received.
There is a clever feature to this protocol. Since the AP periodically transmits information about a client's buffered traffic, sleeping clients don't need to transmit any packets to discover they have packets waiting. A sleeping client can power up the receiver, discover it has no packets waiting, and power it back down, all without transmitting anything.
One of the unique aspects of 802.11 is that two nodes can be connected to the same AP, but not hear each other's transmissions. This is called the hidden node problem, and it is illustrated in Figure 3-1.
Since the AP can hear both clients' transmissions, it is possible for two clients to cause a collision at the AP. To avoid collisions, the 802.11 committee included two interesting control packets: Request To Send (RTS) and Clear To Send (CTS). Figure 3-2 shows a collision at the AP caused by two stations who can't hear each other. The reason this is a problem is because B cannot hear A's transmission. If B was within range of A's radio, station B would wait until A finished.
In an effort to prevent these sorts of collisions, stations can use RTS/CTS packets. In this case, as shown in Figure 3-3, instead of transmitting a data packet, A transmits an RTS. When the AP receives the RTS, it responds with a CTS. The CTS packet tells everyone in range (except A) not to transmit for a specified duration in microseconds. Because B can hear the CTS coming from the AP, B won't transmit during A's timeslot, and the collision is avoided.
|
|
