Title: Data Link Layer Services and Protocols
1Data Link Layer Services and Protocols
- Arzad A. Kherani
- (alam_at_cse.iitd.ac.in)
- Dept. of Computer Sc. And Engg.
- Indian Institute of Technology Delhi
2Outline
- Frame encoding
- Error detection and recovery
- Data Link Protocols
- Protocol analysis
- Performance
- Verification for correctness
3Data link services
- Operates between two neighboring devices
- Provides a capability for higher-layer entities
to send packets - A packet is a sequence of bits, with
well-identified start and end - The packet is itself encapsulated into a frame,
adding to it header and trailer
4Data link services (2)
5Data link services (3)
- There is one data link for each physical link
- In a router, for instance
6Data link services
- Connection-less service
- Un-acknowledged service
- Useful in case of low errors, and for real-time
applications - Acknowledged service
- Used in wire-less networks
- Frames that are not acked may be re-sent
- Connection-oriented service
- acknowledged
- Ensures delivery of frames
7Framing
- Link layer packet  frame
- Problem how to recognize beginning andÂ
end of frame? - Three methods
- byte counting (DDCMP)
- bit stuffing (X.25 Level 2, 802.x)
- byte stuffing (BISYNCH, IMP-IMP)
8Framing
- Solution based on counting bits/characters
9Framing
- Solution based on flags (01111110) and bit
stuffing
Original bit string
Bit string, suitably bit-stuffed
Received, interpreted bit string
10Bit Stuffing (2)
- Frame beginning and end marked by specialÂ
- bit string ( 01111110)
- If  5 1's in data to be sent, senderÂ
inserts 0 - If receiver sees 5 1's check next bit(s)
- if 0, remove it (stuffed bit)
- if 10, end of frame marker (01111110)
- if 11, error (7 1's cannot be in data)
11Framing
- Solution based on flag characters, byte stuffing
- Special characters used for control
12Byte Stuffing Problems
- Dependence on fixed character set
- Must examine every byte of data onÂ
sending - and receiving (insert / remove DLE)
- Was used widely in IBM bisynch (atÂ
9600bps)
13Error detection and recovery
- Two approaches
- error correction codes
- quick, but ineffective in several cases
- temporary dislocation
- frame size is large, and error rate is high
- burst errors
- expensive
- error detection and recovery using
re-transmission - the preferred solution today
- efficient
14Error detection
- Hamming distance between pair of codes
- let message of length m ? 2m distinct messages
- with r redundant bits, codeword is of length n
m r - hamming distance between codes x, y
- no. of bits in which x and y differ
- Hamming distance for a code
- consider n dimension space, with 2m codewords
-
- hamming distance for code (or coding scheme)
- minx, y (no. of bits in which x and y differ)
15Hamming codes
- Hamming distance for code based on parity bit is
2 - resulting capability detect 1 error, correct 0
errors - Result
- to detect d errors, the Hamming distance must be
d1 - to correct d errors, the Hamming distance must be
at least 2d 1
16Hamming codes (2)
- Consider 7 bit data, 4 redundancy bits, codeword
is 11 bits - message bits are numbered 3, 5, 6, 7, 9, 10, 11
- redundancy bits are numbered 1, 2, 4, 8
- check bit 1 checks error in bits 1, 3, 5, 7, 9,
11 - check bit 2 checks error in bits 2, 3, 6, 7, 10,
11 - check bit 4 checks error in bits 4, 5, 6, 7
- check bit 8 checks error in bits 8, 9, 10, 11
- or (it should be)
- 0 b1 b3 b5 b7 b9 b11
- 0 b2 b3 b6 b7 b10 b11
- 0 b4 b5 b6 b7
- 0 b8 b9 b10 b11
17Error detection using block codes
- Block of data is re-written as a matrix, say 4 x
8 - last row is parity bits
- bits are transmitted row-by-row, including parity
bits - code is capable of detecting a burst of errors of
length n
18Polynomial codes
- Also known as Cyclic Redundancy Codes (CRC)
- Note, all arithmetic is modulo-2
19Polynomial codes (2)
- Error detection capability depends upon G(x)
- 1 bit error ? R(x) T(x) xi
- R(x)/G(x) 0 iff E(x)/G(x) 0
- E(x)/G(x) ? 0 if G(x) has 2 or more terms
- ? single errors can always be detected
- Similarly, two errors can always be detected if
G(x) does not divide xk 1 - Again, if G(x) is divisible by x1 then an odd
number of errors can be detected - Polynomial codes with r CRC bits will detect all
bursts of length r or less - etc., etc.
20Polynomial codes (3)
- International, IEEE standards
- IEEE 802 standard
- G(x) x32 x26 x23 x22 x16 x12 x11
x10 x8 x7 x5 x4 x2 x1 1 - it is capable of detecting bursts of length up
to 32, and all odd number of errors, and even no
of error with high probability
21Error recovery
- Error detection, followed by re-transmissions,
etc. - Efficient
- Simultaneously address problem of flow control
22Elementary data link protocols
- Broad objective of data link protocol
- Error-free, loss-free, duplication-free and
in-sequence transfer of user data packets between
network entities - flow-controlled
- transfer user data packets in both directions
23Data link modules
24Data link modules
- We consider several protocols. But to begin with
we consider moving data in one direction, only
25Data link protocol
- Assumptions
- errors during transmission
- processing capacity at receiver end
- buffer capacity at receiver end
- whether the underlying physical channel is half-
or full-duplex - we will make nice assumptions to begin with, but
move towards realistic assumptions later
26Simple data link protocol Utopia
- Assume no errors, infinite processing capacity
and buffer space at receiver end, and half-duplex
channel
Note, F_i Data link frame, containing data
packet, i
27Simple data link protocol Utopia (2)
28Simple data link protocol Utopia (3)
29Definitions of data types/structures
30Definition of procedures
31Simple data link protocol Utopia (4)
32Flow control problem and its solution
- Flow control --gt limit the rate at which a sender
can send data to one which is consistent with the
receivers ability to process incoming data - Two approaches to solving it
- rate-based determine the minimum rate at which
receiver can process incoming data - feedback based send more data as when receiver
can handle more data
33Stop and wait protocol
- Assume no errors, FINITE processing capacity,
FINITE buffer space at receiver end, and
half-duplex channel
Note, F_i Data link frame, containing data
packet, i
34Stop-n-wait protocol (2)
35PAR protocol for noisy channels
- PAR protocol addresses
- flow control
- noisy channel
- based on positive acks and re-transmissions
36PAR protocol
37PAR protocol
- Data Frames are suitably numbered 0, 1, 0, 1,
- Acks are not numbered
38PAR protocol (sender)
39PAR protocol (receiver)
40PAR protocol
41PAR protocol
- If the underlying physical layer is full-duplex,
then the protocol fails
42Alternating bit protocol
- PAR protocol, with numbered acks
F_0
Pkt 1
Pkt 1
Ack_0
Pkt 2
F_1
F_1
Pkt 2
Ack_1
Pkt 3
F_0
Pkt 3
Ack_0
F_0
Ack_0
Sender, A
Receiver, B
43Alternating bit protocol
44Alternating bit protocol
45Alternating bit protocol
46Alternating bit protocol
- Use link A ? B to carry data from A to B, and
acks from B to A and use link B ? A to carry data
from B to A, and acks from A to B - Piggyback acks onto data frames, if one has data
to send - Else, just an ack
- Redundant acks are OK
- An ack takes the form I am waiting to receive
data frame no. X - Introduce a field for frame type, data frame or
ack frame
47Performance of PAR protocol
- Link utilization
- Utilization L / (LbR), where
- L size of data frame
- b data rate
- R is round-trip delay
- For a satellite channel, let L 10K bits, b
100 Kbps, R500ms - Utilization is 10K / (10K 50K) 1/6
- For a fibre-optic channel, let L 10K bits, b
100 Mbps, R 1ms - Utilization is 10K / (10K 100K) 1/11
- DelayBW product is the key
- Let sender send many data frames before it
receives an ack
48Pipelining
- Problems arise when one or more packets are lost
49Pipelining, with error recovery
- Two approaches to recover from loss of data
frame - go-back n
- selective repeat
50Pipelining, with error recovery
51Pipelining, with error recovery
52Sliding window protocols
- Each data frame is sequentially numbered 0
through 2n-1 - Sender maintains transmit window indicating
- which data frames can be sent
- which data frames have been sent
- receiver maintains a Receive window
- which data frames can it receive
- which data frames have been received
53Sliding window protocols
- Transmit window
- size 4, waiting for acks for data frames 1, 2,
3, frame 4 not sent - Receive window
- size 3, ack for frame 1 sent, data frame 3
received, waiting for frames 2 and 4
54Sliding window protocols
- Assuming sequence numbering 0 .. 7
- Go back n protocol
- Transmit window is size, say 7
- receive window is size 1
- selective repeat protocol
- transmit window is size 4
- receive window is size 4
55Go back n protocol declarations
56Go back n protocol more declrations
57Go back n protocol initializations
58Go back n protocol (loop)
59Go back n protocol event processing
60Go back n protocol event processing
61Go back n protocol event processing
62Go back n protocol
- Buffer requirements
- at senders end N-1, where seq no is 0 .. N-1
- at receivers end 1
- Go-back n works well when error are infrequent
- Because several frames need to be re-transmitted
when an error occurs
63Select Repeat Protocol
- Sequence numbering 0 through n-1
- Transmit window size is n/2
- Receive window size is n/2
- Receiver buffers each correctly recd data frame,
but does not deliver it to the layer 3 - Receiver sends a NACK frame when it suspects loss
of a data frame - But makes sure that a NACK is not repeated
64Select Repeat Protocol
65Select Repeat Protocol
66Select Repeat Protocol
67Select Repeat Protocol
68Protocol Analysis
69Protocol Performance
- Performance
- Delay
- Efficient use of available bandwidth
70Channel utilization
- It can be shown for stop-and-wait protocol
- U F1 F2 F3
- where
- F1 D/ (HD)
- F2 (1-E)(HD) (1-E)D
- F3 (HD) / (HDCT)
- Above,
- D, H are resp. length of data and header (or
Ack) - E is bit-error-rate (BER)
- C is channel capacity
- T is timer interval
-
71Channel utilization
- Channel utilization in stop-and-wait protocol
is maximum when - Doptimum ?(HCT)/E
72Channel utilization
- Channel utilization in sliding-window protocols
is complex. Consider - No error, large Tx window
- No error, small Tx window
- With possibility of errors, large Tx window
- With possibility of errors, small Tx window
73Channel utilization
- What is a large enough window size?
- W gt 1 2 C I / (DH)
- where I propagation delay interrupt
handling time
74Channel utilization
- Channel utilization in sliding-window when
there is no error, large Tx window - U D / (DH)
- Channel utilization in sliding-window when
there is no error, but small Tx window - U D/(DH) W/(1 2 C I / (DH))
75Channel utilization
- Channel utilization in sliding-window when
there may be errors, but Tx window is small - U D/(DH) (1-L)
- where L is the probability that a frame or an
ack to it is lost - Channel utilization in sliding-window when
there may be errors, but Tx window is small - U D/(DH) (1-L) W/(1 2 C I / (DH))
76Channel utilization
- CI is also the delay-BW product,
- And CI/F is the delay-BW product in terms of no
of frames
77Protocol Verification
- Verification
- Formal specification
- Verification of protocol design
- Conformance of an implementation to a given
design
78Protocol Verification
- Two parts
- protocol modeling
- verification
- Look upon the communicating entities as ONE
finite state machine - Use two different, although equivalent, ways to
model the machines - State transition diagrams
- Petrinet based model
79Protocol verification model using state
transitions
- Consider an example stop-n-wait protocol
- Consider the sender-receiver pair, together with
channels as ONE single system - Focus on significant states, not intermediate
states encountered while executing commands or
program instructions
80Protocol Verification model using state
transitions
- Stop-n-wait protocol components, and their states
- Sender sending 0 or 1
- Receiver receiving 0 or 1
- Half-duplex channel carrying frame 0 or 1, or
Ack, or - - Acks are not numbered
- Total no of states is 16, of which 6 are
unreachable - These are states that correspond to sender and
receiver waiting for next event to occur - Further,
- Consider initial state
- Any enabled transition may take place next
- Transitions take place at any time
81Protocol Verification model using state
transitions
82Protocol Verification
- Can a protocol drop a user packet?
- Protocol never delivers packets in two data
frames, numbered 0, without delivering packet
contained in a data frame numbered 1 - Or, machine does not make two transitions
numbered 1, without an intervening transition
3 - There does not a path with two edges
corresponding to transition 1 without an
intervening edge transition 3
83Protocol Verification
- Can a protocol drop a sequence of two user
packets? - Or, sender should not state 1 twice while
receiver does not change its state in between
84Protocol modeling using Petrinets
- A Petrinet, with
- places set of possible states
- tokens define the current state
- transitions, input and output arcs
- firing of transitions
- conditions, and resulting re-distribution of
tokens
85Producer/consumer model
- Model of a producer- consumer system with one
buffer, using Petrinet
86Stop-n-wait protocol model
87Stop-n-wait protocol model
- Petrinet is formally described by its
transitions - 1 BD --gt AC
- 2 A --gt A
- 3 AD --gt BE
- 4 B --gt B
- 5 C --gt
- 6 D --gt
- 7 E --gt
- 8 CF --gt DF
- 9 EG --gt DG
- 10 CG --gt DF
- 11 EF --gt DG
88Stop-n-wait protocol model
- Using the formal specs one can formally argue
about properties that are (are not) satisfied - e.g. consider all possible sequences of
transitions. Then are there two 10 transitions
without an intervening transition 11? - How would ensure that two consecutive packets are
not lost
89Example Data Link Protocols
- HDLC (bit-oriented, high-level data link control)
- Connection establishment, release, data transfer,
and even connection reset
90Example Data Link Protocols
- PPP (point-to-point protocol)
- Mainly used router-to-router and dial-up
connections - Connection establishment and release a data link,
data transfer, and even connection reset - Help establish network layer (IP) addresses
- Over LANs, the protocol is typically Ethernet
91Thanks