Data Link Protocols ผศ.ดร. อนันต์ ผลเพิ่ม Asst.Prof. Anan Phonphoem, Ph.D. anan@cpe.ku.ac.th http://www.cpe.ku.ac.th/~anan Computer Engineering Department Kasetsart University, Bangkok, Thailand Protocol: set of rules or specifications used to implement one or more layers of the OSI model Data Link Protocol: a set of specifications used to implement data link layer rules –> line discipline, flow control, and error handling

Data Link Protocols Asynchronous Protocols Synchronous Protocols Xmodem Ymodem Zmodem BLAST Kermit Asynchronous: treat each character in a bit stream independently Synchronous: take whole bit stream and chop it into characters of equal size Character-oriented Bit-oriented

Asynchronous Protocols Long, long…time ago Not complex and easy to implement Slow Required start/stop bit and space Now mainly used in modem  Replaced by high speed synchronous

XMODEM frame Half-duplex, stop-and-wait ARQ protocol 1979: designed for FTP via telephone-line between PCs SOH: Start of Header TX  start by sending NAK (from receiver) Sender must wait for ACK before sending next frame Half-duplex, stop-and-wait ARQ protocol

Data Link Protocols Asynchronous Protocols Synchronous Protocols Xmodem Ymodem Zmodem BLAST Kermit Ymodem  data unit changes to 1024 bytes (Xmodem=128) use CRC16 multiple files accepted Zmodem  combination of X and Ymodem BLAST (Blocked Asynchronous Transmission)  better than Xmodem (full-duplex, sliding window flow conrol) Kermit (Columbia U)  most widely used asyn. Protocol (operation same as Xmodem) Character-oriented (Byte-oriented) Bit-oriented BSC

Synchronous Protocols Character-oriented protocol Based on one byte (8-bit) Use ASCII for control character Not efficient  seldom used Bit-oriented protocol Based on individual bits One or multiple bits for control More efficient Speed  better than asynchronous

IBM’s Binary Synchronous Communication (BSC) Character-oriented protocol Half-duplex, stop-and-wait ARQ 2 frame types Data frame (data transmission) Control frame (connect/disconnect and flow/error control)

A simple BSC data frame SYN = Synchronous idle = 0010110 SYN : Alert the receiver for the incoming frame BCC : can be LRC (longitudinal redundancy check) or CRC (cyclic redundancy check) This simple frame is seldom used SYN = Synchronous idle = 0010110 STX = Start of text = 0000010 ETX = End of text = 0000011

A BSC frame with a header Header Fields: address (sender/receiver) #frame identifier (0/1 for stop-and-wait ARQ) SOH: start of Header

A multiblock frame ITB = Intermediate text block Probability of error: Frame size increases, error increases  multiple faults occurs  Difficult to detect errors (error cancel each others)  Message is divided in several blocks  Each block has STX, ITB and BCC  Ending with ETX (end of text)  Error detected, whole frame is discarded (needs retransmission)  ACK for entire frame  one frame is entire message ITB = Intermediate text block

Multiframe transmission “Large Message” is broken down to multiple frame  need ETB (End of transmission Block)  need ETX (End of text)  Half-duplex so ACK 0 and ACK 1 alternately ETB = End of transmission Block

Control frame Note: Control Frame is used to send command Control frame  not control character Note: Control Frame is used to send command * Establish connection * Maintaining flow & error control * terminating connection

Control frames

Control frames

Control frames

Data Transparency BSC is designed for text message Now, non-text message (graphics,…) Problem? BSC control character problem Data transparency: should be able to send any data

Byte stuffing DLE = data link escape Byte Stuffing 2 activities: - Defining the transparent text region with DLE - Preceding any DLE character within the transparent region (extra DLE) Problem still exist if text = DLE ?  Insert an addition DLE next to the character (DLE DLE) DLE = data link escape

Data Link Protocols Asynchronous Protocols Synchronous Protocols Xmodem Ymodem Zmodem BLAST Kermit Character-oriented (Byte-oriented) Bit-oriented BSC

