1. Chapter 3 Data Link Layer Dr. N Amanquah
Computer Networks
Chapter 3
Data Link Layer
Dr. N Amanquah
Acknowledgements: Prof J Breecher, Clark Uni

2. DLL
Objective: provide reliable, efficient communication between adjacent machines connected by a single communication channel.
return a positive or negative acknowledgment
“Frames” (packets/messages at Layer 2)
Errors occur
Detect errors
Finite propagation delay
Provide (reliable?) service to layer above
Manage flow control (tx –rx speeds)

3. Virtual vs actual path of comms

4. DLL Design Delivery Mechanisms: SERVICES PROVIDED TO THE NETWORK LAYER
Connection-Less
Connection
Oriented
Acknowledged
UN-Acknowledged
“Best Effort”
Better Quality
Reliable Delivery
Chap. 3- DLL

5. Unacknowledged Connection-less Service -- Best Effort:
Destination host does not ack frames, no attempt to recover lost or damaged packets by DLL
Use if low error rates eg LAN, Fiber
Recovery by higher layers
Real time applications – “better never than late” –(MILK)
NB: ACKs are not a requirement for DLL, but just an optimization – cf sending frames of a large pkt over unreliable wireless

6. Acknowledged Connection-less Service -- Acknowledged Delivery:
No logical connections, but ACK each frame
Make use of Sequence Nos
Sender retransmits unACKed frames.
Useful for unreliable channels eg wireless.
NB: DLL has limits on frame size, whereas NW layer may not.
If high probability of packet loss, better to handle ACK in DLL rather than in NW- a entire NW packet must be sent if any part is lost.

7. Acknowledged Connection-Oriented Service -- Reliable Delivery:
Frames are delivered reliably and in order
Connection state kept
-sending order
which frames require retransmission. etc

8. Framing DLL Design How to detect frame boundaries Character Count:
Header=frame size. Synchronization difficulties
Character stuffing:
Use flags for start and end. Double ocurrence=new frame. Eg
Challenge: if flag exists in data? ESC it (character stuffing)
Eg: “A ESC ESC FLAG B C”
Disadvantage: A octet is the smallest unit that can be operated on
Bit Stuffing:
Encoding Violations:
The DLL translates the physical layer's raw bit stream into discrete units (messages) called frames. How can frame be transmitted so the receiver can detect frame boundaries? That is, how can the receiver recognize the start and end of a frame? We will discuss four ways:
Chap. 4- MAC

9. Bit Stuffing Same as char-stuffing, but on bits instead of bytes.
FRAMING
Bit Stuffing
Same as char-stuffing, but on bits instead of bytes.
Eg use as start of frame. (0—6(1)—0)
What if 6ones occur in data?  stuff a zero after occurrence of 5ones, irrespective of what follows the 5ones (see p190)
Example: data;
Bit Stuffing:
Same idea as char-stuffing, but operates on bits instead of bytes.
IDEA: Use reserved bit patterns to indicate the start and end of a frame. For instance, use the 4-bit sequence of 0111 to delimit consecutive frames. A frame consists of everything between two delimiters.
Problem: What happens if the reserved delimiter happens to appear in the frame itself? If we don't remove it from the data, the receiver will think that the incoming frame is actually two smaller frames!
Solution: Use bit stuffing. Within the frame, replace every occurrence of two consecutive 1's with E.g., append a zero bit after each pair of 1's in the data. This prevents 3 consecutive 1's from ever appearing in the frame.
Chap. 3- DLL

10. FRAMING
Encoding violations
Send a signal that doesn't conform to any legal bit representation.
Machester encoding 1== high low sequence
End of frame could be low-low or high-high or vice versa
Used by token bus (IEEE802.4)
Ethernet (IEE802.3) makes use of special start & end frame patterns.
Encoding Violations:
Send a signal that doesn't conform to any legal bit representation. In Manchester encoding, for instance, 1-bits are represented by a high-low sequence, and 0-bits by low-high sequences. The start/end of a frame could be represented by the signal low-low or high-high.
The advantage of encoding violations is that no extra bandwidth is required as in bit or character stuffing. The IEEE standard uses this approach. (token Bus).
Finally, some systems use a combination of these techniques. IEEE 802.3,(ethernet) for instance, has both a length field and special frame start and frame end patterns.
Chap. 3- DLL

11. Error control

