Forwarding information base

A Forwarding Information Base (FIB), also known as a forwarding table, is most commonly used in network bridging, routing, and similar functions to find the proper interface to which the input interface should send a packet to be transmitted by the router.

In contrast to Routing Information Bases (RIB), also known as routing tables, FIBs are optimized for fast lookup of destination addresses. Earlier implementations cached only a subset of the routes most frequently used in actual forwarding, and this worked reasonably well for enterprises where there is a meaningful most-frequently-used subset. Routers used for accessing the entire Internet, however, experienced severe performance degradation in refreshing a small cache, and various implementations moved to having FIBs in one-to-one correspondence with the RIB . RIBs are optimized for efficient updating by routing protocols and other Control Plane methods, and contain the full set of routes learned by the router.

FIBs may also be implemented with fast hardware lookup mechanisms, such as Ternary Content Addressable Memory (TCAM). TCAM, however, is quite expensive, and tends to be used more in edge routers with relatively small numbers of routes than in routers that must carry full Internet routing tables, with supplementary internal routes .

Applications for Data Link and other Link-Local Technologies

A link-local technology, such as Medium Access Control (MAC) protocols on local area networks, has an address that has no significance beyond a single medium. In contrast, network layer addresses, such as IP, are conceptually similar on all media in the routing domain.

Besides IEEE 802.1 bridging of MAC layer addresses, other link-local technologies using forwarding tables include Frame Relay and Asynchronous Transfer Mode switches, and Multiprotocol Label Switching. ATM has both link-local addresses and addresses that have end-to-end significance in the ATM domain.

Bridging

MAC layer bridges learn the interface on which they first saw a particular source address, and associate that interface with that address. When the bridge subsequently receives a frame with a destination address in its forwarding table, it sends the frame out the interface stored in the forwarding table.

If the bridge has not seen the address yet, it floods it out all active interfaces, except received interface. As is also done with broadcast frames.

Frame Relay

While the exact mechanics of a forwarding table is implementation-specific, the general model is that Frame Relay switches have statically defined forwarding tables, one per interface. When a frame with a given Data Link Connection Identifier (DLCI) is received on one interface, the table associated with that interface gives the outgoing interface, and the new DLCI to insert into the frame's address field.

Asynchronous Transfer Mode

ATM switches have link-level forwarding tables much like those used in Frame Relay. Rather than a DLCI, however, interfaces have forwarding tables that specify the outgoing interface, Virtual Path Identifier, and Virtual Circuit Identifier. These tables may be configured statically, or they can be distributed by the Private Network-to-Network Interface (PNNI) protocol, an ATM routing protocol with considerable similarity to the Open Shortest Path First (OSPF) used for IP routing.

When PNNI is in use, the ATM switches at the edges of the ATM "cloud" will map one of the standard ATM end-to-end identifiers, such as an NSAP, to the next-hop VPI/VCI.

Multiprotocol Label Switching

MPLS, which has been called "ATM without cells", has many similarities, at the forwarding level, to ATM. The Label Edge Routers (LSR) at the edges of an MPLS cloud map between the end-to-end identifier, such as an IP address, and a link-local label.

At each MPLS hop, there is a forwarding table that tells the Label Switched Router (LSR) which outgoing interface is to receive the MPLS packet, and what label to use when sending the packet out that interface.

Applications in Network Layer Routing

Forwarding information base design

Originally, all destinations were looked up in the RIB. Perhaps the first step in speeding routers was to have a separate RIB and FIB in main memory, with the FIB, typically with fewer entries than the RIB, being organized for fast destination lookup. In contrast, the RIB was optimized for efficient updating by routing protocols.

Early uniprocessing routers usually organized the FIB as a hash table, while the RIB might be a linked list. Depending on the implementation, the FIB might have fewer entries than the RIB, or the same number.

