Network Layer Protocols

In the previous pages, we examined individual protocols in isolation: IP for forwarding, routing protocols for path discovery, and control protocols for operational support. But real networking requires these protocols to work together seamlessly—each performing its role at precisely the right moment.

Understanding protocol interaction is essential for diagnosing network issues, designing robust systems, and truly grasping how the Internet functions. A simple webpage request involves dozens of protocol invocations across multiple layers—all invisible to the user but carefully orchestrated by the protocol stack.

The OSI and TCP/IP models describe layers, and each layer communicates with the layers immediately adjacent to it. This vertical interaction follows strict patterns:

Downward Flow (Sending):

1. Application creates data (e.g., HTTP request)
2. Transport layer adds header (TCP segment), handles reliability
3. Network layer adds IP header, determines next hop
4. Data link layer adds frame header/trailer, may require ARP
5. Physical layer converts to bits and transmits

Upward Flow (Receiving):

1. Physical layer receives bits, reconstructs frame
2. Data link layer validates frame, strips header, delivers to network layer
3. Network layer validates IP header, strips it, delivers to transport layer
4. Transport layer reassembles segments, delivers to application
5. Application processes received data

Encapsulation and De-encapsulation:

Each layer adds its own header (and sometimes trailer) to the data from above—this is encapsulation. The receiving side reverses this—de-encapsulation—stripping each layer's header as data moves up.

[Ethernet Header][IP Header][TCP Header][HTTP Data][Ethernet Trailer]
└─ Frame ─────────────────────────────────────────────────────────────┘
              └─ Packet ───────────────────────────────────────┘
                          └─ Segment ──────────────────────┘
                                      └─ Message ──────────┘

Service Primitives:

Layers communicate through defined service interfaces. For example, the network layer offers:

• send(destination_IP, data) — Transport layer asks network layer to deliver data
• receive(source_IP, data) — Network layer delivers received data to transport layer

Each layer doesn't need to understand how the layer below accomplishes its task—only that the service will be performed. This abstraction is what makes layered architecture powerful.

The relationship between IP and transport protocols (TCP/UDP) exemplifies careful protocol design—each handles distinct responsibilities while depending on the other.

What IP Provides to Transport:

• Host-to-host delivery: IP gets the packet to the right machine
• Source and destination addressing: Transport knows where packet came from
• Best-effort service: Transport must handle unreliability

What Transport Adds:

• Port numbers: Demultiplexing to correct application
• Reliable delivery (TCP): Retransmissions, acknowledgments
• Ordering (TCP): Sequence numbers ensure correct order
• Flow control (TCP): Prevent sender overwhelming receiver
• Congestion control (TCP): Prevent overloading the network

Or for UDP: essentially just port demultiplexing with minimal overhead.

The Pseudo-Header:

An interesting interaction occurs in checksum calculation. TCP and UDP checksums cover not just their own headers and data, but also a "pseudo-header" including:

• Source IP address
• Destination IP address
• Protocol number
• Segment length

This pseudo-header isn't actually transmitted—it's artificially constructed from the IP header. This design ensures that if a segment arrives at the wrong destination IP (due to corruption), the checksum will fail. It ties transport integrity to network layer addressing.

Fragmentation Interaction:

If an IP packet carrying a TCP segment is fragmented:

1. Each fragment has an IP header but only the first has the TCP header
2. Receiver must reassemble all fragments before passing to TCP
3. If any fragment is lost, the entire TCP segment is lost
4. TCP will retransmit the segment after timeout
5. The retransmit may be fragmented again

This is why Path MTU Discovery is important—avoiding fragmentation improves efficiency and reduces failure probability.

The interaction between IP (Network Layer) and Data Link Layer is crucial because ultimately, bits must traverse physical media. This interaction involves address resolution and frame construction.

The Fundamental Problem:

IP provides logical addressing (IP addresses), but Ethernet (and other LAN technologies) uses hardware addressing (MAC addresses). Before IP can ask the data link layer to transmit, it must determine the appropriate MAC address.

ARP Integration:

When IP needs to send a packet:

1. If destination is on the same subnet: Need MAC for destination IP
2. If destination is on different subnet: Need MAC for default gateway's IP
3. Check ARP cache for existing mapping
4. If not found, invoke ARP (broadcast request, wait for reply)
5. Once MAC is known, construct Ethernet frame with that destination

This creates an important delay for the first packet to a new destination—subsequent packets use the cached ARP entry.

Key Insight: MAC Changes, IP Doesn't

