The Rationale for Using a Reliable Data Link
Why should the data link layer be connection-oriented when there are other reliable protocol layers already running on top of it?
Why should there be reliability at the Data Link layer when Layer 4 protocols (such as TCP, SPX, or NetBIOS) already offer connection-oriented services? The answer is that lower layers operate faster than higher layers.
Consider these situations (and realize that they could be occurring either on a local network or across many bridges, routers, and WAN links in an internet work).
When an application makes a disk read request, how long should it wait before deciding that the disk has not responded?
When a station sends a frame to a file server, how long should it wait without receiving an acknowledgment before it retransmits the frame?
When a station electrically generates a frame on a cable, how long should it wait before deciding that the frame was electrically corrupted and in need of retransmission?
You see, at the physical level, Ethernet retransmits almost instantaneously (roughly .0003 seconds; three-tenths of a millisecond). LLC is willing to wait a little longer to get the frame across the single data link and receive an acknowledgment (perhaps 5 or 10 milliseconds; .005 seconds). TCP or SPX, at Layer 4, must be willing to wait for an acknowledgment coming back from, potentially, the other side of a router or WAN link. It will wait even a longer period of time (perhaps in the range of several seconds). The application itself must be willing to wait for a request to be processed. This might take quite a long time (perhaps 10’s of seconds)
When a frame is transmitted across an internet work and it gets corrupted on some intervening data link it is possible for Type 2 LLC to recover the frame on the intervening link without the conversation having to wait the much longer time required for end-to-end Layer 4 reliability. We say, “Lower layer reliability maintains the investment made in the transport of a frame”.
There are a number of configurable timer parameters associated with protocol implementation. Ideally, it would be best to make the lower layers wait long enough that any new data being sent by the higher layer can be sent along with the acknowledgment for previous data received. The layers of protocol work in harmony, each one using the services of the underlying layer and each one providing services to the layer above. The lowest layer is the cable, the highest ‘layer’ is the human sitting at the keyboard.
Topics In This Discussion
- Introduction to LLC Layer
- Defining “Connection-less” and “Connection-Oriented”
- Type 1 Logical Link Control
- Setting Up a Type II LLC Connection
- Transmitting and Acknowledging
- Data in Type II LLC
- Protocol Analysis Techniques for Type II LLC
- The Bits in the LLC Header
- Type 2 LLC Commands and Responses
- Type II LLC Commands and Responses
- Viewing LLC with your Protocol Analyzer
- The Rationale for Using a Reliable Data Link