Skip to main content

1. Introduction

1.1. Motivation​

The Internet Protocol is designed for use in interconnected systems of packet-switched computer communication networks. Such a system has been called a "catenet" [1]. The internet protocol provides for transmitting blocks of data called datagrams from sources to destinations, where sources and destinations are hosts identified by fixed length addresses. The internet protocol also provides for fragmentation and reassembly of long datagrams, if necessary, for transmission through "small packet" networks.

Core Design Goals​

1. Interconnection

Network A ←→ Gateway ←→ Network B ←→ Gateway ←→ Network C
  ↓                    ↓                    ↓
Host 1              Host 2              Host 3

IP enables different types of networks to interconnect

2. Datagram Delivery

  • Connectionless service
  • Each datagram independently routed
  • No guarantee of delivery, order, or duplication protection

3. Addressing

  • 32-bit fixed length addresses
  • Uniquely identify each host on the internet
  • Hierarchical structure (network + host)

4. Fragmentation & Reassembly

Large datagram (1500 bytes)
    ↓ Fragment
Fragment 1 (500 bytes) + Fragment 2 (500 bytes) + Fragment 3 (500 bytes)
    ↓ Transmit through small packet network
    ↓ Reassemble
Large datagram (1500 bytes)

1.2. Scope​

The internet protocol is specifically limited in scope to provide the functions necessary to deliver a package of bits (an internet datagram) from a source to a destination over an interconnected system of networks. There are no mechanisms to augment end-to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols. The internet protocol can capitalize on the services of its supporting networks to provide various types and qualities of service.

What IP Does NOT Provide​

FunctionIP ProvidesProvided By
Reliable delivery❌ NoTCP
Flow control❌ NoTCP
Sequencing❌ NoTCP
Error recovery❌ NoTCP
Connection management❌ NoTCP
Congestion control❌ NoTCP

What IP Provides​

FunctionDescription
✅ Addressing32-bit IP addresses
✅ RoutingDatagram forwarding
✅ Fragmentation/ReassemblyAdapt to different MTUs
✅ Time to LiveTTL prevents loops
✅ Type of ServiceToS field
✅ Header ChecksumDetect header errors

Design Philosophy​

End-to-End Principle:
- Keep IP layer simple
- Complex functions implemented at endpoints
- Network core only does forwarding

Advantages:
✅ Network scalability
✅ Support multiple upper layer protocols
✅ Failure domain isolation

1.3. Interfaces​

This protocol is called on by host-to-host protocols in an internet environment. This protocol calls on local network protocols to carry the internet datagram to the next gateway or destination host.

Upper Layer Interface​

Example: TCP calling IP

The TCP module would call on the internet module to take a TCP segment 
(including the TCP header and user data) as the data portion of an 
internet datagram. The TCP module would provide the addresses and other 
parameters in the internet header to the internet module as arguments 
of the call.

Interface Flow:

Application Layer
    ↓ Data
Transport Layer (TCP/UDP)
    ↓ TCP segment/UDP datagram
Network Layer (IP) ← Add IP header
    ↓ IP datagram
Data Link Layer (Ethernet/etc)
    ↓ Frame
Physical Layer

Lower Layer Interface​

Example: IP calling local network

In the ARPANET case, for example, the internet module would call on a 
local net module which would add the 1822 leader [2] to the internet 
datagram creating an ARPANET message to transmit to the IMP (Interface 
Message Processor). The ARPANET address would be derived from the 
internet address by the local network interface.

1822 Protocol Example:

+----------------+------------------+
| 1822 Leader    | IP Datagram      |
| (ARPANET-specific) | (Generic format) |
+----------------+------------------+

Interface Parameters​

IP Send Interface:

send_ip_datagram(
    source_address,      // Source IP address
    dest_address,        // Destination IP address
    protocol,            // Upper layer protocol (TCP=6, UDP=17)
    tos,                 // Type of Service
    ttl,                 // Time to Live
    data,                // Data
    length,              // Data length
    options              // IP options (optional)
);

IP Receive Interface:

receive_ip_datagram(
    source_address,      // Source IP address
    dest_address,        // Destination IP address
    protocol,            // Upper layer protocol
    data,                // Data
    length               // Data length
);

1.4. Operation​