As a packet traverses the network, the IP addresses (source and destination) remain constant, but MAC addresses change at each hop:

Host → Router1 → Router2 → Server

Hop 1: MAC:Host→R1, IP:Host→Server
Hop 2: MAC:R1→R2, IP:Host→Server
Hop 3: MAC:R2→Server, IP:Host→Server

Each router:

1. Receives frame, checks destination MAC (is it for me?)
2. Strips Ethernet header, examines IP header
3. Looks up destination IP in routing table
4. Determines next hop (or final destination)
5. ARPs for next-hop MAC if needed
6. Creates new Ethernet frame with new MACs
7. Transmits on appropriate interface

MTU Considerations:

Different link technologies have different Maximum Transmission Units. IP must interact with the data link layer to determine if fragmentation is needed. The interface reports its MTU; IP compares packet size to MTU and fragments if necessary (IPv4) or returns error/uses PMTUD (IPv6).

Routing protocols and IP forwarding are often discussed together but operate on fundamentally different timescales and in different planes.

Control Plane vs Data Plane:

• Control Plane (Routing): Runs periodically or on topology changes; builds routing table
• Data Plane (Forwarding): Runs for every packet; uses routing table to make decisions

Routing protocols might update the routing table once per second or less frequently. Forwarding decisions happen millions of times per second. They must not interfere with each other.

The Routing Table as Interface:

The routing table serves as the interface between control and data planes:

1. Routing protocols write to the routing table:

   • OSPF learns about network 10.0.0.0/8 via neighbor, updates table
   • BGP receives path to 203.0.113.0/24, adds to table

2. Forwarding reads from the routing table:

   • Packet arrives for 10.5.6.7
   • Lookup finds entry for 10.0.0.0/8: next-hop 192.168.1.254, exit eth0
   • Packet is forwarded accordingly

Multiple Routing Sources:

Large routers may run multiple routing protocols. Each proposes routes; the router uses administrative distance (preference) to choose:

• Connected routes: 0 (most preferred)
• Static routes: 1
• OSPF: 110
• RIP: 120
• eBGP: 20
• iBGP: 200

If OSPF and RIP both have routes to the same destination, OSPF (lower distance) wins.

Forwarding Information Base (FIB):

In high-performance routers, the routing table (RIB - Routing Information Base) is separate from the forwarding table (FIB). The control plane populates the RIB; selected entries are pushed to the FIB, which is optimized for fast lookups (often in specialized hardware).

Let's trace a complete packet journey to see all protocols interacting. The scenario: User at 192.168.1.100 loads www.example.com.

Phase 1: DNS Resolution (before any data transfer)

Phase 2: TCP Connection Establishment

Phase 3: HTTP Request and Response

Protocol Invocation Count:

In this simple webpage load, consider what happened:

• DNS: 2 UDP exchanges (query and response)
• TCP: 3-way handshake + data + 4-way close = dozens to hundreds of segments
• IP: Every TCP segment is an IP packet
• ARP: Possibly at each new hop (or cache hits)
• OSPF/BGP: Running in background at every router, maintaining routes
• Ethernet: Frame for every packet at every hop

A single webpage might generate 200+ packets, each processed at 10-20 hops, meaning thousands of individual protocol interactions—all in under a second.

When problems occur, protocols must cooperate to handle errors appropriately. Different layers handle different types of failures.

Layered Error Handling:

Example: Unreachable Host Scenario

Imagine sending to a host that's powered off:

1. IP packet arrives at final router (gateway of destination network)
2. Router needs destination MAC—sends ARP request
3. No ARP reply (host is down)
4. Router retries ARP (typically 3 times)
5. All retries fail
6. Router generates ICMP Destination Unreachable (Host Unreachable)
7. ICMP is sent back to source
8. Source's TCP receives ICMP error
9. TCP signals connection failure to application
10. Application handles (shows error to user)

Example: MTU Problem Scenario

1. Source sends 1500-byte packet with DF (Don't Fragment) set
2. Path includes a tunnel with 1400-byte MTU
3. Router can't forward (too large) and can't fragment (DF set)
4. Router sends ICMP Packet Too Big (with MTU=1400)
5. Source receives ICMP, learns path MTU
6. Source resends with smaller packets (1400 bytes)
7. Subsequent packets pass through tunnel successfully

Note: If firewalls block ICMP, PMTUD fails—creating 'black holes' where packets silently vanish at the MTU boundary.

Network communication is a symphony of protocols, each playing its part at precisely the right moment. The layered architecture provides clean interfaces between components, enabling each to evolve independently while maintaining interoperability.