The DataLink Layer Goto Contents

Brian Bramer, School of Computing and Mathematical Sciences, De Montfort University, Leicester 8 March 1997

The HDLC family is typical of bit-oriented protocols which utilise the sliding window mechanism. High Level Data Link Control (HDLC) is the ISO name for its protocol standard.  It is based on lBMs Synchronous DataLink Control (SDLC) and many manufacturers have analogous products (eg Burroughs DataLink Control - BDLC). CCITT call it Link Access Protocol B CLAPB) and ANSI call it Advanced Data Communications Control Procedure (ADCCP).

The protocol is based around a common frame format:

where:
 

flag	is a unique bit pattern 01111110 used to delimit the start and end of each frame. Bit stuffing is used to ensure data transparency (see Appendix). Flags may be transmitted continuously when the link is idle.
address	indicates the destination station address
control	a field indicating the type of frame
data	is a field of arbitrary length.
checksum	is a cyclic redundancy check using polynomial CRC-16 and applied to all fields in the frame except the flags. The receiver can always locate this check field by counting back from the end flag.

There are 3 distinct types of frame which are distinguished by different formats of the control field.

I-frame: Information frame

Data is transferred in Information frames (I) with the control field format:

where:
 

S	is the frame sequence number of the frame modulo 8
R	is a piggy backed acknowledgement, modulo 8, of the next frame expected.
P/F	stands for Poll/Final and is used to support compatibility with some older mainframe multidrop networks and multiframe block data transfer.

HDLC uses a sliding window with a send window of size 7. There is also a variant (extended HDLC) which has a 2-byte control field, providing a maximum window size of 127 for use on satellite links.

If an acknowledgement for any frame is not received within the timeout interval, the sender starts retransmitting from that frame number.

S-frame: Supervisory Frame

Supervisory Frames provide a separate acknowledgement facility and have the control field format:

where
 

R

is the sequence number, modulo 8, of the next frame expected from the other side.

type

a two bit field indicating the nature of the acknowledgement: 0 Receive Ready (denoted RR(R)) is a positive acknowledge ACK of all frames up to and including frame number R-1. 1 Reject (denoted RE.J(R)) is a negative acknowledge NAK of a Go-back-N mechanism. ie start retransmitting from frame number R. 2 Receive Not Ready (denoted RNR(R)) is a positive acknowledge of all frames up to and including R-1 but the sender must pause until a Receive Ready arrives. This can be used to pause the sender because of temporary problems at the receiver. 3 Selective Reject (denoted SREJ(R)) is a negative acknowledge in a Selective Repeat mechanism. ie resend only frame R. It is not supported in several implementations.

Notice that the supervisory frames do not have a sequence number; why is one not needed?

U-frame: UnNumbered Frame

The final class of frames is used for network management; the particular usage varies in different implementations. They are called UnNumbered Frames because they have the control field format:

The type and modifier fields together identify the function of the frame. Typical functions include:
 

RIM	Request Initialisation Mode
SABM	Set Asynchronous Balanced Mode
DiSC	Disconnect the Link
RSET	Reset the Link
FRMR	FRame Reject. ie you sent me a frame which arrived with a totally impossible format.

There is also a type of frame called an UnNumbered Acknowledgement used, not surprisingly, by one side to acknowledge that it has received an UnNumbered Frame from the other side.

Discussion

The Information and Supervisory frames control the exchange during the data transfer phase of the protocol. The set-up and termination phases involve the exchange of UnNumbered Frames. For example, negotiation is required about how the link is configured, eg will 3-bit or 7-bit sequence numbers be used, etc.
HDLC was developed in the days of master-slave networks and was initially designed to support this type of configuration. It is called unbalanced operation since both ends do not have the same control of the link. The computer master is called the primary and the slave is called the secondary; the ‘addres& field in the frame is the address of the secondary. There are two unbalanced modes of operation:
 

Normal Response Mode (NRM)	where the secondary may only respond to commands from the primary
Asynchronous Response Mode (ASM)	where the primary can set the secondary link so that a secondary can transmit without waiting for the primary to select it each time.

