The Network Layer

The network service model defines the characteristics of end-to-end delivery of packets
between sending and receiving hosts.

Some possible services that the network layer could provide include:
● Guaranteed delivery. This service guarantees that a packet sent by a source host will
eventually arrive at the destination host.
● Guaranteed delivery with bounded delay. This service not only guarantees delivery of the
packet, but delivery within a specified host-to-host delay bound (for example, within 100
msec).
● In-order packet delivery. This service guarantees that packets arrive at the desti- nation in
the order that they were sent.
● Guaranteed minimal bandwidth. This network-layer service emulates the behavior of a
transmission link of a specified bit rate (for example, 1 Mbps) between sending and
receiving hosts. As long as the sending host transmits bits (as part of packets) at a rate
below the specified bit rate, then all packets are eventually delivered to the destination
host.
● Security. The network layer could encrypt all datagrams at the source and decrypt them
at the destination, thereby providing confidentiality to all transport-layer segments.

The Internet’s network layer provides a single service, known as best-effort service. With best-
effort service, packets are neither guaranteed to be received in the order in which they were sent,
nor is their eventual delivery even guaranteed. There is no guarantee on the end-to-end delay nor
is there a minimal bandwidth guarantee. It might appear that best-effort service is a euphemism
for no service at all—a network that delivered no packets to the destination would satisfy the
definition of best-effort delivery service! So essentially no services mentioned above are provided.
Forwarding and Routing: The Data and Control Planes

The primary role of the network layer is deceptively simple—to move packets from a sending host to a
receiving host. To do so, two important network-layer functions can be identified:

• Forwarding. When a packet arrives at a router’s input link, the router must move the packet to the
appropriate output link. For example, a packet arriving from Host H1 to Router R1 in Figure 4.1 must be
forwarded to the next router on a path to H2. As we will see, forwarding is but one function (albeit the most
common and important one!) implemented in the data plane.
• Routing. The network layer must determine the route or path taken by packets as they flow from a sender
to a receiver. Determining these paths is like marking the route from one destination to another. Just like
Google Maps does for us. When we ask for a route from source to destination the Maps app does not work
out the appropriate route but only shows us the best precomputed route. Likewise best paths are
precomputed in the network. The algorithms that calculate these paths are referred to as routing algorithms.
A routing algorithm would determine, for example, the path along which packets flow from H1 to H2 in
Figure 4.1. Routing is implemented in the control plane of the network layer.

An Example

Take into consideration a trip from Lahore to Karachi undertaken by a traveler. During this trip, our driver
passes through many interchanges on the way to Karachi. We can think of forwarding as the process of
getting through a single interchange: A car enters the interchange from one road and determines which
road it should take to leave the interchange. We can think of routing as the process of planning the trip
from Lahore to Karachi; marking our route! Before embarking on the trip, the driver has consulted a map
and chosen one of many paths possible, with each path consisting of a series of road segments connected
at interchanges. Forwarding then is looking up the map at every interchange and reading what exit to take
to keep on the route that we had marked for ourselves on the map

IPv4 Datagram Format

Recall that the Internet’s network-layer packet is referred to as a datagram. We begin our study
of IP with an overview of the syntax and semantics of the IPv4 datagram. You might be thinking
that nothing could be drier than the syntax and semantics of a packet’s bits. Nevertheless, the
datagram plays a central role in the Internet—every networking student and professional needs
to see it, absorb it, and master it. (And just to see that protocol headers can indeed be fun to
study, check out [Pomeranz 2010]). The IPv4 datagram format is shown in Figure 4.17. The key
fields in the IPv4 datagram are the following:
● Version number. These 4 bits specify the IP protocol version of the datagram. By looking
at the version number, the router can determine how to interpret the remainder of the IP
datagram. Different versions of IP use different datagram formats. The datagram format
for IPv4 is shown in Figure 4.17. The datagram format for the new version of IP (IPv6) is
discussed in Section 4.3.4.
● Header length. Because an IPv4 datagram can contain a variable number of options
(which are included in the IPv4 datagram header), these 4 bits are needed to determine
where in the IP datagram the payload (for example, the transport-layer segment being
encapsulated in this datagram) actually begins. Most IP data-grams do not contain
options, so the typical IP datagram has a 20-byte header.
● Type of service. The type of service (TOS) bits were included in the IPv4 header to allow
different types of IP datagrams to be distinguished from each other. For example, it might
be useful to distinguish real-time datagrams (such as those used by an IP telephony
application) from non-real-time traffic (e.g., FTP). The specific level of service to be
provided is a policy issue determined and configured by the network administrator for that
router. We also learned in Section 3.7.2 that two of the TOS bits are used for Explicit
Congestion Notification.
● Datagram length. This is the total length of the IP datagram (header plus data), meas-
ured in bytes. Since this field is 16 bits long, the theoretical maximum size of the IP
datagram is 65,535 bytes. However, datagrams are rarely larger than 1,500 bytes, which
allows an IP datagram to fit in the payload field of a maximally sized Ethernet frame.
● Identifier, flags, fragmentation offset. These three fields have to do with so-called IP
fragmentation, when a large IP datagram is broken into several smaller IP data- grams
which are then forwarded independently to the destination, where they are reassembled
before their payload data (see below) is passed up to the transport layer at the destination
host. Interestingly, the new version of IP, IPv6, does not allow for fragmentation. We’ll not
cover fragmentation here; but readers can find a detailed discussion online, among the
“retired” material from earlier versions of this book.
● Time-to-live. The time-to-live (TTL) field is included to ensure that datagrams do not
circulate forever (due to, for example, a long-lived routing loop) in the network. This field
is decremented by one each time the datagram is processed by a router. If the TTL field
reaches 0, a router must drop that datagram.
● Protocol. This field is typically used only when an IP datagram reaches its final destination.
The value of this field indicates the specific transport-layer protocol to which the data
portion of this IP datagram should be passed. For example, a value of 6 indicates that the
data portion is passed to TCP, while a value of 17 indicates that the data is passed to
UDP. For a list of all possible values, see [IANA Protocol Numbers 2016]. Note that the
protocol number in the IP datagram has a role that is analogous to the role of the port
number field in the transport-layer segment. The protocol number is the glue that binds
the network and transport layers together, whereas the port number is the glue that binds
the transport and application layers together. We’ll see in Chapter 6 that the link-layer
frame also has a special field that binds the link layer to the network layer.
● Header checksum. The header checksum aids a router in detecting bit errors in a received
IP datagram. The header checksum is computed by treating each 2 bytes in the header
 as a number and summing these numbers using 1s complement arith- metic. As discussed
