[ Team LiB ]

5.1 Network Layer Design Issues

In the following sections we will provide an introduction to some of the issues that the designers
of the network layer must grapple with. These issues include the service provided to the transport
layer and the internal design of the subnet.

5.1.1 Store-and-Forward Packet Switching

But before starting to explain the details of the network layer, it is probably worth restating the
context in which the network layer protocols operate. This context can be seen in Fig. 5-1. The
major components of the system are the carrier's equipment (routers connected by transmission
lines), shown inside the shaded oval, and the customers' equipment, shown outside the oval. Host
H1 is directly connected to one of the carrier's routers, A, by a leased line. In contrast, H2 is on a
LAN with a router, F, owned and operated by the customer. This router also has a leased line to
the carrier's equipment. We have shown F as being outside the oval because it does not belong to
the carrier, but in terms of construction, software, and protocols, it is probably no different from
the carrier's routers. Whether it belongs to the subnet is arguable, but for the purposes of this
chapter, routers on customer premises are considered part of the subnet because they run the
same algorithms as the carrier's routers (and our main concern here is algorithms).

Figure 5-1. The environment of the network layer protocols.

This equipment is used as follows. A host with a packet to send transmits it to the nearest router,
either on its own LAN or over a point-to-point link to the carrier. The packet is stored there until
it has fully arrived so the checksum can be verified. Then it is forwarded to the next router along
the path until it reaches the destination host, where it is delivered. This mechanism is store-and-
forward packet switching, as we have seen in previous chapters.

5.1.2 Services Provided to the Transport Layer

The network layer provides services to the transport layer at the network layer/transport layer
interface. An important question is what kind of services the network layer provides to the
transport layer. The network layer services have been designed with the following goals in mind.
 1. The services should be independent of the router technology.
2. The transport layer should be shielded from the number, type, and topology of the routers
present.
3. The network addresses made available to the transport layer should use a uniform
numbering plan, even across LANs and WANs.

Given these goals, the designers of the network layer have a lot of freedom in writing detailed
specifications of the services to be offered to the transport layer. This freedom often degenerates
into a raging battle between two warring factions. The discussion centers on whether the network
layer should provide connection-oriented service or connectionless service.

One camp (represented by the Internet community) argues that the routers' job is moving packets
around and nothing else. In their view (based on 30 years of actual experience with a real,
working computer network), the subnet is inherently unreliable, no matter how it is designed.
Therefore, the hosts should accept the fact that the network is unreliable and do error control
(i.e., error detection and correction) and flow control themselves.

This viewpoint leads quickly to the conclusion that the network service should be connectionless,
with primitives SEND PACKET and RECEIVE PACKET and little else. In particular, no packet
ordering and flow control should be done, because the hosts are going to do that anyway, and
there is usually little to be gained by doing it twice. Furthermore, each packet must carry the full
destination address, because each packet sent is carried independently of its predecessors, if any.

The other camp (represented by the telephone companies) argues that the subnet should provide
a reliable, connection-oriented service. They claim that 100 years of successful experience with
the worldwide telephone system is an excellent guide. In this view, quality of service is the
dominant factor, and without connections in the subnet, quality of service is very difficult to
achieve, especially for real-time traffic such as voice and video.

These two camps are best exemplified by the Internet and ATM. The Internet offers
connectionless network-layer service; ATM networks offer connection-oriented network-layer
service. However, it is interesting to note that as quality-of-service guarantees are becoming
more and more important, the Internet is evolving. In particular, it is starting to acquire
properties normally associated with connection-oriented service, as we will see later. Actually,
we got an inkling of this evolution during our study of VLANs in Chap. 4.

5.1.3 Implementation of Connectionless Service

Having looked at the two classes of service the network layer can provide to its users, it is time
to see how this layer works inside. Two different organizations are possible, depending on the
type of service offered. If connectionless service is offered, packets are injected into the subnet
individually and routed independently of each other. No advance setup is needed. In this context,
the packets are frequently called datagrams (in analogy with telegrams) and the subnet is called a
datagram subnet. If connection-oriented service is used, a path from the source router to the
destination router must be established before any data packets can be sent. This connection is
called a VC (virtual circuit), in analogy with the physical circuits set up by the telephone system,
and the subnet is called a virtual-circuit subnet. In this section we will examine datagram
subnets; in the next one we will examine virtual-circuit subnets.

Let us now see how a datagram subnet works. Suppose that the process P1 in Fig. 5-2 has a long
message for P2. It hands the message to the transport layer with instructions to deliver it to
process P2 on host H2. The transport layer code runs on H1, typically within the operating
system. It prepends a transport header to the front of the message and hands the result to the
network layer, probably just another procedure within the operating system.

Figure 5-2. Routing within a datagram subnet.

Let us assume that the message is four times longer than the maximum packet size, so the
network layer has to break it into four packets, 1, 2, 3, and 4 and sends each of them in turn to
router A using some point-to-point protocol, for example, PPP. At this point the carrier takes
over. Every router has an internal table telling it where to send packets for each possible
destination. Each table entry is a pair consisting of a destination and the outgoing line to use for
that destination. Only directly-connected lines can be used. For example, in Fig. 5-2, A has only
two outgoing lines—to B and C—so every incoming packet must be sent to one of these routers,
even if the ultimate destination is some other router. A's initial routing table is shown in the
figure under the label ''initially.''