12. DLL Design ERROR CONTROL
Must ensure that all frames are eventually delivered (possibly in order) to a destination. Three components are required to do this:
Acknowledgments, Timers, and Sequence Numbers
Acknowledgments:
Reliable delivery is achieved using the "acknowledgments with retransmission" paradigm.
The receiver returns a special acknowledgment (ACK) frame to the sender indicating the correct receipt of a frame.
In some systems, the receiver also returns a negative acknowledgment (NACK) for incorrectly-received frames.
This is only a hint to the sender so that it can retransmit a frame right away without waiting for a timer to expire.
Must ensure that all frames are eventually delivered (possibly in order) to a destination. Three components are required to do this:
Acknowledgments, Timers, and Sequence Numbers
Acknowledgments:
Reliable delivery is achieved using the "acknowledgments with retransmission" paradigm.
The receiver returns a special acknowledgment (ACK) frame to the sender indicating the correct receipt of a frame.
In some systems, the receiver also returns a negative acknowledgment (NACK) for incorrectly-received frames.
This is only a hint to the sender so that it can retransmit a frame right away without waiting for a timer to expire.
Chap. 3- DLL

13. DLL Design ERROR CONTROL Timers:
One problem that simple ACK/NACK schemes fail to address is recovering from a frame that is lost, and as a result, fails to solicit an ACK or NACK.
What happens if an ACK or NACK becomes lost?
Retransmission timers are used to resend frames that don't produce an ACK. When sending a frame, schedule a timer to expire at some time after the ACK should have been returned. If the timer goes off, retransmit the frame.
Sequence Numbers:
Retransmissions introduce the possibility of duplicate frames.
To suppress duplicates, add sequence numbers to each frame, so that a receiver can distinguish between new frames and repeats of old frames.
Bits used for sequence numbers depend on the number of frames that can be outstanding at any one time.
Chap. 3- DLL

14. Chap. 4- MAC

15. Error Detection & Control
Overview
3.1 DLL Design Issues
3.2 Error Detection and Correction
3.3 DLL Protocols
3.4 Sliding Window Protocols
3.5 Protocol Specification and Verification
This section is about putting in enough redundancy along with the data to be able to detect (and correct) data errors.
Chap. 4- MAC

16. Error detection and correction
Add redundancy to detect and correct errors
Sources of errors:
Noise, Attenuation, Natural phenomena
NB: noise occurs in bursts rather than independent single bit errors (eg lightening for a few secs)
Error detecting codes – enough redundancy to detect. Use ACK etc to fix error
Error correcting codes: enough redundancy to correct

17. Code words Messages (frames) consist of
m data (message) bits +
r redundancy bits,
= n bit code word = ( m + r ) bit codeword
Code words: valid code words are transmitted

18. Hamming Distance
Given any two codewords, number of bits differ that differ. Do exclusive (XOR) of the two words, and count the number of 1 bits in the result. This count is the Hamming Distance.
If two codewords are d bits apart, d errors are required to convert one to the other.
A code's Hamming Distance = minimum Distance between any two of its legal codewords (from all possible codewords).
.  
To detect d 1-bit errors : having a Hamming Distance of at least d + 1 bits.
To correct d errors requires 2d + 1 bits.
After d errors, the garbled messages is still closer to the original message than any other legal codeword.
 All 2m possible data words are legal. Choosing check bits (r)carefully, so that the codewords will have a large Hamming Distance. The larger the Hamming distance, the better the codes are able to detect errors

19. Parity
Add single parity bit to each data block so that the number of 1 bits always adds up to an even (odd) number.
 The Hamming Distance for parity is 2, and it cannot correct even single-bit errors (but can detect single-bit errors).
Eg a 10-bit code used to represent 4 possible values:
" ", " ", " ", and " ".
Hamming distance =5, can correct 2 single-bit errors:
Discuss other scenarios if more than 2 bits in error
If " " becomes " " by changing only two bits.
 NB: If the sender transmits " " and the receiver sees " ", the receiver will not correct the error properly.  

20. Error Detection & Control
 Error correction is relatively expensive (computationally and in bandwidth.)
 Detecting a single bit error requires only a single-bit, no matter message size
Popular error detection codes are based on polynomial codes or cyclic redundancy codes(CRCs).
 With Error detection, can determine correctly received frames and can discard incorrect ones.
For example, 10 redundancy bits are required to correct 1 single-bit error in a 1000-bit message.
(see code design formula)
Chap. 3- DLL