in Section 3.3, the 1s complement of this sum, known as the Internet checksum, is stored
in the checksum field. A router computes the header checksum for each received IP
datagram and detects an error condition if the checksum carried in the datagram header
does not equal the computed check- sum. Routers typically discard datagrams for which
an error has been detected. Note that the checksum must be recomputed and stored again
at each router, since the TTL field, and possibly the options field as well, will change. An
interesting discussion of fast algorithms for computing the Internet checksum is [RFC
1071]. A question often asked at this point is, why does TCP/IP perform error checking at
both the transport and network layers? There are several reasons for this repetition. First,
note that only the IP header is check summed at the IP layer, while the TCP/ UDP
checksum is computed over the entire TCP/UDP segment. Second, TCP/ UDP and IP do
not necessarily both have to belong to the same protocol stack. TCP can, in principle, run
over a different network-layer protocol (for example, ATM) [Black 1995]) and IP can carry
data that will not be passed to TCP/UDP.
● Source and destination IP addresses. When a source creates a datagram, it inserts its IP
address into the source IP address field and inserts the address of the ultimate destination
into the destination IP address field. Often the source host determines the destination
address via a DNS lookup, as discussed in Chapter 2.
● Options. The options fields allow an IP header to be extended. Header options were meant
to be used rarely—hence the decision to save overhead by not including the information
in options fields in every datagram header. However, the mere existence of options does
complicate matters—since datagram headers can be of variable length, one cannot
determine a priori where the data field will start. Also, since some datagrams may require
options processing and others may not, the amount of time needed to process an IP
datagram at a router can vary greatly. These considerations become particularly important
for IP processing in high- performance routers and hosts. For these reasons and others,
IP options were not included in the IPv6 header.
● Data (payload). Finally, we come to the last and most important field—the raison d’etre
for the datagram in the first place! In most circumstances, the data field of the IP
datagram contains the transport-layer segment (TCP or UDP) to be delivered to the
destination. However, the data field can carry other types of data, such as ICMP
messages (discussed in Section 5.6).
Note that an IP datagram has a total of 20 bytes of header (assuming no options). If the
datagram carries a TCP segment, then each datagram carries a total of 40 bytes of
header (20 bytes of IP header plus 20 bytes of TCP header) along with the application-
layer message.

IPv4 Addressing
We now turn our attention to IPv4 addressing. Although you may be thinking that addressing must be a
straightforward topic, hopefully by the end of this section you’ll be convinced that Internet addressing is not
only a juicy, subtle, and interesting topic but also one that is of central importance to the Internet. An
excellent treatment of IPv4 addressing can be found in the first chapter in [Stewart 1999].
Before discussing IP addressing, however, we’ll need to say a few words about how hosts and routers are
connected into the Internet. A host typically has only a single link into the network; when IP in the host
wants to send a datagram, it does so over this link. The boundary between the host and the physical link is
called an interface. Now consider a router and its interfaces. Because a router’s job is to receive a
datagram on one link and forward the datagram on some other link, a router necessarily has two or more
links to which it is connected. The boundary between the router and any one of its links is also called an
interface. A router thus has multiple interfaces, one for each of its links. Because every host and router is
capable of send- ing and receiving IP datagrams, IP requires each host and router interface to have its own
IP address. Thus, an IP address is technically associated with an interface, rather than with the host or
router containing that interface.

Each IP address is 32 bits long (equivalently, 4 bytes), and there are thus a total of 2 32 (or approximately 4
billion) possible IP addresses. These addresses are typically written in so-called dotted-decimal notation,
in which each byte of the address is written in its decimal form and is separated by a period (dot) from other
bytes in the address. For example, consider the IP address 193.32.216.9. The 193 is the decimal equivalent
of the first 8 bits of the address; the 32 is the decimal equivalent of the second 8 bits of the address, and
so on. Thus, the address 193.32.216.9 in binary notation is

11000001 00100000 11011000 00001001

Each interface on every host and router in the global Internet must have an IP address that is globally
unique (except for interfaces behind NATs (which we will briefly discuss in class).