Forwarding Algorithm

Since none of the primary protocol documents describe the

forwarding algorithm in any detail, we present it here. This is just a general outline, and omits important details, such as handling of congestion, that are dealt with in later sections.

It is not required that an implementation follow exactly the algorithms given in sections [5.2.1.1], [5.2.1.2], and [5.2.1.3].

Much of the challenge of writing router software is to maximize the rate at which the router can forward packets while still achieving the same effect of the algorithm. Details of how to do that are beyond the scope of this document, in part because they are heavily dependent on the architecture of the router. Instead, we merely point out the order dependencies among the steps:

(1) A router MUST verify the IP header, as described in section [5.2.2], before performing any actions based on the contents of the header. This allows the router to detect and discard bad packets before the expenditure of other resources.

(2) Processing of certain IP options requires that the router insert its IP address into the option. As noted in Section [5.2.4], the address inserted MUST be the address of the logical interface on which the packet is sent or the router’s router-id if the packet is sent over an unnumbered interface.

Thus, processing of these options cannot be completed until after the output interface is chosen.

(3) The router cannot check and decrement the TTL before checking whether the packet should be delivered to the router itself, for reasons mentioned in Section [4.2.2.9].

(4) More generally, when a packet is delivered locally to the router, its IP header MUST NOT be modified in any way (except that a router may be required to insert a timestamp into any Timestamp options in the IP header). Thus, before the router determines whether the packet is to be delivered locally to the router, it cannot update the IP header in any way that it is not prepared to undo.

5.2.1.1 General

This section covers the general forwarding algorithm. This algorithm applies to all forms of packets to be forwarded:

unicast, multicast, and broadcast.

(1) The router receives the IP packet (plus additional

information about it, as described in Section [3.1]) from the Link Layer.

(2) The router validates the IP header, as described in Section [5.2.2]. Note that IP reassembly is not done, except on IP fragments to be queued for local delivery in step (4).

(3) The router performs most of the processing of any IP

options. As described in Section [5.2.4], some IP options require additional processing after the routing decision has been made.

(4) The router examines the destination IP address of the IP datagram, as described in Section [5.2.3], to determine how it should continue to process the IP datagram. There are three possibilities:

o The IP datagram is destined for the router, and should be queued for local delivery, doing reassembly if needed.

o The IP datagram is not destined for the router, and should be queued for forwarding.

o The IP datagram should be queued for forwarding, but (a copy) must also be queued for local delivery.

5.2.1.2 Unicast

Since the local delivery case is well-covered by [INTRO:2], the following assumes that the IP datagram was queued for

forwarding. If the destination is an IP unicast address:

(5) The forwarder determines the next hop IP address for the packet, usually by looking up the packet’s destination in the router’s routing table. This procedure is described in more detail in Section [5.2.4]. This procedure also decides which network interface should be used to send the packet.

(6) The forwarder verifies that forwarding the packet is

permitted. The source and destination addresses should be valid, as described in Section [5.3.7] and Section [5.3.4]

If the router supports administrative constraints on forwarding, such as those described in Section [5.3.9], those constraints must be satisfied.

(7) The forwarder decrements (by at least one) and checks the packet’s TTL, as described in Section [5.3.1].

(8) The forwarder performs any IP option processing that could not be completed in step 3.

(9) The forwarder performs any necessary IP fragmentation, as described in Section [4.2.2.7]. Since this step occurs after outbound interface selection (step 5), all fragments of the same datagram will be transmitted out the same interface.

(10) The forwarder determines the Link Layer address of the packet’s next hop. The mechanisms for doing this are Link Layer-dependent (see chapter 3).

(11) The forwarder encapsulates the IP datagram (or each of the fragments thereof) in an appropriate Link Layer frame and queues it for output on the interface selected in step 5.

(12) The forwarder sends an ICMP redirect if necessary, as described in Section [4.3.3.2].

5.2.1.3 Multicast

If the destination is an IP multicast, the following steps are taken.

Note that the main differences between the forwarding of IP unicasts and the forwarding of IP multicasts are

o IP multicasts are usually forwarded based on both the datagram’s source and destination IP addresses,

o IP multicast uses an expanding ring search,

o IP multicasts are forwarded as Link Level multicasts, and o ICMP errors are never sent in response to IP multicast datagrams.

Note that the forwarding of IP multicasts is still somewhat experimental. As a result, the algorithm presented below is not mandatory, and is provided as an example only.

(5a) Based on the IP source and destination addresses found in the datagram header, the router determines whether the datagram has been received on the proper interface for forwarding. If not, the datagram is dropped silently. The method for determining the proper receiving interface depends on the multicast routing algorithm(s) in use. In one of the simplest algorithms, reverse path forwarding (RPF), the proper interface is the one that would be used to forward unicasts back to the datagram source.

(6a) Based on the IP source and destination addresses found in the datagram header, the router determines the datagram’s outgoing interfaces. In order to implement IP multicast’s expanding ring search (see [INTERNET:4]) a minimum TTL value is specified for each outgoing interface. A copy of the multicast datagram is forwarded out each outgoing interface whose minimum TTL value is less than or equal to the TTL value in the datagram header, by separately

applying the remaining steps on each such interface.

(7a) The router decrements the packet’s TTL by one.

(8a) The forwarder performs any IP option processing that could not be completed in step (3).

(9a) The forwarder performs any necessary IP fragmentation, as described in Section [4.2.2.7].

(10a) The forwarder determines the Link Layer address to use in the Link Level encapsulation. The mechanisms for doing this are Link Layer-dependent. On LANs a Link Level multicast or broadcast is selected, as an algorithmic translation of the datagrams’ class D destination address.

See the various IP-over-xxx specifications for more details.

(11a) The forwarder encapsulates the packet (or each of the fragments thereof) in an appropriate Link Layer frame and queues it for output on the appropriate interface.