21. Error Detection & Control
Block coding
Errors occur in bursts.
Arrange sequence of consecutive codewords into rows of a matrix. Transmit them a column at a time. Even if one frame is lost, after re-construction, one bit errors can be detected and corrected.
Chap. 3- DLL

22. DLL Design
FLOW CONTROL   
Flow control deals with throttling the speed of the sender to match that of the receiver. Usually, this is a dynamic process, as the receiving speed depends on such changing factors as the load, and availability of buffer space.
One solution is to have the receiver extend credits to the sender. For each credit, the sender may send one frame. Thus, the receiver controls the transmission rate by handing out credits.
LINK INITIALIZATION:
In some cases, the data link layer service must be "opened" before use:
The data link layer uses open operations for allocating buffer space, control blocks, agreeing on the maximum message size, etc.
Synchronize and initialize send and receive sequence numbers with its peer at the other end of the communications channel.
Chap. 3- DLL 37

23. DLL PROTOCOLS Overview
How can two DLL layers communicate in order to assure reliability?
Chap. 4- MAC

24. DLL Protocols Overview ELEMENTARY DATA LINK PROTOCOLS:
ELEMENTARY DATA LINK PROTOCOLS:
The DLL provides services to the Network Layer above it:
Data : Network Layer  DLL  PHY  PHY2  DLL2  Network Layer
DLL may add header + control info for itself
Data should be
-passed reliably.
-in the exact same order as they are sent. (usually, eg not in real time apps)
Frames are the unit of transmission.
Sequence of steps to accomplish…
Chap. 3- DLL

25. DLL Protocols BUILDING BLOCKS & Definitions
#define MAX PKT /* determines packet size in bytes */
typedef enum {false, true} boolean; /* boolean type */
typedef unsigned int seq_nr; /* sequence or ack numbers */
typedef struct {
unsigned char data[MAX PKT];
} packet; /* packet definition */
typedef enum {data, ack, nak} frame_kind; /* frame kind definition */
typedef struct { /* frames are transported in this layer */
frame_kind kind; /* what kind of a frame is it? */
seq_nr seq; /* sequence number */
seq_nr ack; /* acknowledgement number */
packet info; /* the network layer packet */
} frame;
Chap. 3- DLL

26. DLL Protocols BUILDING BLOCKS
/* 1. Wait for an event to happen; return its type in event. */
void wait_for_event(event_type *event );
/* 2. Fetch a packet from the network layer for transmission on the channel. */
void from_network_layer( packet *p);
/* 3. Deliver information from an inbound frame to the network layer. */
void to_network_layer( packet *p);
/* 4. Go get an inbound frame from the physical layer and copy it to r. */
void from_physical_layer( packet *p);
/* 5. Pass the frame to the physical layer for transmission. */
void to_physical_layer( packet *p);
/* 6. Start the clock running and enable the timeout event. */
void start_timer(seq_nr k);
/* 7. Stop the clock and disable the timeout event. */
void stop_timer(seq_nr k);
/* 8. Start an auxiliary timer and enable the ack_timeout event. */
void start_ack_timer(void);
/* 9. Stop the auxiliary timerand disable the ack_timeout event. */
void stop_ack_timer(void);
/* 10. Allow the network layer to cause a network_layer_event. */
void enable_network_layer( void );
/* 11. Forbid the network layer from causing a network_layer_event. */
void disable_network_layer( void );
Chap. 3- DLL

27. DLL Protocols Assumptions:
AN UNRESTRICTED SIMPLEX PROTOCOL
Assumptions:
Data transmission in one direction only (simplex).
No errors take place on the physical channel.
The sender/receiver can generate/consume an infinite amount of data.
Always ready for sending/receiving.
See the code on the next page == Figure 3.10.
Chap. 3- DLL

