1.2 TCP/IP Protocol Stack and Data Encapsulation

1.2 TCP/IP Protocol Stack and Data Encapsulation

While the OSI reference model provides a theoretical framework for networking concepts, the TCP/IP protocol suite (also known as the Internet Protocol Suite) represents the practical, universally implemented architecture that powers modern enterprise backbones and the global Internet. Developed through research funded by the U.S. Defense Advanced Research Projects Agency (DARPA) and formalized in RFC 1122, the TCP/IP architecture was designed with a fundamental engineering mandate: to create a robust, survivable, and highly scalable packet-switched network capable of maintaining communication sessions even if underlying transmission links suffer catastrophic failure.

---

The 4-Layer TCP/IP Architecture

Unlike the 7-layer OSI model, the TCP/IP model organizes network functionality into four pragmatic layers. It consolidates the upper application-oriented layers and collapses the lower hardware-dependent media functions.

Layer Responsibilities in the TCP/IP Model

1. Application Layer: Provides network services directly to end-user applications and system processes. Application developers write software that interfaces directly with transport sockets (such as TCP or UDP ports), handling any necessary data presentation, compression, and session tracking within the application code itself.
2. Transport Layer: Provides end-to-end communication channels between software processes running on distinct hosts. It abstracts the underlying network routing topology, delivering application payloads across standard interfaces.
3. Internet Layer: Packages transport segments into routable IP datagrams (packets), attaches source and destination IP addresses, and routes packets across interconnected network hops using dynamic routing protocols and local forwarding tables.
4. Network Interface (Link) Layer: Defines the physical media characteristics and protocols required to transmit IP packets across a single local network segment or physical link between adjacent network nodes.

---

Data Encapsulation and Decapsulation Workflows

For network communication to succeed, data must traverse the protocol stack through two mirror-image operations: encapsulation at the sending host and decapsulation at the receiving host.

The Encapsulation Process (Outbound Transmission)

When a user application (such as a web browser or a BGP routing daemon) transmits data, the payload moves downward through the stack:

1. Application Layer: The application formats its raw payload (e.g., an HTTP GET request or BGP UPDATE message) and hands the data stream to the Transport Layer.
2. Transport Layer Encapsulation: The Transport Layer takes the application data and prepends a TCP or UDP header. This header includes the source port and destination port numbers. The resulting unit is called a Segment (for TCP) or a Datagram (for UDP).
3. Internet Layer Encapsulation: The Internet Layer accepts the transport segment as its payload (SDU) and prepends an IP header. This header contains the source and destination IP addresses, Time-to-Live (TTL), and the Protocol field identifying the transport protocol. The resulting data structure is an IP Packet.
4. Network Interface Layer Encapsulation: The packet is passed down to the link layer, which prepends a Data Link header containing the source and destination physical hardware MAC addresses and the EtherType field. It also appends a Frame Check Sequence (FCS) trailer containing a CRC-32 checksum to form a Frame.
5. Physical Transmission: The network interface card (NIC) converts the frame's digital bits into electrical voltages, light pulses, or radio signals, transmitting them across the physical medium.

The Decapsulation Process and Protocol Demultiplexing

When the receiving host's physical network adapter detects incoming signals, it reconstructs the bit stream into a frame and initiates decapsulation, working upward through the stack:

1. Frame Verification and Link Decapsulation: The receiving NIC calculates a CRC over the frame and compares it with the FCS trailer. If no transmission errors occurred, the NIC strips the Layer 2 header and trailer. To determine which network protocol should receive the packet, it reads the EtherType field:
   • 0x0800 → Hand payload to IPv4.
   • 0x86DD → Hand payload to IPv6.
   • 0x0806 → Hand payload to ARP.
2. Internet Layer Decapsulation: The IP module inspects the destination IP address to verify that the packet is destined for this host (or needs forwarding, if operating as a router). If the packet is destined for the local host, the IP header is stripped. The IP module examines the 8-bit Protocol field (or Next Header in IPv6) to determine the transport destination:
   • Protocol 6 → Hand payload to TCP.
   • Protocol 17 → Hand payload to UDP.
   • Protocol 1 → Hand payload to ICMP.
   • Protocol 89 → Hand payload to OSPF.
3. Transport Layer Decapsulation: The transport layer (TCP or UDP) inspects the 16-bit Destination Port number in the transport header. The port number identifies the specific listening socket or application process (e.g., port 80 for a web server, port 179 for BGP). The transport header is stripped, and the original, unaltered application data is delivered into the receiving application's buffer.

---

Transport Layer Comparison: TCP vs. UDP

