To provide service to the network layer, the data link layer must use the service
provided to it by the physical layer. What the physical layer does is accept a
raw bit stream and attempt to deliver it to the destination. If the channel is noisy,
as it is for most wireless and some wired links, the physical layer will add some
redundancy to its signals to reduce the bit error rate to a tolerable level. However,
the bit stream received by the data link layer is not guaranteed to be error free.
Some bits may have different values and the number of bits received may be less
than, equal to, or more than the number of bits transmitted. It is up to the data
link layer to detect and, if necessary, correct errors.
The usual approach is for the data link layer to break up the bit stream into discrete frames, compute a short token called a checksum for each frame, and include the checksum in the frame when it is transmitted. When a frame arrives at the destination, the checksum is recomputed. If the newly computed checksum is different from the one contained in the frame, the data link layer knows that an error has occurred and takes steps to deal with it (e.g., discarding the bad frame and possibly also sending back an error report).
Breaking up the bit stream into frames is more difficult than it at first appears. A good design must make it easy for a receiver to find the start of new frames while using little of the channel bandwidth. We will look at four methods:
1. Byte count.
2. Flag bytes with byte stuffing.
3. Flag bits with bit stuffing.
4. Physical layer coding violations.
The first framing method uses a field in the header to specify the number of bytes in the frame. When the data link layer at the destination sees the byte count, it knows how many bytes follow and hence where the end of the frame is.
The trouble with this algorithm is that the count can be garbled by a transmission error.. It will then be unable to locate the correct start of the next frame. Even if the checksum is incorrect so the destination knows that the frame is bad, it still has no way of telling where the next frame starts. Sending a frame back to the source asking for a retransmission does not help either, since the destination does not know how many bytes to skip over to get to the start of the retransmission. For this reason, the byte count method is rarely used by itself.
With bit stuffing, the boundary between two frames can be unambiguously
recognized by the flag pattern. Thus, if the receiver loses track of where it is, all
it has to do is scan the input for flag sequences, since they can only occur at frame
boundaries and never within the data.
Many data link protocols use a combination of these methods for safety. A common pattern used for Ethernet and 802.11 is to have a frame begin with a well-defined pattern called a preamble. This pattern might be quite long (72 bits is typical for 802.11) to allow the receiver to prepare for an incoming packet. The preamble is then followed by a length (i.e., count) field in the header that is used to locate the end of the frame.
The usual approach is for the data link layer to break up the bit stream into discrete frames, compute a short token called a checksum for each frame, and include the checksum in the frame when it is transmitted. When a frame arrives at the destination, the checksum is recomputed. If the newly computed checksum is different from the one contained in the frame, the data link layer knows that an error has occurred and takes steps to deal with it (e.g., discarding the bad frame and possibly also sending back an error report).
Breaking up the bit stream into frames is more difficult than it at first appears. A good design must make it easy for a receiver to find the start of new frames while using little of the channel bandwidth. We will look at four methods:
1. Byte count.
2. Flag bytes with byte stuffing.
3. Flag bits with bit stuffing.
4. Physical layer coding violations.
The first framing method uses a field in the header to specify the number of bytes in the frame. When the data link layer at the destination sees the byte count, it knows how many bytes follow and hence where the end of the frame is.
The trouble with this algorithm is that the count can be garbled by a transmission error.. It will then be unable to locate the correct start of the next frame. Even if the checksum is incorrect so the destination knows that the frame is bad, it still has no way of telling where the next frame starts. Sending a frame back to the source asking for a retransmission does not help either, since the destination does not know how many bytes to skip over to get to the start of the retransmission. For this reason, the byte count method is rarely used by itself.
(a) Without errors. (b) With one error.
The second framing method gets around the problem of resynchronization
after an error by having each frame start and end with special bytes. Often the
same byte, called a flag byte, is used as both the starting and ending delimiter.Two consecutive flag bytes indicate
the end of one frame and the start of the next. Thus, if the receiver ever loses synchronization
it can just search for two flag bytes to find the end of the current
frame and the start of the next frame.
However, there is a still a problem we have to solve. It may happen that the
flag byte occurs in the data, especially when binary data such as photographs or
songs are being transmitted. This situation would interfere with the framing. One
way to solve this problem is to have the sender’s data link layer insert a special
escape byte (ESC) just before each ‘‘accidental’’ flag byte in the data. Thus, a
framing flag byte can be distinguished from one in the data by the absence or
presence of an escape byte before it. The data link layer on the receiving end removes
the escape bytes before giving the data to the network layer. This technique
is called byte stuffing.
Of course, the next question is: what happens if an escape byte occurs in the
middle of the data? The answer is that it, too, is stuffed with an escape byte. At
the receiver, the first escape byte is removed, leaving the data byte that follows it
(which might be another escape byte or the flag byte).In all cases, the byte sequence delivered after destuffing is exactly
the same as the original byte sequence. We can still search for a frame boundary
by looking for two flag bytes in a row, without bothering to undo escapes.
The byte-stuffing scheme depicted in figure is a slight simplification of the
one used in PPP (Point-to-Point Protocol), which is used to carry packets over
communications links.
(a) A frame delimited by flag bytes. (b) Four examples of byte sequences
before and after byte stuffing.
The third method of delimiting the bit stream gets around a disadvantage of
byte stuffing, which is that it is tied to the use of 8-bit bytes. Framing can be also
be done at the bit level, so frames can contain an arbitrary number of bits made up
of units of any size. It was developed for the once very popular HDLC (Highlevel
Data Link Control) protocol. Each frame begins and ends with a special
bit pattern, 01111110 or 0x7E in hexadecimal. This pattern is a flag byte. Whenever
the sender’s data link layer encounters five consecutive 1s in the data, it
automatically stuffs a 0 bit into the outgoing bit stream. This bit stuffing is analogous
to byte stuffing, in which an escape byte is stuffed into the outgoing character
stream before a flag byte in the data. It also ensures a minimum density of
transitions that help the physical layer maintain synchronization. USB (Universal
Serial Bus) uses bit stuffing for this reason.
When the receiver sees five consecutive incoming 1 bits, followed by a 0 bit,
it automatically destuffs (i.e., deletes) the 0 bit. Just as byte stuffing is completely
transparent to the network layer in both computers, so is bit stuffing. If the user
data contain the flag pattern, 01111110, this flag is transmitted as 011111010 but
stored in the receiver’s memory as 01111110.
Bit stuffing. (a) The original data. (b) The data as they appear on
the line. (c) The data as they are stored in the receiver’s memory after destuffing.
With both bit and byte stuffing, a side effect is that the length of a frame now
depends on the contents of the data it carries. For instance, if there are no flag
bytes in the data, 100 bytes might be carried in a frame of roughly 100 bytes. If,
however, the data consists solely of flag bytes, each flag byte will be escaped and
the frame will become roughly 200 bytes long. With bit stuffing, the increase
would be roughly 12.5% as 1 bit is added to every byte.
The encoding of bits as signals often includes redundancy to
help the receiver. This redundancy means that some signals will not occur in regular
data. For example, in the 4B/5B line code 4 data bits are mapped to 5 signal
bits to ensure sufficient bit transitions. This means that 16 out of the 32 signal
possibilities are not used. We can use some reserved signals to indicate the start
and end of frames. In effect, we are using ‘‘coding violations’’ to delimit frames.
The beauty of this scheme is that, because they are reserved signals, it is easy to
find the start and end of frames and there is no need to stuff the data.
Many data link protocols use a combination of these methods for safety. A common pattern used for Ethernet and 802.11 is to have a frame begin with a well-defined pattern called a preamble. This pattern might be quite long (72 bits is typical for 802.11) to allow the receiver to prepare for an incoming packet. The preamble is then followed by a length (i.e., count) field in the header that is used to locate the end of the frame.
No comments:
Post a Comment