28. DLL Protocols AN UNRESTRICTED SIMPLEX PROTOCOL
typedef enum {frame_arrival} event_type;
#include "protocol.h"
void sender1(void) {
frame s; /* buffer for an outbound frame */
packet buffer; /* buffer for an outbound packet */
while (true) {
from_network_layer(&buffer); /* go get something to send */
s.info = buffer; /* copy it into s for transmission */
to_physical_layer(&s); /* send it on its way */ }
void receiver1(void)
frame r;
event_type event; /* filled in by wait, but not used here */
wait_for_event(&event); /* only possibility is frame arrival */
From_physical_layer(&r); /* go get the inbound frame */
To_network_layer(&r.info); /* pass the data to the network layer */
Chap. 3- DLL

29. DLL Protocols Assumptions:
SIMPLEX STOP-AND-WAIT PROTOCOL
Assumptions:
No longer assume receiver can process incoming data infinitely fast.
Sender ships one frame and then waits for acknowledgment (stop and wait.)
The contents of the acknowledgment frame are unimportant.
Data transmission is one directional, but must have bi-directional line. Could have a half-duplex (one direction at a time) physical channel.
See the code on the next page == Figure 3.11. 
Chap. 3- DLL

30. DLL Protocols SIMPLEX STOP-AND-WAIT PROTOCOL
/* Protocol 2 (stop-and-wait)
typedef enum {frame_arrival} event_type;
#include "protocol.h"
void sender2(void) {
frame s; /* buffer for an outbound frame */
packet buffer; /* buffer for an outbound packet */
event_type event; /* frame_arrival is the only possibility */
while (true) {
from_network_layer(&buffer); /* go get something to send */
s.info = buffer; /* copy it into s for transmission */
to_physical_layer(&s); /* send it on its way */
wait_for_event(event(&event); /* do not proceed until given go ahead*/ }
void receiver2(void)
frame r, s;
event_type event; /* filled in by wait, but not used here */
wait_for_event(&event); /* only possibility is frame arrival */
From_physical_layer(&r); /* go get the inbound frame */
To_network_layer(&r.info); /* pass the data to the network layer */
to_physical_layers); /* send a dummy frame to awaken sender */
Chap. 3- DLL

31. DLL Protocols SIMPLEX PROTOCOL FOR A NOISY CHANNEL
Assumptions:
The channel is noisy and we can lose frames (they never arrive).
Simple approach, add a time-out to the sender so if no ACK after a certain period, it retransmits the frame.
Scenario of a bug that could happen if we’re not careful:
A transmits frame one
B receives A1
B generates ACK
ACK is lost
A times out, retransmits
B gets duplicate copy of A1 (and sends it on to network layer.)
Use a sequence number. How many bits? 1-bit is sufficient for this simple case because only concerned about two successive frames.
Positive Acknowledgment with Retransmission (PAR): Sender waits for positive acknowledgment before advancing to the next data item. (Numerous alternatives to this we will see later.)
 (ARQ)
Chap. 3- DLL

32. DLL Protocols SIMPLEX PROTOCOL FOR A NOISY CHANNEL This is Figure 3.12
/* Protocol 3 (par) allows unidirectional data flow over an unreliable channel. */
#define MAX_SEQ 1 /* must be 1 for protocol 3 */
typedef enum {frame_arrival, cksum_err, timeout } event_type;
#include "protocol.h“
void sender3(void) {
seq_nr next_frame_to_send; /* Seq number of next outgoing frame */
frame s; /* buffer for an outbound frame */
packet buffer; /* buffer for an outbound packet */
event_type event; /* frame_arrival is the only possibility */
next_frame_to_send = 0;
from_network_layer(&buffer); /* go get something to send */
while (true) {
s.info = buffer; /* copy it into s for transmission */
s.seq = next_frame_to_send; /* insert sequence number in frame */
to_physical_layer(&s); /* send it on its way */
start_timer( s.seq); /* if answer takes too long, time out */
wait_for_event(event(&event); /* frame arrival or cksum err, or timeout */
if ( event == frame_arrival) {
from_physical_layers(&s); /* Get the ACK */
if ( s.ack == next_frame_to_send ) {
from_network_layer( &buffer ); /* get the next one to send */
inc( next_frame_to_send ); /* invert next_frame_to_send */ }
This is Figure 3.12
Chap. 3- DLL

33. DLL Protocols SIMPLEX PROTOCOL FOR A NOISY CHANNEL
void receiver3(void) {
seq_nr frame_expected;
frame r, s;
event_type event;
frame_expected=0;
while (true) {
wait_for_event(&event); /* only possibility is frame arrival */
if ( frame == event_arrival ) { /* A valid frame has arrived */
from_physical_layer(&r); /* go get the inbound frame */
if ( r.seq == frame_expected ) { /* This is what we’ve been waiting for */
to_network_layer(&r.info); /* pass the data to the network layer */
inc(frame_expected); /* next time expect the other seq # */ }
s.ack = 1 – frame_expected;
to_physical_layer(&s); /* send a dummy frame to awaken sender */
Chap. 3- DLL

34. DLL Protocols SIMPLEX PROTOCOL FOR A NOISY CHANNEL   
A Problem unresolved by this protocol is this:
How long should the timer be?
What if too long? (inefficient)
What if too short? Sender will transmit an unneccary number of duplicate frames
So far considered one way comms with ACKs only in reverse.
Next: make better use of channel.
Chap. 3- DLL

35. Sliding Window Protocols
Overview
These methods provide much more realism!
General method provides buffering with ACKs.
Chap. 4- MAC

36. Sliding Window Protocols
FEATURES   
Assumptions:
Use more realistic Two-way communication.
We now have two kinds of frames (containing a "kind" field):
Data
ACK containing (sequence number of last correctly received frame).
Piggybacking - add acknowledgment to data frames going in reverse direction. –rather than separate ACKs
Piggybacking issue: For better use of bandwidth, how long should we wait for outgoing data frame before sending the ACK on its own.
Chap. 3- DLL

37. Sliding Window Protocols
EXAMPLE
Example of a sliding window protocol. Contains a sequence number whose maximum value, MaxSeq, is 2n (n is number of bits used to represent the sequence numbers)
For stop-and-wait sliding window protocol, n = 1.
Essentially same as Simplex Protocol, except
ACKs are numbered, which solves early time out problem.
Two-way communication.
Protocol works, all frames delivered in correct order.
Requires little buffer space.
Poor line utilization due to stop-and-wait. (To be solved in next example.)
<<< Figure 3.14 >>>
Chap. 3- DLL

38. Sliding Window Protocols
EXAMPLE
/* Protocol 4 (sliding window) is bi-directional and is more robust than protocol 3 */
#define MAX-SEQ /* must be 1 for protocol 4 */
typedef enum {frame-arrival, cksum-err, timeout} event-type;
#include "protocol.h"
void protocol4 (void) {
seq-nr next-frame-to-send; /* 0 or 1 only */
seq-nr frame-expected; /* 0 or 1 only */
frame r, s; /* scratch variables */
packet buffer; /* current packet being sent */
event-type event;
next-frame-to-send = 0; /* next frame on the outbound stream */
frame-expected = 0; /* number of frame arriving frame expect */
from-network-layer(&buffer); /* fetch a packet from the network layer */
s.info = buffer; /* prepare to send the initial frame */
s.seq = next-frame-to-send; /* insert sequence number into frame */
s.ack = 1 -frame-expected; /* piggybacked ack */
to-physical-layer(&s); /* transmit the frame */
start-timer(s.seq); /* start the timer running */
The receiver runs:
next-frame-to-send=1;
frame-expected = 0;
//it does not fetch data from nw //layer yet
Chap. 3- DLL

39. Sliding Window Protocols
EXAMPLE
while (true) {
wait-for-event(&event); /* frame-arrival, cksum-err, or timeout */
if (event == frame-arrival) { /* a frame has arrived undamaged. */
from-physical-layer(&r); /* go get it */
if (r.seq == frame-expected) {
* Handle inbound frame stream. */
to-network-layer(&r.info); /* pass packet to network layer */
inc(frame-expected); /* invert sequence number expected next */ }
if (r.ack == next-frame-to-send) { /* handle outbound frame stream. */
from-network-layer(&buffer); /* fetch new pkt from network layer */
inc(next-frame-to-send); /* invert sender's sequence numbe
s.info = buffer; /* construct outbound frame */
s.seq = next-frame-to-send; /* insert sequence number into it */
s.ack = 1 -frame-expected; /* seq number of last received frame */
to-physical-layer(&s); /* transmit a frame */
start-timer(s.seq); /* start the timer running */
Chap. 3- DLL

40. Sliding Window Protocols
OTHER ISSUES
Problem with stop and wait protocols is that sender can only have one unACKed frame outstanding.
Example:
1000 bit frames
1 Mbs channel (satellite)
270 ms propagation delay
Frame takes 1msec ( 1000 bits/(1,000,000 bits/sec) = sec = 1 msec ) to send. With propagation delay the ACK is not seen at the sender again until time 541msec. Very poor channel utilization. Several solutions are possible:
We can use larger frames, but the maximum size is limited by the bit error rate of the channel. The larger the frame, the higher the probability that it will become damaged during transmission.
Use pipelining: allow multiple frames to be in transmission simultaneously.
Chap. 3- DLL

41. Sliding Window Protocols
PIPELINING
Sender does not wait for each frame to be ACK'ed. Rather it sends many frames with the assumption that they will arrive. Must still get back ACKs for each frame.
Provides more efficient use of transmit bandwidth, but error handling is more complex.
What if 20 frames transmitted, and the second has an error. Frames 3-20 will be ignored at receiver side? Sender will have to retransmit. What are the possibilities?
Two strategies for receive Window size:
Chap. 3- DLL

42. Sliding Window Protocols
SLIDING WINDOW MECHANISMS
Go back n - equivalent to receiver's window size of one.
If receiver sees bad frames or missing sequence numbers, subsequent frames are discarded.
No ACKs for discarded frames.
Selective repeat - receiver's window size larger than one.
Store all received frames after the bad one.
ACK only last one received in sequence.
Chap. 3- DLL

43. Sliding Window Protocols
SLIDING WINDOW MECHANISMS
Tradeoff between bandwidth and data link layer buffer space on the receiver side.
In either case will need buffer space on the sender side. Cannot release until an ACK is received.
Use a timer for each unACK'ed frame that has been sent.
Must be able to enable/disable network layer because may not be able to handle more send data if there are many unACK’d frames
Window Size Rules
MaxSeq is 7 (0 through 7) is valid. How big can sender window be?
Send 0-7.
Receive 0-7 (one at a time) and send ACKS
Suppose all ACKS are lost and Message 0 times out and is retransmitted
Receiver accepts frame 0 (why? - because that is next frame) and passes it to Network Layer.
So – sender window size must be smaller than MaxSeq.
Chap. 3- DLL

44. Sliding Window Protocols
PERFORMANCE
A few pages back, we defined channel utilization as simply bits-transmitted/capacity. Now we’ll do it again with a bit more precision.
What is the channel efficiency of a stop-and-wait protocol?
F = frame size = D + H = data bits + header bits
C = channel capacity (bps)
I = propagation delay plus processor service time (seconds)
A = ack size (bits)
Time between frames: Time to get frame on wire Propagation time for frame + Time to get ACK on wire Propagation time for ACK = F/C + I + A/C + I
Time spent sending data (doing useful stuff): D/C
Efficiency: D/C D D
= =
F/C + 2I + A/C F + 2IC + A D + H + 2IC + A
What here helps or hinders efficiency?
Chap. 3- DLL

45. Chap. 4- MAC

46. Protocol Specification/Design & Verification
PROTOCOL SPECIFICATION AND VERIFICATION:
Finite State Machines / State Diagrams are a useful way of verifying that a design is correct and complete.
states = when wait(event) function is called.
The possible states for this configuration are represented by (XYZ) where
X = <0|1>: Sequence number of frame being sent
Y = <0|1>: Sequence number of frame receiver expects
Z = <0|1|A|->: State of the channel; <Seq. 0|Seq. 1|ACK|empty>
(0,0,0) = sender has sent frame 0, the receiver expects 0, and frame 0 is on the channel.
Useful for determining:
Guarantee that some transitions are NOT possible.
Guarantee that no deadlock possible
(every state has a transition out of it.)
Apply to protocol 3:
(Simplex protocol for noisy channel)
Chap. 3- DLL

47. Examples HDLC HDLC - HIGH LEVEL DATA LINK CONTROL:
Adopted as part of X.25.
A connection oriented 64Kbps network using either virtual or permanent circuits.
Bit oriented (uses bit stuffing and bit delimiters)
3-bit sequence numbers
Up to 7 unACK'ed frames can be outstanding at any time (how big is the receiver's window?)
ACK's the "frame expected" rather than last frame received (any behavior difference between the two? No, as long as the sender and receiver agree on the same convention).
For control information see spec
Control frames: next=piggybacked ack
P/F: poll (for more) or final pkt
Other control fields used if no return traffic. Type= NAK, selective NACK, receiver not ready etc
Chap. 3- DLL

48. Examples DLL In The Internet Point-to-point lines:  
Point-to-point lines:
Between routers over leased lines
Dial-up to a host via a modem
PPP - Point-to-Point Protocol
a Standard (RFCs )
Can be used for dial-up and leased router-router lines.
Provides:
Framing method to delineate frames. Also handles error detection.
Link Control Protocol (LCP) for bringing lines up, negotiation of options, bringing them down. These are distinct PPP packets.
Network Control Protocol (NCP) for negotiating network layer options.
Similar to HDLC, but is character-oriented.
PPP doesn’t provide reliable data transfer using sequence numbers and acknowledgments as the default. Reliable data transfer can be requested as an option (as part of LCP).
Allows an internet provider to reuse IP addresses. You get to use an address only for the duration of your login.
Chap. 3- DLL