The Data Link Layer is not an isolated component—it exists to serve the layers above it. In network architecture, each layer provides a specific set of services to the layer immediately above. Understanding what services the DLL provides to the Network Layer is fundamental to grasping how internetworking actually functions.

Think of this relationship like a contract: the Network Layer (IP) asks the Data Link Layer to deliver packets to the next hop, and the DLL promises certain capabilities in return. The specifics of this contract determine what the Network Layer can reliably expect—and what responsibilities remain with higher layers.

Before diving into specific DLL services, let's establish what "layer services" means in the OSI/networking context.

Service vs. Protocol:

A critical distinction often confused:

• Protocol: The rules for communication between peer entities (e.g., the format of Ethernet frames, the CSMA/CD algorithm). Horizontal relationship—it defines how two DLL entities communicate.

• Service: What a layer provides to the layer above it. Vertical relationship—it defines what the Network Layer can request from the DLL.

The protocol is the internal mechanism; the service is the external capability provided.

Service Access Points (SAPs):

Layers communicate through Service Access Points—logical interfaces where services are requested and provided. Each SAP has an address that identifies it:

• The Network Layer accesses DLL services through the LLC SAP
• Each SAP can handle requests for a specific upper-layer protocol (e.g., one SAP for IP, another for ARP)

Service Primitives:

The interaction between layers is formally described using service primitives—standardized operations that a layer can request:

• Request: Upper layer asks lower layer to do something
• Indication: Lower layer informs upper layer of an event
• Response: Upper layer responds to an indication
• Confirm: Lower layer confirms a request was handled

For example, to send a packet, the Network Layer issues a DATA.request; when it's sent, the DLL may issue a DATA.confirm. When data arrives, the DLL issues a DATA.indication to the Network Layer.

The unacknowledged connectionless service is the simplest and most widely used DLL service. It is the default service for Ethernet and most wired LANs.

Characteristics:

• No connection establishment: Frames are sent immediately without any setup phase
• No acknowledgments: The sender has no confirmation that frames arrived
• No sequencing: Frames may theoretically arrive out of order (rare on simple LANs)
• No retransmission: Lost or corrupted frames are not retried by the DLL
• Minimal overhead: No extra control frames, maximum efficiency

Why This Service Works for LANs:

Unacknowledged connectionless service is appropriate when:

1. Transmission errors are rare: Modern Ethernet over quality cabling has extremely low bit error rates (BER < 10⁻¹²). Most frames are delivered correctly.

2. Higher layers handle reliability: TCP detects lost segments via timeout and sequence numbers, then retransmits. The DLL doesn't need to duplicate this.

3. Real-time traffic: VoIP, video streaming—would rather lose a frame than delay waiting for retransmission.

4. Broadcast/multicast: Acknowledging broadcasts from every receiver would create an ACK implosion.

Service Primitives:

The acknowledged connectionless service adds reliability to connectionless transmission. Each frame is individually acknowledged without establishing a connection.

Characteristics:

• No connection establishment: Like unacknowledged service, no setup phase
• Per-frame acknowledgments: Receiver sends ACK for each frame received
• Timeout and retransmission: Sender retransmits if ACK not received within timeout
• Still connectionless: No sequencing or flow control between frames
• Early error detection: Sender knows quickly when frames are lost

When Acknowledged Connectionless Service is Needed:

1. Unreliable Media: Wireless networks have much higher error rates than wired. Detecting losses at Layer 2 is faster than waiting for TCP timeout.

2. Real-Time Applications: Some applications need reliability but can't tolerate TCP delay. Localized retransmission is faster.

3. Remote Links: When round-trip time is high, waiting for end-to-end TCP retransmission wastes time. Link-layer recovery is faster.

The Case of Wireless LANs (802.11):

Wi-Fi uses acknowledged connectionless service at the MAC layer:

1. Station A sends data frame to Station B
2. After short interframe space (SIFS), B sends ACK frame
3. If A doesn't receive ACK, it retransmits after backoff
4. Maximum retry limit (typically 7 for data, 4 for management)

This link-layer reliability dramatically improves performance over unreliable wireless channels.

The connection-oriented service provides the most reliable DLL service. It establishes a logical connection before data transfer, provides sequencing, flow control, and error recovery.

Characteristics:

• Connection establishment: Three-phase process (connect request, connect confirm, data transfer)
• Sequenced delivery: Frames delivered to Network Layer in order sent
• Flow control: Receiver can control sender's rate (sliding window)
• Error recovery: Lost/corrupted frames detected and retransmitted
• Connection termination: Orderly shutdown of the connection

The Three Phases:

1. Connection Establishment:

• Sender requests connection to specific destination
• Resources are allocated (buffers, sequence number space, connection ID)
• Connection parameters negotiated (window size, etc.)

2. Data Transfer:

• Frames are numbered with sequence numbers
• Receiver acknowledges receipt (individual or cumulative ACKs)
• Flow control via window size
• Retransmission of lost/errored frames