As they arrived at A, packets 1, 2, and 3 were stored briefly (to verify their checksums). Then
each was forwarded to C according to A's table. Packet 1 was then forwarded to E and then to F.
When it got to F, it was encapsulated in a data link layer frame and sent to H2 over the LAN.
Packets 2 and 3 follow the same route.

However, something different happened to packet 4. When it got to A it was sent to router B,
even though it is also destined for F. For some reason, A decided to send packet 4 via a different
route than that of the first three. Perhaps it learned of a traffic jam somewhere along the ACE
path and updated its routing table, as shown under the label ''later.'' The algorithm that manages
the tables and makes the routing decisions is called the routing algorithm. Routing algorithms are
one of the main things we will study in this chapter.

5.1.4 Implementation of Connection-Oriented Service

For connection-oriented service, we need a virtual-circuit subnet. Let us see how that works. The
idea behind virtual circuits is to avoid having to choose a new route for every packet sent, as in
Fig. 5-2. Instead, when a connection is established, a route from the source machine to the
destination machine is chosen as part of the connection setup and stored in tables inside the
routers. That route is used for all traffic flowing over the connection, exactly the same way that
the telephone system works. When the connection is released, the virtual circuit is also
terminated. With connection-oriented service, each packet carries an identifier telling which
virtual circuit it belongs to.

As an example, consider the situation of Fig. 5-3. Here, host H1 has established connection 1
with host H2. It is remembered as the first entry in each of the routing tables. The first line of A's
table says that if a packet bearing connection identifier 1 comes in from H1, it is to be sent to
router C and given connection identifier 1. Similarly, the first entry at C routes the packet to E,
also with connection identifier 1.

Figure 5-3. Routing within a virtual-circuit subnet.

Now let us consider what happens if H3 also wants to establish a connection to H2. It chooses
connection identifier 1 (because it is initiating the connection and this is its only connection) and
tells the subnet to establish the virtual circuit. This leads to the second row in the tables. Note
that we have a conflict here because although A can easily distinguish connection 1 packets from
H1 from connection 1 packets from H3, C cannot do this. For this reason, A assigns a different
connection identifier to the outgoing traffic for the second connection. Avoiding conflicts of this
kind is why routers need the ability to replace connection identifiers in outgoing packets. In some
contexts, this is called label switching.

5.1.5 Comparison of Virtual-Circuit and Datagram Subnets

Both virtual circuits and datagrams have their supporters and their detractors. We will now
attempt to summarize the arguments both ways. The major issues are listed in Fig. 5-4, although
purists could probably find a counterexample for everything in the figure.

Figure 5-4. Comparison of datagram and virtual-circuit subnets.

Inside the subnet, several trade-offs exist between virtual circuits and datagrams. One trade-off is
between router memory space and bandwidth. Virtual circuits allow packets to contain circuit
numbers instead of full destination addresses. If the packets tend to be fairly short, a full
destination address in every packet may represent a significant amount of overhead and hence,
wasted bandwidth. The price paid for using virtual circuits internally is the table space within the
routers. Depending upon the relative cost of communication circuits versus router memory, one
or the other may be cheaper.

Another trade-off is setup time versus address parsing time. Using virtual circuits requires a
setup phase, which takes time and consumes resources. However, figuring out what to do with a
data packet in a virtual-circuit subnet is easy: the router just uses the circuit number to index into
a table to find out where the packet goes. In a datagram subnet, a more complicated lookup
procedure is required to locate the entry for the destination.

Yet another issue is the amount of table space required in router memory. A datagram subnet
needs to have an entry for every possible destination, whereas a virtual-circuit subnet just needs
an entry for each virtual circuit. However, this advantage is somewhat illusory since connection
setup packets have to be routed too, and they use destination addresses, the same as datagrams
do.

Virtual circuits have some advantages in guaranteeing quality of service and avoiding congestion
within the subnet because resources (e.g., buffers, bandwidth, and CPU cycles) can be reserved
in advance, when the connection is established. Once the packets start arriving, the necessary
bandwidth and router capacity will be there. With a datagram subnet, congestion avoidance is
more difficult.

For transaction processing systems (e.g., stores calling up to verify credit card purchases), the
overhead required to set up and clear a virtual circuit may easily dwarf the use of the circuit. If
the majority of the traffic is expected to be of this kind, the use of virtual circuits inside the
subnet makes little sense. On the other hand, permanent virtual circuits, which are set up
manually and last for months or years, may be useful here.

Virtual circuits also have a vulnerability problem. If a router crashes and loses its memory, even
if it comes back up a second later, all the virtual circuits passing through it will have to be
aborted. In contrast, if a datagram router goes down, only those users whose packets were
queued in the router at the time will suffer, and maybe not even all those, depending upon
whether they have already been acknowledged. The loss of a communication line is fatal to
virtual circuits using it but can be easily compensated for if datagrams are used. Datagrams also
allow the routers to balance the traffic throughout the subnet, since routes can be changed
partway through a long sequence of packet transmissions.
[ Team LiB ]