The transport layer offers two primary workhorse protocols that represent fundamentally different design philosophies regarding reliability, overhead, and latency.

TCP Mechanics: Reliability, Handshaking, and Flow Control

TCP (RFC 9293, the current core specification) achieves robust reliability across unreliable network paths through several sophisticated mechanisms:

1. The Three-Way Handshake

Before any user data can be exchanged, TCP must establish a synchronized, stateful connection between client and server:

• Step 1 (SYN): The client transmits a segment with the SYN (Synchronize) control flag asserted and chooses an Initial Sequence Number (ISN), denoted as Seq = X.
• Step 2 (SYN-ACK): The server receives the SYN and responds with both SYN and ACK flags asserted. The server acknowledges the client's sequence number by sending Ack = X + 1 and selects its own Initial Sequence Number, denoted as Seq = Y.
• Step 3 (ACK): The client completes the handshake by transmitting a segment with the ACK flag asserted, confirming the server's sequence number with Ack = Y + 1. Once the three-way handshake completes, both endpoints transition to the ESTABLISHED state and bidirectional data transfer begins.

2. Sequence and Acknowledgment Numbers

TCP numbers bytes in its stream; a segment header identifies its first data byte. SYN and FIN also consume sequence space. The receiver sends cumulative acknowledgments indicating the next byte it expects to receive (ACK = next contiguous byte expected). If a segment is dropped in transit, the receiver's acknowledgment remains stalled at the missing byte offset, prompting the sender's retransmission timer to fire and retransmit the missing data.

3. Sliding Window Flow Control

TCP dynamically regulates data transmission speed to match the receiver's available processing capacity. The receiving host advertises its available buffer space inside the Receive Window (rwnd) field of every acknowledgment segment. The sender is permitted to transmit only up to the unacknowledged byte volume indicated by rwnd. If the receiver's application processes data slowly, the advertised window shrinks; if buffers fill completely, the receiver advertises a zero-window (rwnd = 0), instructing the sender to pause transmission immediately until buffer space frees.

4. Connection Teardown

When communication concludes, TCP closes the session gracefully typically through FIN and ACK exchanges; combining FIN and ACK can reduce the packet count. A common four-packet example is:

1. Initiator sends a FIN (Finish) segment.
2. Responder acknowledges with an ACK.
3. Responder completes its pending data transmission and sends its own FIN.
4. Initiator acknowledges with a final ACK, closing the connection after a safety timeout (TIME_WAIT).

UDP Mechanics: Lightweight and Connectionless

UDP (RFC 768) strips transport communication down to its bare essentials. The UDP header is fixed at exactly 8 bytes, containing only four 16-bit fields:

1. Source Port: Identifies the sending application process (optional in some implementations).
2. Destination Port: Identifies the receiving application process.
3. Length: Specifies the total length of the UDP header plus payload in bytes.
4. Checksum: Provides optional (IPv4) or mandatory (IPv6) error detection over the header and data.

Because UDP maintains no session state, it requires no three-way handshake, eliminates connection setup latency, and introduces no transmission overhead for sequence tracking or acknowledgment packets. If a packet is lost due to network congestion or link corruption, UDP does not retransmit it; upper-layer applications (such as real-time audio codecs or DNS resolvers) must handle retransmission if desired.

---

Critical Well-Known Port Numbers

Transport layer port numbers are 16-bit integers ranging from 0 to 65535. The Internet Assigned Numbers Authority (IANA) divides the port space into three distinct categories:

• Well-Known Ports (0 to 1023): Reserved for system services and standard Internet protocols.
• Registered Ports (1024 to 49151): Assigned by IANA to specific user processes or vendor software applications upon request.
• Dynamic / Private / Ephemeral Ports (49152 to 65535): Allocated dynamically by client operating systems as temporary source ports when initiating outbound connections.

In telecommunications and carrier routing environments, network engineers and candidates preparing for the Nokia NRS I certification must master critical well-known port numbers and their transport protocols:

Exam Tip: Pay particular attention to the dual transport usage of LDP (Port 646) and DNS (Port 53):

• LDP utilizes UDP port 646 to transmit multicast "Hello" discovery packets to discover adjacent MPLS routers (sent to the All-Routers multicast address 224.0.0.2), and then initiates a TCP port 646 connection to establish a reliable, stateful session for exchanging MPLS label bindings.
• BGP utilizes TCP port 179 exclusively. Because BGP relies on TCP for reliability, retransmission, and flow control, it does not need to implement its own transport reliability mechanisms.

Primary technical reference

Specification or Nokia manual, checked October 20, 2026. Examples are teaching scenarios, not captured router execution.