Talk:Logical link control

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
???	This article has not yet received a rating on the project's importance scale.
	This article is supported by WikiProject Software.

If the LLC sub layer is responsible for sequencing, then why is it that Ethernet frames created by MAC sublayer also has sequence fields and error checksum fields? How exactly are the MAC frames and HDLC frames related? What exactly does multiplexing protocols mean? —The preceding unsigned comment was added by 220.226.77.222 (talk • contribs) 13:05, 18 May 2007 (UTC).[reply]

Ethernet frames don't have sequence fields unless some protocol running above the MAC layer puts them there, e.g. the N(R) and N(S) fields in 802.2 LLC I-frames, or the offset field in IPv4 packets, or the sequence number fields in TCP segments. What Ethernet frames have at the MAC layer is a 6-octet destination address, a 6-octet source address, and a 2-byte type/length field, followed by the payload, followed by a 4-byte checksum.

The checksum is to detect errors; it's up to a protocol running above the MAC layer to do something about the error. An Ethernet adapter will (normally) drop frames if the checksum is bad; there's no acknowledgment of Ethernet frames at the MAC layer, so there won't be any transmission at the MAC layer - a protocol running above that layer will have to detect the loss of the frame and retransmit it.

"Multiplexing protocols" means allowing, for example, ARP packets, IPv4 packets, IPv6 packets, IPX packets, DECNET packets, etc. to be transmitted from host A to host B, and allowing host B to know which type of frame it's received. That can be done by using the 2-byte type/length field as a type field; the type field indicates the type of packet. If the type/length field is used as a length field, it is instead done with the 802.2 LLC header; either the SAP fields indicate the type of packet or, if they indicate that it's a SNAP packet, the OUI and protocol ID fields in the SNAP header indicate the type of packet. Guy Harris 22:07, 18 May 2007 (UTC)[reply]

Thanks for the clarification, Guy! It's indeed helpful. Actually, the article could be improved with help of these details. --Kraymer (talk) 12:38, 8 February 2011 (UTC)[reply]

Requested move[edit]

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was: moved. ErikHaugen (talk | contribs) 18:15, 4 November 2011 (UTC)[reply]

– These LLC and MAC sublayers of the data link layer are also not proper names; many sources have them in lower case, and per MOS:CAPS, so should we. Dicklyon (talk) 03:16, 27 October 2011 (UTC)[reply]

Sorry to stalk you, Dick, but you stalk me! :-). Yes, I support this move, because it's directly analogous to "layer", which we've already decided should not have the eye-poking caps. I can't image why these compound items need to be dressed up to be recognised: their letter strings are unique. The opening sentence of the first article in question says it all: "The Logical Link Control (LLC) data communication protocol layer is the upper sub-layer of ...".

Tony (talk)

06:14, 27 October 2011 (UTC)[reply]

Support —Ruud 20:28, 27 October 2011 (UTC)[reply]
Support -- SchreyP ^(messages) 12:05, 31 October 2011 (UTC)[reply]

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.