draft-ietf-babel-rfc6126bis-01.txt   draft-ietf-babel-rfc6126bis-02.txt 
Network Working Group J. Chroboczek Network Working Group J. Chroboczek
Internet-Draft IRIF, University of Paris-Diderot Internet-Draft IRIF, University of Paris-Diderot
Intended status: Standards Track January 31, 2017 Intended status: Standards Track May 24, 2017
Expires: August 4, 2017 Expires: November 25, 2017
The Babel Routing Protocol The Babel Routing Protocol
draft-ietf-babel-rfc6126bis-01 draft-ietf-babel-rfc6126bis-02
Abstract Abstract
Babel is a loop-avoiding distance-vector routing protocol that is Babel is a loop-avoiding distance-vector routing protocol that is
robust and efficient both in ordinary wired networks and in wireless robust and efficient both in ordinary wired networks and in wireless
mesh networks. mesh networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 4, 2017. This Internet-Draft will expire on November 25, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
2. Conceptual Description of the Protocol . . . . . . . . . . . 4 2. Conceptual Description of the Protocol . . . . . . . . . . . 4
2.1. Costs, Metrics and Neighbourship . . . . . . . . . . . . 5 2.1. Costs, Metrics and Neighbourship . . . . . . . . . . . . 5
2.2. The Bellman-Ford Algorithm . . . . . . . . . . . . . . . 5 2.2. The Bellman-Ford Algorithm . . . . . . . . . . . . . . . 5
2.3. Transient Loops in Bellman-Ford . . . . . . . . . . . . . 6 2.3. Transient Loops in Bellman-Ford . . . . . . . . . . . . . 6
2.4. Feasibility Conditions . . . . . . . . . . . . . . . . . 6 2.4. Feasibility Conditions . . . . . . . . . . . . . . . . . 6
2.5. Solving Starvation: Sequencing Routes . . . . . . . . . . 8 2.5. Solving Starvation: Sequencing Routes . . . . . . . . . . 8
2.6. Requests . . . . . . . . . . . . . . . . . . . . . . . . 9 2.6. Requests . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7. Multiple Routers . . . . . . . . . . . . . . . . . . . . 10 2.7. Multiple Routers . . . . . . . . . . . . . . . . . . . . 10
2.8. Overlapping Prefixes . . . . . . . . . . . . . . . . . . 11 2.8. Overlapping Prefixes . . . . . . . . . . . . . . . . . . 11
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 11 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 11
3.1. Message Transmission and Reception . . . . . . . . . . . 11 3.1. Message Transmission and Reception . . . . . . . . . . . 12
3.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 12 3.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 12
3.3. Acknowledged Packets . . . . . . . . . . . . . . . . . . 15 3.3. Acknowledged Packets . . . . . . . . . . . . . . . . . . 16
3.4. Neighbour Acquisition . . . . . . . . . . . . . . . . . . 15 3.4. Neighbour Acquisition . . . . . . . . . . . . . . . . . . 16
3.5. Routing Table Maintenance . . . . . . . . . . . . . . . . 17 3.5. Routing Table Maintenance . . . . . . . . . . . . . . . . 18
3.6. Route Selection . . . . . . . . . . . . . . . . . . . . . 21 3.6. Route Selection . . . . . . . . . . . . . . . . . . . . . 22
3.7. Sending Updates . . . . . . . . . . . . . . . . . . . . . 22 3.7. Sending Updates . . . . . . . . . . . . . . . . . . . . . 23
3.8. Explicit Route Requests . . . . . . . . . . . . . . . . . 24 3.8. Explicit Route Requests . . . . . . . . . . . . . . . . . 25
4. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 27 4. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 29
4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 28 4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 29
4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 29 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 30
4.3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 29 4.3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 31
4.4. Details of Specific TLVs . . . . . . . . . . . . . . . . 30 4.4. Sub-TLV Format . . . . . . . . . . . . . . . . . . . . . 31
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 4.5. Parser state . . . . . . . . . . . . . . . . . . . . . . 32
6. Security Considerations . . . . . . . . . . . . . . . . . . . 39 4.6. Details of Specific TLVs . . . . . . . . . . . . . . . . 33
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.7. Details of specific sub-TLVs . . . . . . . . . . . . . . 43
7.1. Normative References . . . . . . . . . . . . . . . . . . 40 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
7.2. Informative References . . . . . . . . . . . . . . . . . 40 6. Security Considerations . . . . . . . . . . . . . . . . . . . 44
Appendix A. Cost and Metric Computation . . . . . . . . . . . . 41 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.1. Maintaining Hello History . . . . . . . . . . . . . . . . 41 7.1. Normative References . . . . . . . . . . . . . . . . . . 44
A.2. Cost Computation . . . . . . . . . . . . . . . . . . . . 42 7.2. Informative References . . . . . . . . . . . . . . . . . 44
A.3. Metric Computation . . . . . . . . . . . . . . . . . . . 43 Appendix A. Cost and Metric Computation . . . . . . . . . . . . 45
Appendix B. Constants . . . . . . . . . . . . . . . . . . . . . 43 A.1. Maintaining Hello History . . . . . . . . . . . . . . . . 45
Appendix C. Simplified Implementations . . . . . . . . . . . . . 44 A.2. Cost Computation . . . . . . . . . . . . . . . . . . . . 46
Appendix D. Software Availability . . . . . . . . . . . . . . . 45 A.3. Metric Computation . . . . . . . . . . . . . . . . . . . 47
Appendix E. Changes from previous versions . . . . . . . . . . . 45 Appendix B. Constants . . . . . . . . . . . . . . . . . . . . . 48
E.1. Changes since RFC 6126 . . . . . . . . . . . . . . . . . 45 Appendix C. Considerations for protocol extensions . . . . . . . 49
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 45 Appendix D. Simplified Implementations . . . . . . . . . . . . . 50
Appendix E. Software Availability . . . . . . . . . . . . . . . 50
Appendix F. Changes from previous versions . . . . . . . . . . . 51
F.1. Changes since RFC 6126 . . . . . . . . . . . . . . . . . 51
F.2. Changes since draft-ietf-babel-rfc6126bis-00 . . . . . . 51
F.3. Changes since draft-ietf-babel-rfc6126bis-01 . . . . . . 51
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
Babel is a loop-avoiding distance-vector routing protocol that is Babel is a loop-avoiding distance-vector routing protocol that is
designed to be robust and efficient both in networks using prefix- designed to be robust and efficient both in networks using prefix-
based routing and in networks using flat routing ("mesh networks"), based routing and in networks using flat routing ("mesh networks"),
and both in relatively stable wired networks and in highly dynamic and both in relatively stable wired networks and in highly dynamic
wireless networks. wireless networks.
1.1. Features 1.1. Features
skipping to change at page 11, line 50 skipping to change at page 12, line 8
Every Babel speaker is assigned a router-id, which is an arbitrary Every Babel speaker is assigned a router-id, which is an arbitrary
string of 8 octets that is assumed unique across the routing domain. string of 8 octets that is assumed unique across the routing domain.
We suggest that router-ids should be assigned in modified EUI-64 We suggest that router-ids should be assigned in modified EUI-64
format [ADDRARCH]. (As a matter of fact, the protocol encoding is format [ADDRARCH]. (As a matter of fact, the protocol encoding is
slightly more compact when router-ids are assigned in the same manner slightly more compact when router-ids are assigned in the same manner
as the IPv6 layer assigns host IDs.) as the IPv6 layer assigns host IDs.)
3.1. Message Transmission and Reception 3.1. Message Transmission and Reception
Babel protocol packets are sent in the body of a UDP datagram. Each Babel protocol packets are sent in the body of a UDP datagram. Each
Babel packet consists of one or more TLVs. Babel packet consists of zero or more TLVs. Most TLVs may contain
sub-TLVs.
The source address of a Babel packet is always a unicast address, The source address of a Babel packet is always a unicast address,
link-local in the case of IPv6. Babel packets may be sent to a well- link-local in the case of IPv6. Babel packets may be sent to a well-
known (link-local) multicast address (this is the usual case) or to a known (link-local) multicast address (this is the usual case) or to a
(link-local) unicast address. In normal operation, a Babel speaker (link-local) unicast address. In normal operation, a Babel speaker
sends both multicast and unicast packets to its neighbours. sends both multicast and unicast packets to its neighbours.
With the exception of Hello TLVs and acknowledgements, all Babel TLVs With the exception of Hello TLVs and acknowledgements, all Babel TLVs
can be sent to either unicast or multicast addresses, and their can be sent to either unicast or multicast addresses, and their
semantics does not depend on whether the destination was a unicast or semantics does not depend on whether the destination was a unicast or
skipping to change at page 12, line 34 skipping to change at page 12, line 40
The exact delay and amount of jitter applied to a packet depends on The exact delay and amount of jitter applied to a packet depends on
whether it contains any urgent TLVs. Acknowledgement TLVs MUST be whether it contains any urgent TLVs. Acknowledgement TLVs MUST be
sent before the deadline specified in the corresponding request. The sent before the deadline specified in the corresponding request. The
particular class of updates specified in Section 3.7.2 MUST be sent particular class of updates specified in Section 3.7.2 MUST be sent
in a timely manner. The particular class of request and update TLVs in a timely manner. The particular class of request and update TLVs
specified in Section 3.8.2 SHOULD be sent in a timely manner. specified in Section 3.8.2 SHOULD be sent in a timely manner.
3.2. Data Structures 3.2. Data Structures
Every Babel speaker maintains a number of data structures. Every Babel speaker maintains a number of data structures. All of
these data structures consist of familiar data types -- integers, IP
addresses, etc. -- with the exception of sequence numbers.
3.2.1. Sequence Number 3.2.1. Sequence number arithmetic
Sequence numbers (seqnos) appear in a number of Babel data
structures, and they are interpreted as integers modulo 2^16. For
the purposes of this document, arithmetic on serial numbers is
defined as follows.
Given a seqno s and an integer n, the sum of s and n is defined by
s + n (modulo 2^16) = (s + n) MOD 2^16
or, equivalently,
s + n (modulo 2^16) = (s + n) AND 65535
where MOD is the modulo operation yielding a non-negative integer and
AND is the bitwise conjunction operation.
Given two sequence numbers s and s', the relation s is less than s'
(s < s') is defined by
s < s' (modulo 2^16) when 0 < ((s' - s) MOD 2^16) < 32768
or equivalently
s < s' (modulo 2^16) when s /= s' and ((s' - s) AND 32768) = 0.
3.2.2. Node Sequence Number
A node's sequence number is a 16-bit integer that is included in A node's sequence number is a 16-bit integer that is included in
route updates sent for routes originated by this node. A node route updates sent for routes originated by this node.
increments its sequence number (modulo 2^16) whenever it receives a
request for a new sequence number (Section 3.8.1.2).
A node SHOULD NOT increment its sequence number (seqno) A node increments its sequence number (modulo 2^16) whenever it
spontaneously, since increasing seqnos makes it less likely that receives a request for a new sequence number (Section 3.8.1.2). A
other nodes will have feasible alternate routes when their selected node SHOULD NOT increment its sequence number (seqno) spontaneously,
routes fail. since increasing seqnos makes it less likely that other nodes will
have feasible alternate routes when their selected routes fail.
3.2.2. The Interface Table 3.2.3. The Interface Table
The interface table contains the list of interfaces on which the node The interface table contains the list of interfaces on which the node
speaks the Babel protocol. Every interface table entry contains the speaks the Babel protocol. Every interface table entry contains the
interface's Hello seqno, a 16-bit integer that is sent with each interface's Hello seqno, a 16-bit integer that is sent with each
Hello TLV on this interface and is incremented (modulo 2^16) whenever Hello TLV on this interface and is incremented (modulo 2^16) whenever
a Hello is sent. (Note that an interface's Hello seqno is unrelated a Hello is sent. (Note that an interface's Hello seqno is unrelated
to the node's seqno.) to the node's seqno.)
There are two timers associated with each interface table entry -- There are two timers associated with each interface table entry --
the Hello timer, which governs the sending of periodic Hello and IHU the Hello timer, which governs the sending of periodic Hello and IHU
packets, and the update timer, which governs the sending of periodic packets, and the update timer, which governs the sending of periodic
route updates. route updates.
3.2.3. The Neighbour Table 3.2.4. The Neighbour Table
The neighbour table contains the list of all neighbouring interfaces The neighbour table contains the list of all neighbouring interfaces
from which a Babel packet has been recently received. The neighbour from which a Babel packet has been recently received. The neighbour
table is indexed by pairs of the form (interface, address), and every table is indexed by pairs of the form (interface, address), and every
neighbour table entry contains the following data: neighbour table entry contains the following data:
o the local node's interface over which this neighbour is reachable; o the local node's interface over which this neighbour is reachable;
o the address of the neighbouring interface; o the address of the neighbouring interface;
skipping to change at page 13, line 47 skipping to change at page 14, line 34
hello timer, which is initialised from the interval value carried by hello timer, which is initialised from the interval value carried by
Hello TLVs, and the IHU timer, which is initialised to a small Hello TLVs, and the IHU timer, which is initialised to a small
multiple of the interval carried in IHU TLVs. multiple of the interval carried in IHU TLVs.
Note that the neighbour table is indexed by IP addresses, not by Note that the neighbour table is indexed by IP addresses, not by
router-ids: neighbourship is a relationship between interfaces, not router-ids: neighbourship is a relationship between interfaces, not
between nodes. Therefore, two nodes with multiple interfaces can between nodes. Therefore, two nodes with multiple interfaces can
participate in multiple neighbourship relationships, a fairly common participate in multiple neighbourship relationships, a fairly common
situation when wireless nodes with multiple radios are involved. situation when wireless nodes with multiple radios are involved.
3.2.4. The Source Table 3.2.5. The Source Table
The source table is used to record feasibility distances. It is The source table is used to record feasibility distances. It is
indexed by triples of the form (prefix, plen, router-id), and every indexed by triples of the form (prefix, plen, router-id), and every
source table entry contains the following data: source table entry contains the following data:
o the prefix (prefix, plen), where plen is the prefix length, that o the prefix (prefix, plen), where plen is the prefix length, that
this entry applies to; this entry applies to;
o the router-id of a router originating this prefix; o the router-id of a router originating this prefix;
o a pair (seqno, metric), this source's feasibility distance. o a pair (seqno, metric), this source's feasibility distance.
There is one timer associated with each entry in the source table -- There is one timer associated with each entry in the source table --
the source garbage-collection timer. It is initialised to a time on the source garbage-collection timer. It is initialised to a time on
the order of minutes and reset as specified in Section 3.7.3. the order of minutes and reset as specified in Section 3.7.3.
3.2.5. The Route Table 3.2.6. The Route Table
The route table contains the routes known to this node. It is The route table contains the routes known to this node. It is
indexed by triples of the form (prefix, plen, neighbour), and every indexed by triples of the form (prefix, plen, neighbour), and every
route table entry contains the following data: route table entry contains the following data:
o the source (prefix, plen, router-id) for which this route is o the source (prefix, plen, router-id) for which this route is
advertised; advertised;
o the neighbour that advertised this route; o the neighbour that advertised this route;
skipping to change at page 14, line 42 skipping to change at page 15, line 31
o the next-hop address of this route; o the next-hop address of this route;
o a boolean flag indicating whether this route is selected, i.e., o a boolean flag indicating whether this route is selected, i.e.,
whether it is currently being used for forwarding and is being whether it is currently being used for forwarding and is being
advertised. advertised.
There is one timer associated with each route table entry -- the There is one timer associated with each route table entry -- the
route expiry timer. It is initialised and reset as specified in route expiry timer. It is initialised and reset as specified in
Section 3.5.4. Section 3.5.4.
3.2.6. The Table of Pending Requests Of course, the data structure described above is conceptual: actual
implementations will likely use a different data structure, for
example a table of installed routes and a set of redundant ones, or
some more complicated data structure.
3.2.7. The Table of Pending Requests
The table of pending requests contains a list of seqno requests that The table of pending requests contains a list of seqno requests that
the local node has sent (either because they have been originated the local node has sent (either because they have been originated
locally, or because they were forwarded) and to which no reply has locally, or because they were forwarded) and to which no reply has
been received yet. This table is indexed by prefixes, and every been received yet. This table is indexed by prefixes, and every
entry in this table contains the following data: entry in this table contains the following data:
o the prefix, router-id, and seqno being requested; o the prefix, router-id, and seqno being requested;
o the neighbour, if any, on behalf of which we are forwarding this o the neighbour, if any, on behalf of which we are forwarding this
request; request;
o a small integer indicating the number of times that this request o a small integer indicating the number of times that this request
will be resent if it remains unsatisfied. will be resent if it remains unsatisfied.
There is one timer associated with each pending request; it governs There is one timer associated with each pending request; it governs
both the resending of requests and their expiry. both the resending of requests and their expiry.
3.3. Acknowledged Packets 3.3. Acknowledged Packets
skipping to change at page 15, line 43 skipping to change at page 16, line 38
acknowledgement requests is not necessary, and not even recommended, acknowledgement requests is not necessary, and not even recommended,
as the acknowledgements cause additional traffic and may force as the acknowledgements cause additional traffic and may force
additional Address Resolution Protocol (ARP) or Neighbour Discovery additional Address Resolution Protocol (ARP) or Neighbour Discovery
exchanges. exchanges.
3.4. Neighbour Acquisition 3.4. Neighbour Acquisition
Neighbour acquisition is the process by which a Babel node discovers Neighbour acquisition is the process by which a Babel node discovers
the set of neighbours heard over each of its interfaces and the set of neighbours heard over each of its interfaces and
ascertains bidirectional reachability. On unreliable media, ascertains bidirectional reachability. On unreliable media,
neighbour acquisition additionally provides some statistics that MAY neighbour acquisition additionally provides some statistics that may
be used in link quality computation. be useful for link quality computation.
Before it can exchange routing information with a neighbour, a Babel
node MUST create an entry for that neighbour in the neighbour table.
When to do that is an implementation detail; suitable strategies
include creating an entry when any Babel packet is received, or
creating an entry when a Hello TLV is parsed. Similarly, in order to
conserve system resources, an implementation SHOULD discard an entry
when it has been unused for long enough; suitable strategies include
dropping the neighbour after a timeout, and dropping a neighbour when
the associated Hello history becomes empty (see Appendix A.2).
3.4.1. Reverse Reachability Detection 3.4.1. Reverse Reachability Detection
Every Babel node sends periodic Hellos over each of its interfaces. Every Babel node sends periodic Hellos over each of its interfaces.
Each Hello TLV carries an increasing (modulo 2^16) sequence number Each Hello TLV carries an increasing (modulo 2^16) sequence number
and the interval between successive periodic packets sent on this and the interval between successive periodic packets sent on this
particular interface. particular interface.
In addition to the periodic Hello packets, a node MAY send In addition to the periodic Hello packets, a node MAY send
unscheduled Hello packets, e.g., to accelerate link cost estimation unscheduled Hello packets, e.g., to accelerate link cost estimation
skipping to change at page 20, line 10 skipping to change at page 21, line 17
Additionally, a prefix of the advertised prefix can be omitted in an Additionally, a prefix of the advertised prefix can be omitted in an
Update TLV, in which case it is copied from a previous Update TLV in Update TLV, in which case it is copied from a previous Update TLV in
the same packet -- this is known as address compression [PACKETBB]. the same packet -- this is known as address compression [PACKETBB].
Finally, as a special optimisation for the case when a router-id Finally, as a special optimisation for the case when a router-id
coincides with the interface-id part of an IPv6 address, the router- coincides with the interface-id part of an IPv6 address, the router-
id can optionally be derived from the low-order bits of the id can optionally be derived from the low-order bits of the
advertised prefix. advertised prefix.
The encoding of updates is described in detail in Section 4.4. The encoding of updates is described in detail in Section 4.6.
3.5.4. Route Acquisition 3.5.4. Route Acquisition
When a Babel node receives an update (router-id, prefix, seqno, When a Babel node receives an update (router-id, prefix, seqno,
metric) from a neighbour neigh with a link cost value equal to cost, metric) from a neighbour neigh with a link cost value equal to cost,
it checks whether it already has a routing table entry indexed by it checks whether it already has a routing table entry indexed by
(neigh, router-id, prefix). (neigh, router-id, prefix).
If no such entry exists: If no such entry exists:
skipping to change at page 24, line 4 skipping to change at page 25, line 13
This is done as follows. This is done as follows.
If no entry indexed by (prefix, plen, router-id) exists in the source If no entry indexed by (prefix, plen, router-id) exists in the source
table, then one is created with value (prefix, plen, router-id, table, then one is created with value (prefix, plen, router-id,
seqno, metric). seqno, metric).
If an entry (prefix, plen, router-id, seqno', metric') exists, then If an entry (prefix, plen, router-id, seqno', metric') exists, then
it is updated as follows: it is updated as follows:
o if seqno > seqno', then seqno' := seqno, metric' := metric; o if seqno > seqno', then seqno' := seqno, metric' := metric;
o if seqno = seqno' and metric' > metric, then metric' := metric; o if seqno = seqno' and metric' > metric, then metric' := metric;
o otherwise, nothing needs to be done. o otherwise, nothing needs to be done.
The garbage-collection timer for the entry is then reset. Note that The garbage-collection timer for the entry is then reset. Note that
the garbage-collection timer is not reset when a retraction is sent. the garbage-collection timer is not reset when a retraction is sent.
When the garbage-collection timer expires, the entry is removed from
the source table.
3.7.4. Split Horizon 3.7.4. Split Horizon
When running over a transitive, symmetric link technology, e.g., a When running over a transitive, symmetric link technology, e.g., a
point-to-point link or a wired LAN technology such as Ethernet, a point-to-point link or a wired LAN technology such as Ethernet, a
Babel node SHOULD use an optimisation known as split horizon. When Babel node SHOULD use an optimisation known as split horizon. When
split horizon is used on a given interface, a routing update is not split horizon is used on a given interface, a routing update is not
sent on this particular interface when the advertised route was sent on this particular interface when the advertised route was
learnt from a neighbour over the same interface. learnt from a neighbour over the same interface.
Split horizon SHOULD NOT be applied to an interface unless the Split horizon SHOULD NOT be applied to an interface unless the
skipping to change at page 25, line 19 skipping to change at page 26, line 31
such a route exists, it MUST send an update; if such a route does such a route exists, it MUST send an update; if such a route does
not, it MUST send a retraction for that prefix. not, it MUST send a retraction for that prefix.
When a node receives a wildcard route request, it SHOULD send a full When a node receives a wildcard route request, it SHOULD send a full
routing table dump. routing table dump.
3.8.1.2. Seqno Requests 3.8.1.2. Seqno Requests
When a node receives a seqno request for a given router-id and When a node receives a seqno request for a given router-id and
sequence number, it checks whether its routing table contains a sequence number, it checks whether its routing table contains a
selected entry for that prefix; if no such entry exists, or the entry selected entry for that prefix. If a selected route for the given
has infinite metric, it ignores the request. prefix exists, it has finite metric, and either the router-ids are
different or the router-ids are equal and the entry's sequence number
If a selected route for the given prefix exists, and either the is no smaller than the requested sequence number, the node MUST send
router-ids are different or the router-ids are equal and the entry's an update for the given prefix. If the router-ids match but the
sequence number is no smaller than the requested sequence number, it requested seqno is larger (modulo 2^16) than the route entry's, the
MUST send an update for the given prefix. node compares the router-id against its own router-id. If the
router-id is its own, then it increases its sequence number by 1 and
If the router-ids match but the requested seqno is larger than the sends an update. A node MUST NOT increase its sequence number by
route entry's, the node compares the router-id against its own more than 1 in response to a seqno request.
router-id. If the router-id is its own, then it increases its
sequence number by 1 and sends an update. A node MUST NOT increase
its sequence number by more than 1 in response to a seqno request.
If the requested router-id is not its own, the received request's hop Otherwise, if the requested router-id is not its own, the received
count is 2 or more, and the node has a route (not necessarily a request's hop count is 2 or more, and the node has a route (not
feasible one) for the requested prefix that does not use the necessarily a feasible one) for the requested prefix that does not
requestor as a next hop, the node SHOULD forward the request. It use the requestor as a next hop, the node MUST forward the request if
does so by decreasing the hop count and sending the request in a it has a feasible route to the requested prefix and it is advertising
unicast packet destined to a neighbour that advertises the given this prefix to neighbours, and SHOULD forward the request if it has a
prefix (not necessarily the selected neighbour) and that is distinct (not necessarily feasible) route to the requested prefix. It does so
from the neighbour from which the request was received. by decreasing the hop count and sending the request in a unicast
packet destined to a neighbour that advertises the given prefix and
that is not the neighbour from which the request was received.
A node SHOULD maintain a list of recently forwarded requests and A node SHOULD maintain a list of recently forwarded requests and
forward the reply in a timely manner. A node SHOULD compare every forward the reply (an update with a sufficiently large seqno) in a
incoming request against its list of recently forwarded requests and timely manner. A node SHOULD compare every incoming request against
avoid forwarding it if it is redundant. its list of recently forwarded requests and avoid forwarding it if it
is redundant.
Since the request-forwarding mechanism does not necessarily obey the Since the request-forwarding mechanism does not necessarily obey the
feasibility condition, it may get caught in routing loops; hence, feasibility condition, it may get caught in routing loops; hence,
requests carry a hop count to limit the time for which they remain in requests carry a hop count to limit the time for which they remain in
the network. However, since requests are only ever forwarded as the network. However, since requests are only ever forwarded as
unicast packets, the initial hop count need not be kept particularly unicast packets, the initial hop count need not be kept particularly
low, and performing an expanding horizon search is not necessary. A low, and performing an expanding horizon search is not necessary. A
request MUST NOT be forwarded to a multicast address, and it MUST be request MUST NOT be forwarded to a multicast address, and it MUST NOT
forwarded to a single neighbour only. be forwarded to multiple neighbours.
3.8.2. Sending Requests 3.8.2. Sending Requests
A Babel node MAY send a route or seqno request at any time, to a A Babel node MAY send a route or seqno request at any time, to a
multicast or a unicast address; there is only one case when multicast or a unicast address; there is only one case when
originating requests is required (Section 3.8.2.1). originating requests is required (Section 3.8.2.1).
3.8.2.1. Avoiding Starvation 3.8.2.1. Avoiding Starvation
When a route is retracted or expires, a Babel node usually switches When a route is retracted or expires, a Babel node usually switches
to another feasible route for the same prefix. It may be the case, to another feasible route for the same prefix. It may be the case,
however, that no such routes are available. however, that no such routes are available.
A node that has lost all feasible routes to a given destination MUST A node that has lost all feasible routes to a given destination but
still has unexpired unfeasible routes to that destination, MUST send
a seqno request; if it doesn't have any such routes, it MAY still
send a seqno request. The router-id of the request is set to the send a seqno request. The router-id of the request is set to the
router-id of the route that it has just lost, and the requested seqno router-id of the route that it has just lost, and the requested seqno
is the value contained in the source table, plus 1. is the value contained in the source table, plus 1.
Such a request SHOULD be multicast over all of the node's attached If the node has any (unfeasible) routes to the requested destination,
interfaces. Similar requests will be sent by other nodes that are then it MUST send the request to at least one of the next-hop
affected by the route's loss and will be forwarded by neighbouring neighbours that advertised these routes, and SHOULD send it to all of
nodes up to the source. If the network is connected, and there is no them; in any case, it MAY send the request to any other neighbours,
packet loss, this will result in a route being advertised with a new whether they advertise a route to the requested destination or not.
sequence number. (Note that, due to duplicate suppression, only a A simple implementation strategy is therefore to unconditionally
small number of such requests will actually reach the source.) multicast the request over all attached interfaces.
Similar requests will be sent by other nodes that are affected by the
route's loss. If the network is still connected, and assuming no
packet loss, then at least one of these requests will be forwarded to
the source, resulting in a route being advertised with a new sequence
number. (Note that, due to duplicate suppression, only a small
number of such requests will actually reach the source.)
In order to compensate for packet loss, a node SHOULD repeat such a In order to compensate for packet loss, a node SHOULD repeat such a
request a small number of times if no route becomes feasible within a request a small number of times if no route becomes feasible within a
short time. Under heavy packet loss, however, all such requests may short time. Under heavy packet loss, however, all such requests
be lost; in that case, the second mechanism in the next section will might be lost; in that case, the second mechanism in the next section
eventually ensure that a new seqno is received. will eventually ensure that a new seqno is received.
3.8.2.2. Dealing with Unfeasible Updates 3.8.2.2. Dealing with Unfeasible Updates
When a route's metric increases, a node might receive an unfeasible When a route's metric increases, a node might receive an unfeasible
update for a route that it has currently selected. As specified in update for a route that it has currently selected. As specified in
Section 3.5.1, the receiving node will either ignore the update or Section 3.5.1, the receiving node will either ignore the update or
retract the route. retract the route.
In order to keep routes from spuriously expiring because they have In order to keep routes from spuriously expiring because they have
become unfeasible, a node SHOULD send a unicast seqno request become unfeasible, a node SHOULD send a unicast seqno request
whenever it receives an unfeasible update for a route that is whenever it receives an unfeasible update for a route that is
currently selected. The requested sequence number is computed from currently selected. The requested sequence number is computed from
the source table as above. the source table as above.
Additionally, a node SHOULD send a unicast seqno request whenever it Additionally, since metric computation does not necessarily coincide
receives an unfeasible update from a currently unselected neighbour with the delay in propagating updates, a node might receive an
that is "good enough", i.e., that would lead to the received route unfeasible update from a currently unselected neighbour that is
becoming selected were it feasible. preferable to the currently selected route (e.g., because it has a
much smaller metric); in that case, the node SHOULD send a unicast
seqno request to the neighbour that advertised the preferable update.
3.8.2.3. Preventing Routes from Expiring 3.8.2.3. Preventing Routes from Expiring
In normal operation, a route's expiry timer should never trigger: In normal operation, a route's expiry timer should never trigger:
since a route's hold time is computed from an explicit interval since a route's hold time is computed from an explicit interval
included in Update TLVs, a new update should arrive in time to included in Update TLVs, a new update (possibly a retraction) should
prevent a route from expiring. arrive in time to prevent a route from expiring.
In the presence of packet loss, however, it may be the case that no In the presence of packet loss, however, it may be the case that no
update is successfully received for an extended period of time, update is successfully received for an extended period of time,
causing a route to expire. In order to avoid such spurious expiry, causing a route to expire. In order to avoid such spurious expiry,
shortly before a selected route expires, a Babel node SHOULD send a shortly before a selected route expires, a Babel node SHOULD send a
unicast route request to the neighbour that advertised this route; unicast route request to the neighbour that advertised this route;
since nodes always send retractions in response to non-wildcard route since nodes always send retractions in response to non-wildcard route
requests (Section 3.8.1.1), this will usually result in either the requests (Section 3.8.1.1), this will usually result in either the
route being refreshed or a retraction being received. route being refreshed or a retraction being received.
3.8.2.4. Acquiring New Neighbours 3.8.2.4. Acquiring New Neighbours
In order to speed up convergence after a mobility event, a node MAY In order to speed up convergence after a mobility event, a node MAY
send a unicast wildcard request after acquiring a new neighbour. send a unicast wildcard request after acquiring a new neighbour.
Additionally, a node MAY send a small number of multicast wildcard Additionally, a node MAY send a small number of multicast wildcard
requests shortly after booting. requests shortly after booting. Note that doing that carelessly can
cause serious congestion when a whole network is rebooted, especially
on link layers with high per-packet overhead (e.g., IEEE 802.11).
4. Protocol Encoding 4. Protocol Encoding
A Babel packet is sent as the body of a UDP datagram, with network- A Babel packet is sent as the body of a UDP datagram, with network-
layer hop count set to 1, destined to a well-known multicast address layer hop count set to 1, destined to a well-known multicast address
or to a unicast address, over IPv4 or IPv6; in the case of IPv6, or to a unicast address, over IPv4 or IPv6; in the case of IPv6,
these addresses are link-local. Both the source and destination UDP these addresses are link-local. Both the source and destination UDP
port are set to a well-known port number. A Babel packet MUST be port are set to a well-known port number. A Babel packet MUST be
silently ignored unless its source address is either a link-local silently ignored unless its source address is either a link-local
IPv6 address, or an IPv4 address belonging to the local network, and IPv6 address, or an IPv4 address belonging to the local network, and
skipping to change at page 29, line 48 skipping to change at page 31, line 23
Any data following the body MUST be silently ignored. Any data following the body MUST be silently ignored.
4.3. TLV Format 4.3. TLV Format
With the exception of Pad1, all TLVs have the following structure: With the exception of Pad1, all TLVs have the following structure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Body... | Type | Length | Payload...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
Type The type of the TLV. Type The type of the TLV.
Length The length of the body, exclusive of the Type and Length Length The length of the body, exclusive of the Type and Length
fields. If the body is longer than the expected length of fields. If the body is longer than the expected length of
a given type of TLV, any extra data MUST be silently a given type of TLV, any extra data MUST be silently
ignored. ignored.
Body The TLV body, the interpretation of which depends on the Payload The TLV payload, which consists of a body and, for selected
type. TLV types, an optional list of sub-TLVs.
TLVs with an unknown type value MUST be silently ignored. TLVs with an unknown type value MUST be silently ignored.
4.4. Details of Specific TLVs 4.4. Sub-TLV Format
4.4.1. Pad1 Every TLV carries an explicit length in its header; however, most
TLVs are self-terminating, in the sense that it is possible to
determine the length of the body without reference to the explicit
TLV length. If a TLV has a self-terminating format, then it MAY
allow a sequence of sub-TLVs to follow the body.
Sub-TLVs have the same structure as TLVs. With the exception of
PAD1, all TLVs have the following structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Body...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields :
Type The type of the sub-TLV.
Length The length of the body, in octets, exclusive of the Type
and Length fields.
Body The sub-TLV body, the interpretation of which depends on
both the type of the sub-TLV and the type of the TLV within
which it is embedded.
The most-significant bit of the sub-TLV, called the mandatory bit,
indicates how to handle unknown sub-TLVs. If the mandatory bit is
not set, then an unknown sub-TLV MUST be silently ignored, and the
rest of the TLV processed normally. If the mandatory bit is set,
then the whole enclosing TLV MUST be silently ignored (except for
updating the parser state by a Router-ID, Next-Hop or Update TLV, see
Section 4.6.7, Section 4.6.8, and Section 4.6.9).
4.5. Parser state
Babel uses a stateful parser: a TLV may refer to data from a previous
TLV. Babel's parser state consists of the following pieces of data:
o for each address encoding that allows compression, the current
default prefix; this is undefined at the start of the packet, and
is updated by an Update TLV with flag 80 hexadecimal set
(Section 4.6.9);
o for each address family (IPv4 or IPv6), the current next-hop; this
is the source address of the enclosing packet for the matching
address family at the start of a packet, and is updated by the
Next-Hop TLV (Section 4.6.8);
o the current router-id; this is undefined at the start of the
packet, and is updated by both the Router-ID TLV (Section 4.6.7)
and the Update TLV with flag 40 hexadecimal set.
Since the parser state is separate from the bulk of Babel's state,
and for correct parsing must be identical across implementations, it
is updated before checking for mandatory TLVs: parsing a TLV updates
the parser state even if the TLV is otherwise ignored due to an
unknown mandatory sub-TLV.
4.6. Details of Specific TLVs
4.6.1. Pad1
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type = 0 | | Type = 0 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Fields : Fields :
Type Set to 0 to indicate a Pad1 TLV. Type Set to 0 to indicate a Pad1 TLV.
This TLV is silently ignored on reception. This TLV is silently ignored on reception.
4.4.2. PadN 4.6.2. PadN
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length | MBZ... | Type = 1 | Length | MBZ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
Type Set to 1 to indicate a PadN TLV. Type Set to 1 to indicate a PadN TLV.
Length The length of the body, exclusive of the Type and Length Length The length of the body, exclusive of the Type and Length
fields. fields.
MBZ Set to 0 on transmission. MBZ Set to 0 on transmission.
This TLV is silently ignored on reception. This TLV is silently ignored on reception.
4.4.3. Acknowledgement Request 4.6.3. Acknowledgement Request
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length | Reserved | | Type = 2 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce | Interval | | Nonce | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV requests that the receiver send an Acknowledgement TLV This TLV requests that the receiver send an Acknowledgement TLV
within the number of centiseconds specified by the Interval field. within the number of centiseconds specified by the Interval field.
Fields : Fields :
Type Set to 2 to indicate an Acknowledgement Request TLV. Type Set to 2 to indicate an Acknowledgement Request TLV.
Length The length of the body, exclusive of the Type and Length Length The length of the body, exclusive of the Type and Length
fields. fields.
skipping to change at page 31, line 35 skipping to change at page 34, line 24
Reserved Sent as 0 and MUST be ignored on reception. Reserved Sent as 0 and MUST be ignored on reception.
Nonce An arbitrary value that will be echoed in the receiver's Nonce An arbitrary value that will be echoed in the receiver's
Acknowledgement TLV. Acknowledgement TLV.
Interval A time interval in centiseconds after which the sender will Interval A time interval in centiseconds after which the sender will
assume that this packet has been lost. This MUST NOT be 0. assume that this packet has been lost. This MUST NOT be 0.
The receiver MUST send an acknowledgement before this time The receiver MUST send an acknowledgement before this time
has elapsed (with a margin allowing for propagation time). has elapsed (with a margin allowing for propagation time).
4.4.4. Acknowledgement This TLV is self-terminating, and allows sub-TLVs.
4.6.4. Acknowledgement
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Length | Nonce | | Type = 3 | Length | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is sent by a node upon receiving an Acknowledgement Request. This TLV is sent by a node upon receiving an Acknowledgement Request.
Fields : Fields :
skipping to change at page 32, line 11 skipping to change at page 34, line 49
Length The length of the body, exclusive of the Type and Length Length The length of the body, exclusive of the Type and Length
fields. fields.
Nonce Set to the Nonce value of the Acknowledgement Request that Nonce Set to the Nonce value of the Acknowledgement Request that
prompted this Acknowledgement. prompted this Acknowledgement.
Since nonce values are not globally unique, this TLV MUST be sent to Since nonce values are not globally unique, this TLV MUST be sent to
a unicast address. a unicast address.
4.4.5. Hello This TLV is self-terminating, and allows sub-TLVs.
4.6.5. Hello
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Length | Reserved | | Type = 4 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seqno | Interval | | Seqno | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is used for neighbour discovery and for determining a link's This TLV is used for neighbour discovery and for determining a link's
skipping to change at page 32, line 46 skipping to change at page 35, line 40
Interval An upper bound, expressed in centiseconds, on the time Interval An upper bound, expressed in centiseconds, on the time
after which the sending node will send a new Hello TLV. after which the sending node will send a new Hello TLV.
This MUST NOT be 0. This MUST NOT be 0.
Since there is a single seqno counter for all the Hellos sent by a Since there is a single seqno counter for all the Hellos sent by a
given node over a given interface, this TLV MUST be sent to a given node over a given interface, this TLV MUST be sent to a
multicast destination. In order to avoid large discontinuities in multicast destination. In order to avoid large discontinuities in
link quality, multiple Hello TLVs SHOULD NOT be sent in the same link quality, multiple Hello TLVs SHOULD NOT be sent in the same
packet. packet.
4.4.6. IHU This TLV is self-terminating, and allows sub-TLVs.
4.6.6. IHU
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Length | AE | Reserved | | Type = 5 | Length | AE | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rxcost | Interval | | Rxcost | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address... | Address...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
An IHU ("I Heard You") TLV is used for confirming bidirectional An IHU ("I Heard You") TLV is used for confirming bidirectional
reachability and carrying a link's transmission cost. reachability and carrying a link's transmission cost.
Fields : Fields :
Type Set to 5 to indicate an IHU TLV. Type Set to 5 to indicate an IHU TLV.
Length The length of the body, exclusive of the Type and Length Length The length of the body, exclusive of the Type and Length
fields. fields.
skipping to change at page 34, line 8 skipping to change at page 36, line 46
Conceptually, an IHU is destined to a single neighbour. However, IHU Conceptually, an IHU is destined to a single neighbour. However, IHU
TLVs contain an explicit destination address, and it SHOULD be sent TLVs contain an explicit destination address, and it SHOULD be sent
to a multicast address, as this allows aggregation of IHUs destined to a multicast address, as this allows aggregation of IHUs destined
to distinct neighbours into a single packet and avoids the need for to distinct neighbours into a single packet and avoids the need for
an ARP or Neighbour Discovery exchange when a neighbour is not being an ARP or Neighbour Discovery exchange when a neighbour is not being
used for data traffic. used for data traffic.
IHU TLVs with an unknown value for the AE field MUST be silently IHU TLVs with an unknown value for the AE field MUST be silently
ignored. ignored.
4.4.7. Router-Id This TLV is self-terminating, and allows sub-TLVs.
4.6.7. Router-Id
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length | Reserved | | Type = 6 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Router-Id + + Router-Id +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Router-Id TLV establishes a router-id that is implied by subsequent A Router-Id TLV establishes a router-id that is implied by subsequent
Update TLVs. Update TLVs. This TLV sets the router-id even if it is otherwise
ignored due to an unknown mandatory sub-TLV.
Fields : Fields :
Type Set to 6 to indicate a Router-Id TLV. Type Set to 6 to indicate a Router-Id TLV.
Length The length of the body, exclusive of the Type and Length Length The length of the body, exclusive of the Type and Length
fields. fields.
Reserved Sent as 0 and MUST be ignored on reception. Reserved Sent as 0 and MUST be ignored on reception.
Router-Id The router-id for routes advertised in subsequent Update Router-Id The router-id for routes advertised in subsequent Update
TLVs. This MUST NOT consist of all zeroes or all ones. TLVs. This MUST NOT consist of all zeroes or all ones.
4.4.8. Next Hop This TLV is self-terminating, and allows sub-TLVs.
4.6.8. Next Hop
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Length | AE | Reserved | | Type = 7 | Length | AE | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next hop... | Next hop...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
A Next Hop TLV establishes a next-hop address for a given address A Next Hop TLV establishes a next-hop address for a given address
family (IPv4 or IPv6) that is implied by subsequent Update TLVs. family (IPv4 or IPv6) that is implied by subsequent Update TLVs.
This TLV sets up the next-hop for subsequent Update TLVs even if it
is ignored due to an unknown mandatory sub-TLV.
Fields : Fields :
Type Set to 7 to indicate a Next Hop TLV. Type Set to 7 to indicate a Next Hop TLV.
Length The length of the body, exclusive of the Type and Length Length The length of the body, exclusive of the Type and Length
fields. fields.
AE The encoding of the Address field. This SHOULD be 1 or 3 AE The encoding of the Address field. This SHOULD be 1 or 3
and MUST NOT be 0. and MUST NOT be 0.
skipping to change at page 35, line 23 skipping to change at page 38, line 23
Next hop The next-hop address advertised by subsequent Update TLVs, Next hop The next-hop address advertised by subsequent Update TLVs,
for this address family. for this address family.
When the address family matches the network-layer protocol that this When the address family matches the network-layer protocol that this
packet is transported over, a Next Hop TLV is not needed: in that packet is transported over, a Next Hop TLV is not needed: in that
case, the next hop is taken to be the source address of the packet. case, the next hop is taken to be the source address of the packet.
Next Hop TLVs with an unknown value for the AE field MUST be silently Next Hop TLVs with an unknown value for the AE field MUST be silently
ignored. ignored.
4.4.9. Update This TLV is self-terminating, and allows sub-TLVs.
4.6.9. Update
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 | Length | AE | Flags | | Type = 8 | Length | AE | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Plen | Omitted | Interval | | Plen | Omitted | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seqno | Metric | | Seqno | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 36, line 36 skipping to change at page 39, line 39
hexadecimal (infinity) means that this is a route hexadecimal (infinity) means that this is a route
retraction. retraction.
Prefix The prefix being advertised. This field's size is (Plen/8 Prefix The prefix being advertised. This field's size is (Plen/8
- Omitted) rounded upwards. - Omitted) rounded upwards.
The Flags field is interpreted as follows: The Flags field is interpreted as follows:
o if the bit with value 80 hexadecimal is set, then this Update o if the bit with value 80 hexadecimal is set, then this Update
establishes a new default prefix for subsequent Update TLVs with a establishes a new default prefix for subsequent Update TLVs with a
matching address family within the same packet; matching address encoding within the same packet, even if this TLV
is otherwise ignored due to an unknown mandatory sub-TLV;
o if the bit with value 40 hexadecimal is set, then the low-order 8 o if the bit with value 40 hexadecimal is set, then this TLV
octets of the advertised prefix establish a new default router-id establishes a new default router-id for this TLV and subsequent
for this TLV and subsequent Update TLVs in the same packet. Update TLVs in the same packet, even if this TLV is otherwise
ignored due to an unknown mandatory sub-TLV. This router-id is
computed from the first address of the advertised prefix as
follows:
* if the length of the address is 8 octets or more, then the new
router-id is taken from the 8 last octets of the address;
* if the length of the address is smaller than 8 octets, then the
new router-id consists of the required number of zero octets
followed by the address, i.e., the address is stored on the
right of the router-id. For example, for an IPv4 address, the
router-id consists of 4 octets of zeroes followed by the IPv4
address.
The prefix being advertised by an Update TLV is computed as follows: The prefix being advertised by an Update TLV is computed as follows:
o the first Omitted octets of the prefix are taken from the previous o the first Omitted octets of the prefix are taken from the previous
Update TLV with flag 80 hexadecimal set and the same address Update TLV with flag 80 hexadecimal set and the same address
family; encoding, even if it was ignored due to an unknown mandatory sub-
TLV;
o the next (Plen/8 - Omitted) (rounded upwards) octets are taken o the next (Plen/8 - Omitted) rounded upwards octets are taken from
from the Prefix field; the Prefix field;
o the remaining octets are set to 0. o the remaining octets are set to 0.
If the Metric field is finite, the router-id of the originating node If the Metric field is finite, the router-id of the originating node
for this announcement is taken from the low-order 8 octets of the for this announcement is taken from the prefix advertised by this
prefix advertised by this Update if the bit with value 40 hexadecimal Update if the bit with value 40 hexadecimal is set in the Flags
is set in the Flags field. Otherwise, it is taken either from the field, computed as described above. Otherwise, it is taken either
preceding Router-Id packet, or the preceding Update packet with flag from the preceding Router-Id packet, or the preceding Update packet
40 hexadecimal set, whichever comes last. with flag 40 hexadecimal set, whichever comes last, even if that TLV
is otherwise ignored due to an unknown mandatory sub-TLV.
The next-hop address for this update is taken from the last preceding The next-hop address for this update is taken from the last preceding
Next Hop TLV with a matching address family in the same packet; if no Next Hop TLV with a matching address family (IPv4 or IPv6) in the
such TLV exists, it is taken from the network-layer source address of same packet even if it was otherwise ignored due to an unknown
this packet. mandatory sub-TLV; if no such TLV exists, it is taken from the
network-layer source address of this packet.
If the metric field is FFFF hexadecimal, this TLV specifies a If the metric field is FFFF hexadecimal, this TLV specifies a
retraction. In that case, the current router-id and the Seqno are retraction. In that case, the current router-id and the Seqno are
not used. AE MAY then be 0, in which case this Update retracts all not used. AE MAY then be 0, in which case this Update retracts all
of the routes previously advertised on this interface. of the routes previously advertised on this interface.
Update TLVs with an unknown value for the AE field MUST be silently Update TLVs with an unknown value for the AE field MUST be silently
ignored. ignored.
4.4.10. Route Request This TLV is self-terminating, and allows sub-TLVs.
4.6.10. Route Request
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length | AE | Plen | | Type = 9 | Length | AE | Plen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix... | Prefix...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
A Route Request TLV prompts the receiver to send an update for a A Route Request TLV prompts the receiver to send an update for a
given prefix, or a full routing table dump. given prefix, or a full routing table dump.
skipping to change at page 38, line 13 skipping to change at page 41, line 39
rounded upwards. rounded upwards.
A Request TLV prompts the receiving node to send an update message A Request TLV prompts the receiving node to send an update message
for the prefix specified by the AE, Plen, and Prefix fields, or a for the prefix specified by the AE, Plen, and Prefix fields, or a
full dump of its routing table if AE is 0 (in which case Plen MUST be full dump of its routing table if AE is 0 (in which case Plen MUST be
0 and Prefix is of length 0). A Request may be sent to a unicast 0 and Prefix is of length 0). A Request may be sent to a unicast
address if it is destined to a single node, or to a multicast address address if it is destined to a single node, or to a multicast address
if the request is destined to all of the neighbours of the sending if the request is destined to all of the neighbours of the sending
interface. interface.
4.4.11. Seqno Request This TLV is self-terminating, and allows sub-TLVs.
4.6.11. Seqno Request
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 | Length | AE | Plen | | Type = 10 | Length | AE | Plen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seqno | Hop Count | Reserved | | Seqno | Hop Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Router-Id + + Router-Id +
| | | |
skipping to change at page 39, line 11 skipping to change at page 42, line 49
Router Id The Router-Id that is being requested. This MUST NOT Router Id The Router-Id that is being requested. This MUST NOT
consist of all zeroes or all ones. consist of all zeroes or all ones.
Prefix The prefix being requested. This field's size is Plen/8 Prefix The prefix being requested. This field's size is Plen/8
rounded upwards. rounded upwards.
A Seqno Request TLV prompts the receiving node to send an Update for A Seqno Request TLV prompts the receiving node to send an Update for
the prefix specified by the AE, Plen, and Prefix fields, with either the prefix specified by the AE, Plen, and Prefix fields, with either
a router-id different from what is specified by the Router-Id field, 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 or a Seqno no less (modulo 2^16) than what is specified by the Seqno
this request cannot be satisfied locally, then it is forwarded field. If this request cannot be satisfied locally, then it is
according to the rules set out in Section 3.8.1.2. forwarded according to the rules set out in Section 3.8.1.2.
While a Seqno Request MAY be sent to a multicast address, it MUST NOT While a Seqno Request MAY be sent to a multicast address, it MUST NOT
be forwarded to a multicast address and MUST NOT be forwarded to more be forwarded to a multicast address and MUST NOT be forwarded to more
than one neighbour. A request MUST NOT be forwarded if its Hop Count than one neighbour. A request MUST NOT be forwarded if its Hop Count
field is 1. field is 1.
This TLV is self-terminating, and allows sub-TLVs.
4.7. Details of specific sub-TLVs
4.7.1. Pad1
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0 |
+-+-+-+-+-+-+-+-+
Fields :
Type Set to 0 to indicate a Pad1 sub-TLV.
This sub-TLV is silently ignored on reception.
4.7.2. PadN
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length | MBZ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields :
Type Set to 1 to indicate a PadN sub-TLV.
Length The length of the body, in octets, exclusive of the Type
and Length fields.
MBZ Set to 0 on transmission.
This sub-TLV is silently ignored on reception.
5. IANA Considerations 5. IANA Considerations
IANA has registered the UDP port number 6696, called "babel", for use IANA has registered the UDP port number 6696, called "babel", for use
by the Babel protocol. by the Babel protocol.
IANA has registered the IPv6 multicast group ff02:0:0:0:0:0:1:6 and IANA has registered the IPv6 multicast group ff02:0:0:0:0:0:1:6 and
the IPv4 multicast group 224.0.0.111 for use by the Babel protocol. the IPv4 multicast group 224.0.0.111 for use by the Babel protocol.
6. Security Considerations 6. Security Considerations
skipping to change at page 44, line 29 skipping to change at page 49, line 5
Route Expiry Time: 3.5 times the advertised update interval. Route Expiry Time: 3.5 times the advertised update interval.
Source GC time: 3 minutes. Source GC time: 3 minutes.
The amount of jitter applied to a packet depends on whether it The amount of jitter applied to a packet depends on whether it
contains any urgent TLVs or not. Urgent triggered updates and urgent contains any urgent TLVs or not. Urgent triggered updates and urgent
requests are delayed by no more than 200ms; other TLVs are delayed by requests are delayed by no more than 200ms; other TLVs are delayed by
no more than one-half the Hello interval. no more than one-half the Hello interval.
Appendix C. Simplified Implementations Appendix C. Considerations for protocol extensions
Babel is an extensible protocol, and this document defines a number
of mechanisms that can be used to extend the protocol in a backwards
compatible manner:
o increasing the version number in the packet header;
o defining new TLVs;
o defining new sub-TLVs (with the mandatory bit set or not);
o defining new AEs;
o using the packet trailer.
New versions of the Babel protocol should only be defined if the new
version is not backwards compatible with the original protocol.
In many cases, an extension could be implemented either by defining a
new TLV, or by adding a new sub-TLV to an existing TLV. For example,
an extension whose purpose is to attach additional data to route
updates can be implemented either by creating a new "enriched" Update
TLV, or by adding a sub-TLV to the Update TLV.
The two encodings are treated differently by implementations that do
not understand the extension. In the case of a new TLV, the whole
unknown TLV is ignored by an implementation of the original protocol,
while in the case of a new sub-TLV, the TLV is parsed and acted upon,
and the unknown sub-TLV is silently ignored. Therefore, a sub-TLV
should be used by extensions that extend the Update in a compatible
manner (the extension data may be silently ignored), while a new TLV
must be used by extensions that make incompatible extensions to the
meaning of the TLV (the whole TLV must be thrown away if the
extension data is not understood).
Adding a new AE is essentially equivalent to adding a new TLV: Update
TLVs with an unknown AE are ignored, just like unknown TLVs.
However, adding a new AE is often more involved than adding a new
TLV, since it creates a new set of compression state. Additionally,
since the Next Hop TLV creates state specific to a given address
family, as opposed to a given AE. A similar issue arises with Update
TLVs with unknown AEs establishing a new router-id (flag 40
hexadecimal). Therefore, defining new AEs must be done with care if
compatibility with unextended implementations is required.
The packet trailer -- the space after the declared length of the
packet but within the payload of the UDP datagram -- was originally
intended to carry a cryptographic signature. However, at this time
no extension has used it, and therefore we refrain from making any
recommendations about its use due to the lack of implementation
experience.
Appendix D. Simplified Implementations
Babel is a fairly economic protocol. Route updates take between 12 Babel is a fairly economic protocol. Route updates take between 12
and 40 octets per destination, depending on how successful and 40 octets per destination, depending on how successful
compression is; in a double-stack mesh network, an average of less compression is; in a double-stack mesh network, an average of less
than 24 octets is typical. The route table occupies about 35 octets than 24 octets is typical. The route table occupies about 35 octets
per IPv6 entry. To put these values into perspective, a single full- per IPv6 entry. To put these values into perspective, a single full-
size Ethernet frame can carry some 65 route updates, and a megabyte size Ethernet frame can carry some 65 route updates, and a megabyte
of memory can contain a 20000-entry routing table and the associated of memory can contain a 20000-entry routing table and the associated
source table. source table.
skipping to change at page 45, line 15 skipping to change at page 50, line 44
default route. Since a parasitic implementation never forwards default route. Since a parasitic implementation never forwards
packets, it cannot possibly participate in a routing loop; hence, it packets, it cannot possibly participate in a routing loop; hence, it
need not evaluate the feasibility condition, and need not maintain a need not evaluate the feasibility condition, and need not maintain a
source table. source table.
A parasitic implementation MUST answer acknowledgement requests and A parasitic implementation MUST answer acknowledgement requests and
MUST participate in the Hello/IHU protocol. Finally, it MUST be able MUST participate in the Hello/IHU protocol. Finally, it MUST be able
to reply to seqno requests for routes that it announces and SHOULD be to reply to seqno requests for routes that it announces and SHOULD be
able to reply to route requests. able to reply to route requests.
Appendix D. Software Availability Appendix E. Software Availability
The sample implementation of Babel is available from The sample implementation of Babel is available from
<http://www.pps.univ-paris-diderot.fr/~jch/software/babel/>. <http://www.pps.univ-paris-diderot.fr/~jch/software/babel/>.
Appendix E. Changes from previous versions Appendix F. Changes from previous versions
E.1. Changes since RFC 6126 F.1. Changes since RFC 6126
o Changed UDP port number to 6696. o Changed UDP port number to 6696.
o Consistently use router-id rather than id. o Consistently use router-id rather than id.
o Clarified that the source garbage collection timer is reset after o Clarified that the source garbage collection timer is reset after
sending an update even if the entry was not modified. sending an update even if the entry was not modified.
o In section "Seqno Requests", fixed an erroneous "route request". o In section "Seqno Requests", fixed an erroneous "route request".
o In the description of the Seqno Request TLV, added the description o In the description of the Seqno Request TLV, added the description
of the Router-Id field. of the Router-Id field.
o Made router-ids all-0 and all-1 forbidden. o Made router-ids all-0 and all-1 forbidden.
F.2. Changes since draft-ietf-babel-rfc6126bis-00
o Added security considerations.
F.3. Changes since draft-ietf-babel-rfc6126bis-01
o Integrated the format of sub-TLVs.
o Mentioned for each TLV whether it supports sub-TLVs.
o Added Appendix C.
o Added a mandatory bit in sub-TLVs.
o Changed compression state to be per-AF rather than per-AE.
o Added implementation hint for the route table.
o Clarified how router-ids are computed when bit 0x40 is set in
Updates.
o Relaxed the conditions for sending requests, and tightened the
conditions for forwarding requests.
o Clarified that neighbours should be acquired at some point, but it
doesn't matter when.
Author's Address Author's Address
Juliusz Chroboczek Juliusz Chroboczek
IRIF, University of Paris-Diderot IRIF, University of Paris-Diderot
Case 7014 Case 7014
75205 Paris Cedex 13 75205 Paris Cedex 13
France France
Email: jch@irif.fr Email: jch@irif.fr
 End of changes. 64 change blocks. 
133 lines changed or deleted 410 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/