After reading the 802.2 std, I've got several questions:
1, what does DL-REPLY-UPDATE.request exactly do? Does it mean that if I pass an DL-reply.indication to LLC user, the user will have to use "DL-REPLY-UPDATE.request" to pass response to the peer LLC entity?
2, As for the substatus field:CCCCRRRR, there are several values of CCCC or RRRR, some of the meanings are the same, some of the meanings are not clearly addressed, is there any specific or detailed document describing how to set CCCC or RRRR field in the response?
3, the variable v(RB) is used to set CCCC field for duplicate command, and there is also one value named as "Temp err", if the "temp err" disappears, and the duplicate command comes in, should the CCCC is the same as the previous one (v(RB))? why?
First of all, the DL-REPLY-UPDATE primitive is associated only with the "Acknowledged Connectionless-Mode" service of LLC (LLC Type 3). This service was created specifically for use with MAP (Manufacturing Automation Protocol) and MAP-like systems, typically using 802.4 Token Bus technology. None of these systems or services has seen much practical use in the last 20 years. I know of no commercial system today that employs LLC Acknowleged-Connectionless service today. Thus, the question you ask is purely of academic interest.
That said, the concept behind DL-REPLY-UPDATE was that an LLC entity could "pre-load" the response (i.e., the contents of the reply) to a future acknowledgment request into the MAC entity so that the MAC could respond in real-time, without having to pass the request up the stack and have the reply come back down while the entire network was "held up" waiting for the exchange. Of course, none of this is really necessary, since LLC primitives are simply an abstract way of defining the layer interactions; there is no requirement (indeed, it is usually foolish to do so) to actually *implement* a device in the manner described by the LLC primitives.
These are both issues related to the use of LLC Type 3. The standard itself is the only place where you will find these fields and variables explained. If the explanation given there is insufficient, I don't know where else you would look. Again, it doesn't matter, since no one uses LLC-3 (to my knowledge).
-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX
My understanding is that DSRC is a MAC/PHY technology, and does not specify a particular type of LLC client. For example, IEEE P802.11p is a proposed standard under the "DSRC umbrella", yet it is LLC-neutral (as are all 802 MACs and PHYs). Similarly, the standard for WAVE (Wireless Access in Vehicular Environments, IEEE Std. 1609.3) employs DSRC as its MAC/PHY technology, yet specifies only that it "shall support the LLC as specified in IEEE 802.2." There is no mention of, or requirement for the use of LLC Type 3.
No. Type 3 service is a cobbled-together kludge attempting to achieve contradictory goals. On the one hand, it purports to be a "connectionless service", i.e., simple frame exchange without guarantees of performance. On the other hand, it purports to be an "acknowledged service", i.e., complexity is added to provide an indication that the "connectionless frames" were actually delivered.
The combination was never a good balance of complexity for functionality, and in fact it doesn't really work as intended. The general idea of an acknowledgment is that, when received by a sender of messages, that sender can assume that the message was delivered, and can free up resources (e.g., the buffer that held the message) and proceed to the next task. If not, then the acknowledgment is worthless; e.g., if the sending station must remain prepared to re-send the (acknowledged) message again, then nothing is gained from the acknowledgment.
But what is it that the "acknowledgment" in LLC-3 acknowledges? Clearly, it is not delivery of the message to the application entity in the end station, since there is no application involvement in LLC. At best, it is receipt of the message by the LLC entity; in practice, it is only receipt of the message by the MAC silicon. The message may never be delivered to the receiving application due to contention, buffer, or performance limitations within the receiving station, yet the sender has received his precious acknowledgment. LLC entities typically do not have the sort of buffer resources available to more full-featured transport entities (e.g., TCP); they may be little more than "driver shims".
In the real world, Type 1 service is almost universal. Reliable delivery guarantees are the domain of transport protocols, such as TCP.
LLC has no Type 4 service. There are only three types specified.
-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX
At the time, I thought the IEEE was trying to design into LLC all of the functionalities of previous standards, including RS-232 and X.25. In this example, wasn't X.25 acknowledged at layer 2? (And, for some frame types, 802.11 also sends ACKs at layer 2.)
Not really. There were three "camps" in what was originally known as the "Hi-LI" (HIgher-Layer Interface, later dubbed 802.1) group within 802.
The Ethernet-affiliated folks wanted a simple, connectionless service, under the principle that simple = cheap, and cheap = high-volume. This became LLC Type 1, the most widely adopted LLC variant. In practice, most systems don't even bother implementing LLC, and opt instead for the native "Type field" within Ethernet to multiplex higher-layer clients.
The IBM affiliates wanted something that would look like HDLC, as that was the technology underlying much of SNA. This became LLC Type 2, the connection-oriented service, which was widely implemented in Token Ring systems. LLC-2 is a slight tweak of HDLC; the biggest change being the inclusion of both Source and Destination fields (HDLC only uses a destination, since the source is presumed to be a central controller.)
The process control advocates wanted something that was simple and fast, like LLC-1, but that provided a low-level acknowledgment. The idea was that such systems would not incorporate a full protocol stack, and would run applications directly over the Data Link. In addition, their preferred MAC was a Token Bus technology. It should be noted that the LLC-3 acknowledgment scheme completely falls apart when LANs are transparently bridged together, since the acknowledgment can only come, at best, from the bridge. Since such bridges are capable of dropping frames due to congestion (indeed, they may *have* to, under certain load conditions), the acknowledgment becomes meaningless to the application.
In any case, the three flavors of LLC reflect these three camps never agreeing, and just going their own, merry ways. There was never any intent to provide some sort of integrated, "super functional" link layer.
X.25 is generally considered a Network Layer (i.e., Layer 3) protocol, not a Data Link. Unlike the TCP/IP suite, X.25 does provide full error and flow control at Layer 3.
802.11 incorporates acknowledgments at Layer 2, but they are primarily to compensate for the wireless network's poor communication characteristics; in a high-error-rate channel, it would be highly inefficient to wait for the Transport mechanisms to recover from frames corrupted in the wireless channel. By using a MAC acknowledgment, the control loop can be made much faster. These acknowledgments are sourced and sunk within the MAC, and are not available for higher-layer application use; indeed, they would suffer from the same deficiencies as the acknowledgments of LLC-3 if so used.
-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.