Skip to main content
close banner

Type II LLC Commands and Responses

All the frames defined as Type 1 are technically considered to be Type 2 frames as well. However, you should absolutely know which frames are specific to Type 1 and which frames are specific to Type 2. If you were asked whether a UI frame was Type 1 or Type 2 the reasonable response would be to say, “Type 1” even though you know that technically it would be valid to say, “Type 2” since all Type 1 is included in Type 2.

THE I-FRAME

I Information frame

‘I’ frames transfer sequentially numbered blocks of data between communicators. The I frame contains a send sequence number (NS= or N(S)=) indicating the number of the currently transmitted block. Additionally, each I frame includes the number of the next expected frame from the other communicator.

SUPERVISORY TYPE 2 COMMANDS

Supervisory Commands do not contain an Information field and, therefore, do not increment the sequence number being sent.

RR Receiver Ready

The RR frame is used when a station is acknowledging previously sent data but has no new data to send. In the case where the station DOES have more information to send it simply sends it (NS=). If there is no ‘NS=‘ then the ‘NR=‘ is accompanied by the RR (or RNR) indication.

RNR Receiver Not Ready

If a station sends ‘RNR’ it means that a temporary busy condition exists and the station is currently unable to accept I frames. A brief time after sending an RNR indication it is expected (hoped) that the station will become ready to accept frames and will send the RR indication.

REJ Reject

A REJ command is used to request the resending of one or more frames starting with the frame indicated in the REJ command. For example, if a station sends: NS=0, NS=1, NS=2 but frame #2 is corrupted in transit then the receiver gets: NS=0, NS=2. The receiver will now transmit a REJ command with NR=2 indicating that resending should start with NS=2 and proceed from there (with a resend, in this case, of NS=3). The REJ frame is a polite request to retransmit something that was lost in transit.

Unnumbered Type 2 Commands

SABME Set Asynchronous Balanced Mode Extended

This command is used to establish the link between two LLC stations. This command will always be seen at the beginning of a Type 2 connection. If a SABME is received from a station to which acknowledgments are due (from a previous connection) then the pending acknowledgments are canceled assuming that the other communicator encountered some situation requiring the re-establishment of an entirely new connection.

DISC Disconnect

When a station wants to terminate a connection it sends a DISC command. The command informs the destination that the source is suspending operation of the data link connection. The destination should then enter the Disconnect Mode. If acknowledgments are pending when a DISC is received then the acknowledgments are canceled assuming that the other communicator has suspended operation for reasons of its own.

Responses

Responses could include any of these previously defined frames:

I, RR, RNR, REJ

Responses could also include these:

UA Unnumbered Acknowledgment

DM Disconnect Mode

The DM response is used to report the status of a station that has entered the disconnected mode. It is usually seen following the receipt of a DISC command. I tell you I am DISConnected and you report that you have entered the Disconnect Mode.

FRMR Frame Reject

The FRMR is one of the most misunderstood commands. The 802.2 spec says that the frame is sent when a condition occurs that is not correctable by resending previously sent frames. In effect, a FRMR indicates a catastrophic failure. If you see FRMR frames, suspect possible bugs in device driver software or possible hardware failure. Lost frames on a network will not cause FRMR’s, only REJ’s.

The events that may cause the transmission of an LLC FRMR frame are:

  • An invalid or unimplemnted command or response frame is received. These could be:
    • A supervisory or unnumbered frame with an ‘I’ field that is not permitted
    • Receipt of an unsolicited Final bit (set to ‘1’)
    • Receipt of an unexpected UA response (when no command was sent)
  • The length of the information field causes the previously established (in an XID) maximum length to be exceeded for that connection.
  • A station sends an acknowledgment (NR=) for a frame that has not been previously sent.

The response to receipt of an FRMR is dependent on the implementation. An LLC implementation may be designed to implement some corrective action or it may simply ‘hang’.

If you see FRMR frames you need to find out who is sending them, and why.