Bit-oriented protocol Represent more information into shorter frame Avoid the transparency problems

Bit-oriented Protocols SDLC HDLC LAPs LANs SDLC: Synchronous data link control – IBM HDLC: High-level data link control – ISO LAPs : Link access procedure Most of the bit-oriented protocols are proprietary Most famous  HDLC

HDLC Support half/full – duplex over point-to-point and multipoint links HDLC system characterization Station types Configurations Communication modes Frames

HDLC station types Primary station Secondary station Combined station The station that controls the medium by sending “command” Secondary station The station that “response” to the primary station Combined station The station that can both command and response

HDLC configurations The relationship of hardware devices on a link 3 configurations of all stations (primary/secondary/combined) Unbalanced Symmetrical Balanced

HDLC Configurations: Unbalanced (master/slave) Can be point-to-point (for 2 devices) or multipoint

HDLC Configurations: Symmetrical

HDLC Configurations: Balanced Only point-to-point

HDLC communication modes Mode : describe “Who controls the link” NRM: Normal response mode (master/slave) ARM: Asynchronous response mode (secondary can initiate if idle, all transmissions are made to primary station) ABM: Asynchronous balanced mode (point-to-point equal) ARM: need to communicate through the Primary (even for secondary to secondary relay @ primary)

HDLC frame 3 frame types Information frame (I-frame) Supervisory frame (S-frame) For ACK, Flow/Error controls Unnumbered frame (U-frame) For Mode setting, Initialize, Disconnect

HDLC Frame

HDLC Frame

HDLC Frame: Flag field Flag:  beginning and ending of a frame  Last flag can be the start of the next flag Flag  similar to “Control Character”  problem for transparency !!!  Bit Stuffing

Bit Stuffing How to differentiate data and flag? Adding one extra 0 whenever there are five consecutive 1s in the data

HDLC: Bit stuffing TX more than 5 consecutives “1”  insert (stuffs) one redundant bit “0” after the fifth “1” Example: 0111 1111 1000  0111 1101 1100 0 No Matter that the sixth bit is one or not ! 3-Exceptional: 1. it’s really a Flag (6 consecutive “1”) 2. Tx is being aborted (7-14 consecutive “1”) 3. Channel is in Idle state (>= 15 consecutive “1)

HDLC frame: Address field Primary station creates a frame  destination address Secondary station creates a frame  source address Can be one byte or more

HDLC Frame: Address field One byte = 128 stations (one bit is used for another purpose) Large network needs multiple byte address

HDLC Frame: Control field N(R)  can be think as “ACK” if correct  N(R) = next frame seq else  N(R) = number of damaged frame (need reTx) In S-Frame  not transmit data, so do not need N(S)  S-Frame for response (return N(R) ) Code  flow and error control information

HDLC frame: Poll / Final P/F: dual purposes 1) P/F = 0 no meaning (regular data) 2) P/F = 1 means “poll” when send by primary P/F = 1 means “final” when send by secondary

HDLC Frame: Information field

HDLC Frame: FCS field FCS: Frame check sequence

HDLC: S-Frame

HDLC: Use of P/F field

HDLC: Use of P/F field Piggybacking: data + ack

HDLC: Use of P/F field

HDLC: Use of P/F field

HDLC: S-Frame Acknowledgement

HDLC: S-Frame Positive Acknowledgement RR Receiver sends “Positive Ack” (no data to send) N(R) = seq of next frame RNR Receiver sends “Positive Ack” Receiver tells sender that sender cannot send any frame until ‘RR’ frame is received

HDLC: S-Frame Negative Acknowledgement Reject (REJ) Go-back-n ARQ N(R) = # of damage frame (and follow) Selective-Reject (SREJ) N(R) = # of damage frame

HDLC: U-Frame control field For session management and control information

HDLC: U-Frame control field SNRM : set normal response mode DISC: Disconnect

HDLC: Polling example

HDLC: Selecting example

HDLC: Peer-to-peer example SABM: Set asynchronous balanced mode UA: Unnumbered ack

HDLC: Peer-to-peer example