When routers started to have separate forwarding processors, these processors usually had far less memory than the main processor, such that the forwarding processor could hold only the most frequently used routes. On the early Cisco AGS+ and 7000, for example, the forwarding processor cache could hold approximately 1000 route entries. In an enterprise, this would often work quite well, because there were fewer than 1000 server or other popular destination subnets. Such a cache, however, was far too small for general Internet routing. Different router designs behaved in different ways when a destination was not in the cache.

Cache miss issues

A cache miss condition might result in the packet being sent back to the main processor, to be looked up in a slow path that had access to the full routing table. Depending on the router design, a cache miss might cause an update to the fast hardware cache or the fast cache in main memory. In some designs, it was most efficient to invalidate the fast cache for a cache miss, send the packet that caused the cache miss through the main processor, and then repopulate the cache with a new table that included the destination that caused the miss. This approach is similar to an operating system with virtual memory, which keeps the most recently used information in hardware memory.

As memory costs went down and performance needs went up, FIBs emerged that had the same number of route entries as in the RIB, but arranged for fast lookup rather than fast update. Whenever a RIB entry changed, the router changed the corresponding FIB entry.

FIB design alternatives

High-performance FIBs achieve their speed with implementation-specific combinations of specialized algorithms and hardware.

Software

Various search algorithms have been used for FIB lookup. While well-known general-purpose data structures were first used, such as hash tables, specialized algorithms, optimized for IP addresses, emerged. They include:

• Binary trie
• Radix tree
• Four-way trie
• Patricia tree

Hardware

Various forms of fast RAM and, eventually, basic content addressable memory (CAM) were used to speed lookup. CAM, while useful in layer 2 switches that needed to look up a relatively small number of fixed-length MAC addresses, had limited utility with IP addresses having variable-length routing prefixes (see Classless Inter-Domain Routing). Ternary CAM (CAM), while expensive, lends itself to variable-length prefix lookups .

One of the challenges of forwarder lookup design is to minimize the amount of specialized memory needed, and, increasingly, to minimize the power consumed by memory.

FIBs in Ingress Filtering against Denial of Service

FIBs can also play a role in an Internet Best Current Practice of ingress filtering. Though the simplest form of implementing ingress filtering is to use access lists to drop packets with improper source addresses, use of access lists becomes difficult on routers with a large number of adjacent networks, and traditional access lists are not used in high performance router forwarding paths.

While the IETF document BCP 38 on ingress filtering does not specify a method of implementing source address filtering, some router vendors have implemented a mechanism which employs lookups in the router's tables to perform this check. This is often implemented as a lookup in the FIB of the source address of the packet. If the interface has no route to the source address, the packet is assumed to be part of a denial of service attack, using a false or spoofed source address, and the router discards the packet.

When the router is multihomed, ingress filtering becomes more complex. There are perfectly reasonable operational scenarios in which a packet could arrive on one interface, but that specific interface might not have a route to the source address. For the routers near the edge of the Internet, packet filters are conceptually simpler, than methods which employ routing information lookup, though packet filtering requires more maintenance than unicast reverse path filtering. Ingress filtering for multihomed routers will accept the packet if there is a route back to its source address from any interface on the router. For this type of filtering, the router may also maintain an adjacency table, also organized for fast lookup, that keeps track of the router interface addresses that are on all directly connected routers.

FIBs in Differentiated Services/Quality of Service Routing

IP Differentiated Services provides an additional method to select outgoing interfaces, based on a field that indicates the forwarding priority of the packet, as well as the preference of the packet to be dropped in the presence of congestion.

Routers that support differentiated service not only have to look up the output interface for the destination address, but need to send the packet to the interface that best matches the Differentiated Services requirements. In other words, as well as matching the destination address, the FIB has to match Differentiated Services Code Points (DSCP).

FIB Information for Additional Processing

Specific router implementations may, when a destination address or other FIB criterion is matched, specify other action to be done before forwarding (e.g., accounting or encryption), or applying an access control list that may cause the packet to be dropped.