3. Connection Release:

• Either party can initiate disconnection
• Outstanding data delivered or discarded
• Resources freed

Where Connection-Oriented DLL Service is Used:

1. HDLC (High-Level Data Link Control): The frame protocol for X.25, Frame Relay, PPP (optional). Provides numbered frames, sliding window flow control.

2. LLC Type 2: IEEE 802.2 connection-oriented service for legacy Token Ring networks and some industrial protocols.

3. Specialized Networks: Some industrial control networks and legacy systems use connection-oriented DLL for reliability guarantee.

Modern Perspective:

Connection-oriented DLL service has largely fallen out of favor for general networking. Why?

• TCP provides reliable, connection-oriented service at Layer 4
• Having reliability at both Layer 2 and Layer 4 is redundant and adds overhead
• End-to-end reliability (TCP) is preferred over hop-by-hop (DLL)

However, for specific applications—WAN links, virtual circuits, legacy integration—connection-oriented DLL service remains relevant.

Choosing the right DLL service type depends on the application requirements and the characteristics of the underlying network technology.

Comprehensive Comparison:

Decision Framework:

When selecting DLL service type (or understanding why a technology uses a specific type), consider:

1. Link Error Rate:

• Very low (< 10⁻¹⁰): Unacknowledged connectionless—errors are so rare, DLL recovery is unnecessary
• Moderate (10⁻⁶ to 10⁻⁴): Acknowledged connectionless—catch errors early, retransmit fast
• High (> 10⁻⁴): Consider FEC in addition, or connection-oriented for guaranteed delivery

2. Round-Trip Time:

• Low RTT: Unacknowledged is fine; TCP recovery is fast enough
• High RTT: Link-layer acknowledgment can significantly reduce recovery time

3. Higher-Layer Protocol:

• If TCP is used: Unacknowledged connectionless is sufficient; TCP handles reliability
• If UDP is used: Application must handle reliability, or use acknowledged DLL service

4. Traffic Type:

• Real-time (voice/video): Unacknowledged—retransmission would arrive too late
• Bulk transfer: Can tolerate connection-oriented overhead for guaranteed delivery
• Transactional: Acknowledged connectionless—fast with some reliability

The interface between the Network Layer and the Data Link Layer is where the abstract service definitions become concrete implementation. Understanding this interface illuminates how protocol stacks actually work.

What the Network Layer Provides to DLL:

To transmit a packet, the Network Layer must supply:

1. The data — The IP datagram (or other L3 PDU) to be sent
2. The destination — Either directly as a MAC address, or indirectly as an IP address that must be resolved
3. Quality of Service hints — Priority, delay sensitivity (often ignored in practice)

What the Network Layer Expects from DLL:

1. Frame delivery to the next hop — Not end-to-end; just to the next router or destination
2. Notification of incoming frames — With source address and demultiplexing information
3. Interface information — MTU, link status (up/down), speed

Address Resolution: The Critical Bridge:

The Network Layer uses IP addresses; the DLL uses MAC addresses. Address Resolution Protocol (ARP) bridges this gap:

1. Network Layer has IP datagram to send to IP address X
2. If X is on local network: Resolve X to MAC address
3. If X is remote: Resolve default gateway's IP to MAC address
4. DLL sends frame to resolved MAC address

ARP Operation:

• Check ARP cache for IP→MAC mapping
• If not found, broadcast ARP request: "Who has IP X? Tell me at IP Y"
• Owner of X responds with MAC address
• Cache the mapping for future use (with TTL)

This resolution happens at the boundary between Layer 3 and Layer 2—it's the mechanism that translates logical addressing to physical addressing.

Implementation Reality:

In actual operating systems, this interface is implemented through:

• Network stack APIs: OS-specific interfaces for sending/receiving (e.g., Linux net_device structure)
• Device drivers: Translate OS calls to NIC operations
• Interrupt handlers: Handle incoming frame notifications
• Buffer management: Memory for frame storage and transfer

For example, in Linux:

The Network Layer calls dev_queue_xmit(skb) to transmit
The NIC driver's ndo_start_xmit() function is invoked
Driver programs the NIC to send the frame
NIC generates interrupt when complete

Let's trace through real-world examples of DLL services in action, making the concepts concrete.

Example 1: Web Browsing over Ethernet (Unacknowledged Connectionless)

User requests a webpage:

Example 2: Video Call over Wi-Fi (Acknowledged Connectionless)

VoIP packet sent over wireless:

Example 3: PPP over Serial Link (Connection-Oriented Available)

PPP establishing a connection:

We've explored the services that the Data Link Layer provides to the Network Layer—the foundation for all internetworking.

What's Next:

Having explored what services the DLL provides, the final page examines how the DLL is implemented—the hardware and software components that bring these services to life, from NIC silicon to device drivers to protocol stacks.