Source-Specific Routing in Babel

Source-specific routing is an extension to traditional next-hop where packets are routed according to both their destination and their source address. This document describes extensions to the Babel routing protocol to support source-specific routing. Background information about source-specific routing is provided in .

This extension adds some data to the data structures maintained by a Babel node.

Every Babel node maintains a source table, as described in , Section 3.2.4. A source-specific Babel node extends this table with the following field: the source prefix (sprefix, splen) specifying the source of packets to which this entry applies. If splen is 0, then this is a non-specific entry, and is treated just like a source table entry defined by the original Babel protocol. With this extension the route entry contains a source which itself contains a source prefix. Notwithstanding the accidental similarity in their names, these are two very different concepts, and should not be confused.

Every Babel node maintains a route table, as described in , Section 3.2.5. With this extension, this table is indexed by the 5-tuple (prefix, plen, source prefix, source plen, router-id) obtained from the associated source table entry.

Every Babel node maintains a table of pending requests, as described in , Section 3.2.6. A source-specific Babel node extends this table with the following entry: the source prefix being requested.

In next-hop routing, if two routing table entries overlap, then one is necessarily more specific than the other; the "longest prefix rule" specifies that the most specific applicable routing table entry is chosen. With source-specific routing, there might no longer be a most specific applicable prefix: two routing table entries might match a given packet without one necessarily being more specific than the other. Consider for example the following fragment of a routing table: (2001:DB8:0:1::/64, ::/0, A) (::/0, 2001:DB8:0:2::/64, B) This specifies that all packets with destination in 2001:DB8:0:1::/64 are to be routed through A, while packets with a source in 2001:DB8:0:2::/64 are to be routed through B. A packet with source 2001:DB8:0:2::42 and destination 2001:DB8:0:1::57 matches both rules, although neither is more specific than the other. A choice is necessary, and unless the choice being made is the same on all routers in a routing domain, persistent routing loops may occur. A Babel implementation MUST choose routing table entries by using the so-called destination-first ordering, where a routing table entry R1 is preferred to a routing table entry R2 when either R1's destination prefix is more specific than R2's, or the destination prefixes are equal and R1's source prefix is more specific than R2's. (In more formal terms, routing table entries are compared using the lexicographic product of the destination prefix ordering by the source prefix ordering.) In practice, this means that a source-specific Babel implementation must take care that any lower layers that perform packet forwarding obey this semantics. In particular: If the lower layers implement the destination-first ordering, then the Babel implementation MAY use them directly; If the lower layers can hold source-specific routes, but not with the right semantics, then the Babel implementation MUST disambiguate the routing table by using a suitable disambiguation algorithm (see for such an algorithm). If the lower layers cannot hold source-specific routes, then a Babel implementation SHOULD silently ignore any source-specific routes and MUST NOT reannounce them to other nodes.

This extension does not fundamentally change the operation of the Babel protocol.

This extension introduces a new kind of update, the source-specific update. Whenever a source-specific Babel node needs to send an update, it checks whether the update is for a source-specific route (a route with a source prefix of non-zero length); if that is the case, it sends a source-specific update (), and otherwise it sends a non-specific update (, Section 4.4.9). Every Babel node maintains a source table, which it updates whenever it sends an Update (, Section 3.7.3). A source-specific Babel node extends this procedure by updating the source table not only when it sends an update, but also when it sends a source-specific update.

This extension duplicates Babel's two request types: there are now two kinds of route requests (source-specific and unspecific), and, similarly, two kinds of seqno requests. This extension does not modify Babel's strategy for sending requests. Whenever a Babel node needs to send a request, it checks whether the request is for a source-specific route; if it is, it should send one of the request types defined in this document; if it is not, then it should send one of the request types defined in the original Babel specification.

The Babel protocol provides the ability to request a full routing table dump by sending a "wildcard request", a route request with the AE field set to 0. This extension does not modify the semantics of wildcard requests: a wildcard request prompts a dump of non-specific routes only, and a Babel node SHOULD NOT send any source-specific updates in reply to a wildcard request. A different request is used for obtaining a dump of the source-specific routes in a node's routing table. A "source-specific wildcard request" is a source-specific request () whose AE field is 0; it requests a dump of the receiving nodes source-specific routes only (routes with a source prefix length of 1 or more). A node SHOULD NOT send any non-specific updates in reply to a source-specific wildcard request. In consequence, a node requiring a full routing table dump SHOULD send both a non-specific wildcard request and a source-specific wildcard request.

This extension defines three new TLV types that are used by Source-Specific Babel nodes and silently ignored by ordinary Babel nodes, in accordance with .

Fields: Set to 13 to indicate a source-specific update TLV. The length of the body, exclusive of the Type and Length fields. The encoding of the prefix field. The length of the advertised source prefix. This MUST NOT be 0. The length of the advertised destination prefix. The number of octets that have been omitted at the beginning of the advertised prefix and that should be taken from a preceding Update TLV with the flag with value 80 hexadecimal set. An upper bound, expressed in centiseconds, on the time after which the sending node will send a new update for this prefix. This MUST NOT be 0 and SHOULD NOT be less than 10. The receiving node will use this value to compute a hold time for this routing table entry. The value FFFF hexadecimal (infinity) expresses that this announcement will not be repeated unless a request is received. The originator's sequence number for this update. The sender's metric for this route. The value FFFF hexadecimal (infinity) means that this is a route retraction. The destination prefix being advertised. This field's size is (Plen/8 - Omitted) rounded upwards. The source prefix being advertised. This field's size is (Source Plen)/8 rounded upwards.

Fields: Set to 14 to indicate a Source-Specific Route Request TLV. The length of the body, exclusive of the Type and Length fields. The encoding of the prefix field. The value 0 (wildcard) requests a full dump of all the source-specific routes of the receving node (i.e. those with non-zero source prefix length). The length of the requested destination prefix. The length of the requested source prefix. This MUST NOT be 0, except for AE 0. The destination prefix being requested. This field's size is Plen/8 rounded upwards. The source prefix being advertised. This field's size is (Source Plen)/8 rounded upwards.

Fields: Set to 15 to indicate a Source-Specific Seqno Request TLV. The length of the body, exclusive of the Type and Length fields. The encoding of the prefix field. This MUST NOT be 0. The length of the requested destination prefix. The sequence number that is being requested. The maximum number of times that this TLV may be forwarded, plus 1. This MUST NOT be 0. The length of the requested source prefix. This MUST NOT be 0. The Router-ID associated to this route. The destination prefix being requested. This field's size is Plen/8 rounded upwards. The source prefix being advertised. This field's size is "Source Plen"/8 rounded upwards. A Source-Specific Seqno Request TLV prompts the receiving node to send an Update for the route specified by the AE, Plen, Prefix, Source Plen and Source Prefix fields, with either a router-id different from what is specified by the Router-Id field, or a Seqno no less than what is specified by the Seqno field. If this request cannot be satisfied locally, then it is forwarded according to the rules set out in Section 3.8.1.2 of . Just like an ordinary Seqno Request, a Source-Specific Seqno Request MAY be sent to a multicast address but MUST NOT be forwarded to a multicast address and MUST NOT be forwarded to more than one neighbour. A Source-Specific Seqno Request MUST NOT be forwarded if its Hop Count field is 1.

This document defines three new Babel TLV types:

By itself, the Babel routing protocol is not a secure protocol; this extension doesn't change that fact. Babel can be made secure by using a suitable cryptographic layer, such as the one described in .