There is also a balanced mode of operation called Asynchronous Balanced Mode (ABM). This reflects environments where both ends of the link are intelligent and both may initiate transmissions without waiting for permission from the other.

The following pages illustrate a generic HDLC type protocol (for the precise action taken under difference see details of the relevant protocol).

Generic HDLC data link protocol

Assuming message transmission from host A to host B only!

1. Using piggybacked acknowledgements - receiver will wait for a data frame to piggyback the acknowledgement, otherwise will time out and send Receive Ready frame indicating next frame expected
2. Using Go-Back-N protocol - in case of error receiver sends Reject frame indicating frame in error and discards all subsequent frames
3. Transmitter window size 7 (7 buffers), receiver window size 1 (1 buffer)

Generic HDLC data link protocol

Assuming message transmission from host A to host B only!

1. Using piggybacked acknowledgements - receiver will wait for a data frame to piggyback the acknowledgement, else will time out and send Receive Ready indicating next frame expected
2. Using Go-Back-N protocol - receiver discard frames with checksum errors; in case of sequence error receiver sends Reject frame indicating frame expected and discards all subsequent frames
3. Transmitter window size 7 (7 buffers), receiver window size 1 (1 buffer)

Generic HDLC data link protocol

Assuming message transmission from host A to host B only!

1. Using piggybacked acknowledgements - reóeiver will wait for a data frame to piggyback the acknowledgement, else will time out and send Receive Ready indicating next frame expected
2. Using Go-Back-N protocol - receiver discard frames with checksum errors; in case of sequence error receiver sends Reject frame indicating frame expected and discards all subsequent frames
3. Transmitter window size 7 (7 buffers), receiver window size 1 (1 buffer)

Generic HDLC data link protocol

Message transmission both ways!

1. Using piggybacked acknowledgements
2. Using Go-Back-N protocol
3. Transmitter window size 7 (7 buffers), receiver window size 1 (1 buffer)

Generic HDLC data link protocol

Example of selective-reject protocol

1. Assuming message transmission from host A to host B only!
2. Using selective-reject protocol - receiver discard frames with checksum errors; in case of sequence error receiver sends selective-reject frame indicating frame expected and buffers all subsequent frames
3. Using 4 bit sequence numbers, ie 0 to 15
   transmitter window size 8 (8 buffers
   receiver window size 8 (8 buffers)

Sample answer to problem

Transmitter pseudo code
 
 

SeqSend = 0 LOOP forever FromHost (Sframe.info) Sframe.kind = data Sframe.seq = SeqSend ack_ok = FALSE REPEAT SendFrame (Sframe) StartTimer REPEAT wait (event) if (event = FrameArrival) {     GetFrame (Rframe)     if (Rframe.ack = Sframe.seq + 1)     {         ack_Ok = TRUE     } } UNTIL (ack_OK OR (event = TimeOut) UNTIL ack_ok SeqSend = SeqSend + 1 Timer Stop ENDLOOP

(* initial sequence number *)   (* get message from host *)  * set up data frame with message *) (* set up sequence number *) (* set no acknowledge *) (* until frame acknowledged OK *) ( * transmit frame *) (* start the timer *) (* until ack arrives *) (* STOP and WAIT for ack frame *) (* ack frame arrived? *) (* get frame *) (* correct acknowledge ? *) (* yes *)     (* if acknowledge OK exit *)   (* yes, set next sequence number *)

 

Receiver pseudo code
 

SeqExpected = 0 LOOP forever REPEAT wait (event) GetFrame(Rframe) UNTL event = FrameArrival if (SeqExpected = Rframe.seq) {     ToHost (Rframe.info)     SeqExpected = SeqExpected + 1 } Sframe.kind = ack Sframe.ack = SeqExpected SendFrame (Sframe) ENDLOOP

(* initial sequence number *)   (* until frame OK (* wait for Frame Arrival *) (* get the frame from receiver *) (* frame OK? *) (* frame required? *) (* yes, pass message to host *) (* next sequence number *) (* build ack frame *) (* acknowledge seq number *) (* and transmit frame *)

In practice the sequence numbers for this protocol can be held in a single bit with a sequence of frame having the numbers 0 1 0 1 0 1 0 1 etc.