Internet Packet Forwarding

As we have seen in Chapter 1, it was the desire of the designers of the Internet to keep the router’s routing and forwarding databases small. This was origi-nally done by not requiring the routers to keep track of all individual nodes of the network, but by grouping them in networks of different size. Each router outside a given network only had to know about how to forward packets to these networks, where routers with knowledge about the internal topology would make sure the packet reached its final destination. Two additional goals were also set up and met by the original designers:

1. To provide for several sizes of networks, as to closely fit the needs of the organizations connected to the Internet.

2. To simplify the extraction of the part of the address that named the des-tination network.

The first goal was met by designing the network sizes so that the individual networks could contain up to 254, 65534, or 16 million hosts, named Class C, B, and A, respectively. The second goal was met by having the first few bits of the address indicate the length of the network part. This resulted in 126 Class A networks, 16382 Class B networks, and 2 million Class C networks, leaving one eighth of the address space for future wild ideas (Table 2.5).

To achieve maximum routing table space reduction, aggregation is done aggressively: Suppose all the subnets in a big network have identical routing information except for a single, small subnet with different information. In-stead of having multiple routing entries for each subnet in the large network, just two entries are needed: one for the overall network, and one entry show-ing the exception for the small subnet. Now there are two matches for packets addressed to the exceptional subnet. Clearly, the exception entry should get preference there. This is achieved by preferring the more specific entry, re-sulting in a Best Matching Prefix (BMP) operation. In summary, CIDR traded

Class First Bits # of Networks # of Hosts per Network

A 0 126 16777214

B 10 16382 65534

C 110 2097150 254

D^a 1110 — —

E^b 1111 — —

aOriginally unassigned, later used for Multicast [DC90]

bUnassigned

Table 2.5: Classful Internet Addressing (Outdated)

off better usage of the limited IP address space and a reduction in routing information for a more complex lookup scheme.

Today, an IP router’s database consists of a number of address prefixes. A prefix is a specific pattern, which represents a bit sequence consisting of two distinct areas. One area consists of bits with an exactly defined value (chosen from either 0 or 1), which makes up the most significant bits (“left-aligned”).

The other area consists of all don’t-care bits and is “right-aligned”. Either of the areas may be empty, but the sum of the lengths of the two areas must equal the length of the address they should be compared with. The prefix length is defined as the number of non-wildcard bits.

When an IP router receives a packet, it must compute which of the prefixes in its database has the longest match when compared to the destination address in the packet. The packet is then forwarded to the output link associated with that prefix, directed to the next router or the destination host. For example, a forwarding database may have the prefixes P₁ = 0000∗, P₂ = 0000 111∗ and P₃ = 0000 1111 0000∗, with ∗ meaning all further bits are unspecified and being used to visually group the bits. An address whose first 12 bits are 0000 0110 1111 has longest matching prefix P₁. On the other hand, an address whose first 12 bits are0000 1111 0000matches all three prefixes, but its longest matching prefix is P₃. For one-dimensional prefix databases, if it contains a match at all, there is always a single distinct prefix in this database having the longest prefix length associated with it.

Current backbone routers have to deal with forwarding databases contain-ing up to 40,000 prefixes. Several millions of packets per second have to be compared against this database for each network link. Today (June 1999), the biggest routers contain a dozen OC-192 (9.6Gb/s) links, corresponding to

2.2. The Problems 13 more than 300 million minimum-sized packets passing through the router each second. The forwarding databases, the link speeds, and the link counts are still growing, with the number of packets per link doubling every few months. Cur-rent Internet (IPv4) addresses are 32 bits long, with 128 bits upcoming (IPv6 [DH98]) to relieve the current IP address scarcity and allow for further growth.

Besides the forwarding decision, routers have to perform other tasks when forwarding a packet [Bak95]:

Checksum verification The standard makes it a requirement to check the header checksum of any IPv4 packet before performing looking at any other field. But hardly any router verifies the checksum, because the checksum calculation is considered to be too expensive, despite the speed optimizations possible to the na¨ıve algorithm [BBP88]. Check-summing is omitted under the assumption that (1) packets hardly ever get corrupted in transit with current technology, especially fiber-optics, and (2) end systems (hosts) will recognize the corruption. IP version 6 [DH98] therefore no longer has an IP header checksum, the relevant header fields (source and destination address) are only checked by in-clusion into the transport protocol checksum (already the IPv4 transport protocols include the IP addresses into their checksum).

Fragmentation A packet may need to be fragmented, because the outbound link cannot handle the size of the packet. This is very unusual for high-speed links, since they are designed to handle large enough packets.

Time-to-Live The Time-to-Live (TTL) field is used to detect packets looping in the network. A host sending a packet typically initializes the TTL with 64 (recommended by [RP94]) or 255 (the maximum). Each router then decrements it. The packet is discarded and an error message gen-erated when the TTL reaches zero before reaching the destination.

Checksum update Since a header field—the TTL—was changed, the check-sum needs to be recalculated. [MK90] describes how to efficiently do this incrementally, if only the TTL was decremented. Using incremen-tal updates also allows end systems to recognize corrupted headers and does not run the risk that routers unknowingly overwrite the unchecked bad checksum with a good one.

Although there are a lot of chores to be performed, in almost all cases, they are reduced to decrementing and checking the TTL and incrementally updating

the checksum. These two operations combined are much cheaper than making a forwarding decision.