The internet protocol implements two basic functions: addressing and fragmentation.

Addressing​

The internet modules use the addresses carried in the internet header to transmit internet datagrams toward their destinations. The selection of a path for transmission is called routing.

Address Structure:

32-bit IP Address = Network portion + Host portion

Class A: [0][7-bit network][24-bit host]
Class B: [10][14-bit network][16-bit host]
Class C: [110][21-bit network][8-bit host]

Routing Decision:

def route_datagram(dest_ip):
    if dest_ip in local_network:
        # Direct delivery
        send_to_host(dest_ip)
    else:
        # Forward to gateway
        gateway = lookup_routing_table(dest_ip)
        send_to_gateway(gateway, datagram)

Fragmentation​

The internet modules use fields in the internet header to fragment and reassemble internet datagrams when necessary for transmission through "small packet" networks.

Fragmentation Process:

Original datagram (MTU=1500):
+--------+------------------------+
| IP hdr |     1480 bytes data    |
+--------+------------------------+

After fragmentation through MTU=500 network:

Fragment 1:
+--------+--------+
| IP hdr | 480 bytes | MF=1, Offset=0
+--------+--------+

Fragment 2:
+--------+--------+
| IP hdr | 480 bytes | MF=1, Offset=60
+--------+--------+

Fragment 3:
+--------+--------+
| IP hdr | 520 bytes | MF=0, Offset=120
+--------+--------+

Fragmentation Fields:

  • Identification: Identifies the original datagram
  • Flags:
    • DF (Don't Fragment): Do not fragment
    • MF (More Fragments): More fragments follow
  • Fragment Offset: Position of fragment in original datagram (8-byte units)

Model of Operation​

The model of operation is that an internet module resides in each host engaged in internet communication and in each gateway that interconnects networks. These modules share common rules for interpreting address fields and for fragmenting and assembling internet datagrams. In addition, these modules (especially in gateways) have procedures for making routing decisions and other functions.

The internet protocol treats each internet datagram as an independent entity unrelated to any other internet datagram. There are no connections or logical circuits (virtual or otherwise).

Sender:
1. Receive data from upper layer
2. Add IP header
3. Look up routing table
4. Fragment if necessary
5. Pass to local network

Intermediate Gateway:
1. Receive IP datagram
2. Check destination address
3. Look up routing table
4. Decrement TTL
5. Fragment if necessary
6. Forward to next hop

Receiver:
1. Receive IP datagram
2. Check destination address (is it for me?)
3. Reassemble if fragmented
4. Pass to upper layer protocol

Key Mechanisms​

The internet protocol uses four key mechanisms in providing its service: Type of Service, Time to Live, Options, and Header Checksum.

Type of Service

  • Used to indicate the quality of service desired
  • Abstract or generalized set of parameters
  • Used by gateways to select transmission parameters
  • Guides routing and network selection decisions

Time to Live

  • Upper bound on datagram lifetime
  • Set by sender, decremented at each hop
  • Datagram destroyed when TTL reaches zero
  • Can be thought of as a self-destruct time limit

Options

  • Control functions needed in some situations
  • Unnecessary for most common communications
  • Include provisions for timestamps, security, and special routing

Header Checksum

  • Verification that header was transmitted correctly
  • Data may contain errors (not checked by IP)
  • If checksum fails, datagram is discarded immediately

Reliability Model​

The internet protocol does not provide a reliable communication facility. There are no acknowledgments either end-to-end or hop-by-hop. There is no error control for data, only a header checksum. There are no retransmissions. There is no flow control.

Errors detected may be reported via the Internet Control Message Protocol (ICMP) [3] which is implemented in the internet protocol module.

Key Concepts Summary​

Datagram​

  • Independent packet
  • Contains complete addressing information
  • Can be routed independently

Connectionless​

  • No connection establishment needed
  • Each datagram handled independently
  • Simple and efficient

Best Effort​

  • No guarantee of delivery
  • No guarantee of ordering
  • No guarantee against duplication
  • Reliability handled by upper layer protocols

Design Philosophy: The IP protocol follows the "simple network, intelligent endpoints" design philosophy, pushing complexity to the network edges and keeping the core network simple and scalable. This design enables the internet to support a wide variety of applications and services.

Last updated on