draft-ietf-babel-rfc6126bis-09.txt   draft-ietf-babel-rfc6126bis-10.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
Obsoletes: 6126,7557 (if approved) D. Schinazi Obsoletes: 6126,7557 (if approved) D. Schinazi
Intended status: Standards Track Google LLC Intended status: Standards Track Google LLC
Expires: November 8, 2019 May 7, 2019 Expires: December 9, 2019 June 7, 2019
The Babel Routing Protocol The Babel Routing Protocol
draft-ietf-babel-rfc6126bis-09 draft-ietf-babel-rfc6126bis-10
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. This document describes the Babel routing protocol, mesh networks. This document describes the Babel routing protocol,
and obsoletes RFCs 6126 and 7557. and obsoletes RFCs 6126 and 7557.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 November 8, 2019. This Internet-Draft will expire on December 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 3, line 14 skipping to change at page 3, line 14
F.2. Changes since draft-ietf-babel-rfc6126bis-00 . . . . . . 58 F.2. Changes since draft-ietf-babel-rfc6126bis-00 . . . . . . 58
F.3. Changes since draft-ietf-babel-rfc6126bis-01 . . . . . . 58 F.3. Changes since draft-ietf-babel-rfc6126bis-01 . . . . . . 58
F.4. Changes since draft-ietf-babel-rfc6126bis-02 . . . . . . 59 F.4. Changes since draft-ietf-babel-rfc6126bis-02 . . . . . . 59
F.5. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 59 F.5. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 59
F.6. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 60 F.6. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 60
F.7. Changes since draft-ietf-babel-rfc6126bis-04 . . . . . . 60 F.7. Changes since draft-ietf-babel-rfc6126bis-04 . . . . . . 60
F.8. Changes since draft-ietf-babel-rfc6126bis-05 . . . . . . 60 F.8. Changes since draft-ietf-babel-rfc6126bis-05 . . . . . . 60
F.9. Changes since draft-ietf-babel-rfc6126bis-06 . . . . . . 60 F.9. Changes since draft-ietf-babel-rfc6126bis-06 . . . . . . 60
F.10. Changes since draft-ietf-babel-rfc6126bis-07 . . . . . . 60 F.10. Changes since draft-ietf-babel-rfc6126bis-07 . . . . . . 60
F.11. Changes since draft-ietf-babel-rfc6126bis-08 . . . . . . 60 F.11. Changes since draft-ietf-babel-rfc6126bis-08 . . . . . . 60
F.12. Changes since draft-ietf-babel-rfc6126bis-09 . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
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.
skipping to change at page 5, line 29 skipping to change at page 5, line 29
doesn't form again. doesn't form again.
Conceptually, Bellman-Ford is executed in parallel for every source Conceptually, Bellman-Ford is executed in parallel for every source
of routing information (destination of data traffic). In the of routing information (destination of data traffic). In the
following discussion, we fix a source S; the reader will recall that following discussion, we fix a source S; the reader will recall that
the same algorithm is executed for all sources. the same algorithm is executed for all sources.
2.1. Costs, Metrics and Neighbourship 2.1. Costs, Metrics and Neighbourship
For every pair of neighbouring nodes A and B, Babel computes an For every pair of neighbouring nodes A and B, Babel computes an
abstract value known as the cost of the link from A to B., written abstract value known as the cost of the link from A to B, written
C(A, B). Given a route between any two (not necessarily C(A, B). Given a route between any two (not necessarily
neighbouring) nodes, the metric of the route is the sum of the costs neighbouring) nodes, the metric of the route is the sum of the costs
of all the edges along the route. The goal of the routing algorithm of all the links along the route. The goal of the routing algorithm
is to compute, for every source S, the tree of routes of lowest is to compute, for every source S, the tree of routes of lowest
metric to S. metric to S.
Costs and metrics need not be integers. In general, they can be Costs and metrics need not be integers. In general, they can be
values in any algebra that satisfies two fairly general conditions values in any algebra that satisfies two fairly general conditions
(Section 3.5.2). (Section 3.5.2).
A Babel node periodically sends Hello messages to all of its A Babel node periodically sends Hello messages to all of its
neighbours; it also periodically sends an IHU ("I Heard You") message neighbours; it also periodically sends an IHU ("I Heard You") message
to every neighbour from which it has recently heard a Hello. From to every neighbour from which it has recently heard a Hello. From
skipping to change at page 9, line 17 skipping to change at page 9, line 17
| FD(A) = 1 | FD(A) = 1
S |1 S |1
\ | D(B) = 2 \ | D(B) = 2
2 \| FD(B) = 2 2 \| FD(B) = 2
B B
The only route available from A to S, the one that goes through B, is The only route available from A to S, the one that goes through B, is
not feasible: A suffers from spurious starvation. At that point, the not feasible: A suffers from spurious starvation. At that point, the
whole subtree suffering from starvation must be reset, which is whole subtree suffering from starvation must be reset, which is
essentially what EIGRP does when it performs a global synchronisation essentially what EIGRP does when it performs a global synchronisation
of all the routers in the sarving subtree (the "active" phase of of all the routers in the starving subtree (the "active" phase of
EIGRP). EIGRP).
Babel reacts to starvation in a less drastic manner, by using Babel reacts to starvation in a less drastic manner, by using
sequenced routes, a technique introduced by DSDV and adopted by AODV. sequenced routes, a technique introduced by DSDV and adopted by AODV.
In addition to a metric, every route carries a sequence number, a In addition to a metric, every route carries a sequence number, a
nondecreasing integer that is propagated unchanged through the nondecreasing integer that is propagated unchanged through the
network and is only ever incremented by the source; a pair (s, m), network and is only ever incremented by the source; a pair (s, m),
where s is a sequence number and m a metric, is called a distance. where s is a sequence number and m a metric, is called a distance.
A received update is feasible when either it is more recent than the A received update is feasible when either it is more recent than the
skipping to change at page 10, line 11 skipping to change at page 10, line 11
\ | D(B) = (138, 2) \ | D(B) = (138, 2)
2 \| FD(B) = (138, 2) 2 \| FD(B) = (138, 2)
B B
at which point the route through B becomes feasible again. at which point the route through B becomes feasible again.
Note that while sequence numbers are used for determining Note that while sequence numbers are used for determining
feasibility, they are not used in route selection: a node ignores the feasibility, they are not used in route selection: a node ignores the
sequence number when selecting the best route to a given destination sequence number when selecting the best route to a given destination
(Section 3.6). Doing otherwise would cause route oscillation while a (Section 3.6). Doing otherwise would cause route oscillation while a
seqno propagates through the network, and might even cause persistent sequence number propagates through the network, and might even cause
blackholes with some exotic metrics. persistent blackholes with some exotic metrics.
2.6. Requests 2.6. Requests
In DSDV, the sequence number of a source is increased periodically. In DSDV, the sequence number of a source is increased periodically.
A route becomes feasible again after the source increases its A route becomes feasible again after the source increases its
sequence number, and the new sequence number is propagated through sequence number, and the new sequence number is propagated through
the network, which may, in general, require a significant amount of the network, which may, in general, require a significant amount of
time. time.
Babel takes a different approach. When a node detects that it is Babel takes a different approach. When a node detects that it is
skipping to change at page 10, line 46 skipping to change at page 10, line 46
(Resending requests a small number of times compensates for packet (Resending requests a small number of times compensates for packet
loss.) loss.)
Since requests are forwarded with no regard to the feasibility Since requests are forwarded with no regard to the feasibility
condition, they may, in general, be caught in a forwarding loop; this condition, they may, in general, be caught in a forwarding loop; this
is avoided by having nodes perform duplicate detection for the is avoided by having nodes perform duplicate detection for the
requests that they forward. requests that they forward.
2.7. Multiple Routers 2.7. Multiple Routers
The above discussion assumes that every prefix is originated by a The above discussion assumes that each prefix is originated by a
single router. In real networks, however, it is often necessary to single router. In real networks, however, it is often necessary to
have a single prefix originated by multiple routers: for example, the have a single prefix originated by multiple routers: for example, the
default route will be originated by all of the edge routers of a default route will be originated by all of the edge routers of a
routing domain. routing domain.
Since synchronising sequence numbers between distinct routers is Since synchronising sequence numbers between distinct routers is
problematic, Babel treats routes for the same prefix as distinct problematic, Babel treats routes for the same prefix as distinct
entities when they are originated by different routers: every route entities when they are originated by different routers: every route
announcement carries the router-id of its originating router, and announcement carries the router-id of its originating router, and
feasibility distances are not maintained per prefix, but per source, feasibility distances are not maintained per prefix, but per source,
skipping to change at page 12, line 20 skipping to change at page 12, line 20
until A learns of B's retraction of the direct route to C. B avoids until A learns of B's retraction of the direct route to C. B avoids
this pitfall by installing an "unreachable" route after a route is this pitfall by installing an "unreachable" route after a route is
retracted; this route is maintained until it can be guaranteed that retracted; this route is maintained until it can be guaranteed that
the former route has been retracted by all of B's neighbours the former route has been retracted by all of B's neighbours
(Section 3.5.5). (Section 3.5.5).
3. Protocol Operation 3. Protocol Operation
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.
For example, routers-ids could be assigned randomly, or they could For example, router-ids could be assigned randomly, or they could be
derived from a link-layer address. (The protocol encoding is derived from a link-layer address. (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 (as Babel protocol packets are sent in the body of a UDP datagram (as
described in Section 4 below). Each Babel packet consists of zero or described in Section 4 below). Each Babel packet consists of zero or
more TLVs. Most TLVs may contain sub-TLVs. 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 or to a (link-local) unicast known (link-local) multicast address or to a (link-local) unicast
address. In normal operation, a Babel speaker sends both multicast address. In normal operation, a Babel speaker sends both multicast
and unicast packets to its neighbours. and unicast packets to its neighbours.
With the exception of Hello TLVs and acknowledgments, all Babel TLVs With the exception of acknowledgments, all Babel TLVs can be sent to
can be sent to either unicast or multicast addresses, and their either unicast or multicast addresses, and their semantics does not
semantics does not depend on whether the destination is a unicast or depend on whether the destination is a unicast or a multicast
a multicast address. Hence, a Babel speaker does not need to address. Hence, a Babel speaker does not need to determine the
determine the destination address of a packet that it receives in destination address of a packet that it receives in order to
order to interpret it. interpret it.
A moderate amount of jitter may be applied to packets sent by a Babel A moderate amount of jitter may be applied to packets sent by a Babel
speaker: outgoing TLVs are buffered and SHOULD be sent with a small speaker: outgoing TLVs are buffered and SHOULD be sent with a small
random delay. This is done for two purposes: it avoids random delay. This is done for two purposes: it avoids
synchronisation of multiple Babel speakers across a network [JITTER], synchronisation of multiple Babel speakers across a network [JITTER],
and it allows for the aggregation of multiple TLVs into a single and it allows for the aggregation of multiple TLVs into a single
packet. packet.
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. Acknowledgment TLVs MUST be whether it contains any urgent TLVs. Acknowledgment TLVs MUST be
skipping to change at page 13, line 17 skipping to change at page 13, line 17
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
In this section, we give a description of the data structures that In this section, we give a description of the data structures that
every Babel speaker maintains. This description is conceptual: a every Babel speaker maintains. This description is conceptual: a
Babel speaker may use different data structures as long as the Babel speaker may use different data structures as long as the
resulting protocol is the same as the one described in this document. resulting protocol is the same as the one described in this document.
For example, rather than maintaining a single table containing both For example, rather than maintaining a single table containing both
selected and unselected (fallback) routes, as described in selected and unselected (fallback) routes, as described in
Section 3.2.6 belong, an actual implementation would probably use two Section 3.2.6 below, an actual implementation would probably use two
tables, one with selected routes and one with fallback routes. tables, one with selected routes and one with fallback routes.
3.2.1. Sequence number arithmetic 3.2.1. Sequence number arithmetic
Sequence numbers (seqnos) appear in a number of Babel data Sequence numbers (seqnos) appear in a number of Babel data
structures, and they are interpreted as integers modulo 2^16. For structures, and they are interpreted as integers modulo 2^16. For
the purposes of this document, arithmetic on sequence numbers is the purposes of this document, arithmetic on sequence numbers is
defined as follows. defined as follows.
Given a seqno s and an integer n, the sum of s and n is defined by Given a seqno s and an integer n, the sum of s and n is defined by
skipping to change at page 14, line 49 skipping to change at page 14, line 49
some small value n, indicating which of the n hellos most recently some small value n, indicating which of the n hellos most recently
sent by this neighbour have been received by the local node; sent by this neighbour have been received by the local node;
o a history of recently received Unicast Hello packets from this o a history of recently received Unicast Hello packets from this
neighbour; neighbour;
o the "transmission cost" value from the last IHU packet received o the "transmission cost" value from the last IHU packet received
from this neighbour, or FFFF hexadecimal (infinity) if the IHU from this neighbour, or FFFF hexadecimal (infinity) if the IHU
hold timer for this neighbour has expired; hold timer for this neighbour has expired;
o the neighbour's expected incoming Multicast Hello sequence number, o the expected incoming Multicast Hello sequence number for this
an integer modulo 2^16. neighbour, an integer modulo 2^16.
o the neighbour's expected incoming Unicast Hello sequence number, o the expected incoming Unicast Hello sequence number for this
an integer modulo 2^16. neighbour, an integer modulo 2^16.
o the neighbour's outgoing Unicast Hello sequence number, an integer o the outgoing Unicast Hello sequence number for this neighbour, an
modulo 2^16 that is sent with each Unicast Hello TLV to this integer modulo 2^16 that is sent with each Unicast Hello TLV to
neighbour and is incremented (modulo 2^16) whenever a Unicast this neighbour and is incremented (modulo 2^16) whenever a Unicast
Hello is sent. (Note that a neighbour's outgoing Unicast Hello Hello is sent. (Note that the outgoing Unicast Hello seqno for a
seqno is distinct from the interface's outgoing Multicast Hello neighbour is distinct from the interface's outgoing Multicast
seqno.) Hello seqno.)
There are three timers associated with each neighbour entry -- the There are three timers associated with each neighbour entry -- the
multicast hello timer, which is initialised from the interval value multicast hello timer, which is initialised from the interval value
carried by scheduled Multicast Hello TLVs, the unicast hello timer, carried by scheduled Multicast Hello TLVs, the unicast hello timer,
which is initialised from the interval value carried by scheduled which is initialised from the interval value carried by scheduled
Unicast Hello TLVs, and the IHU timer, which is initialised to a Unicast Hello TLVs, and the IHU timer, which is initialised to a
small multiple of the interval carried in IHU TLVs. small 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
skipping to change at page 16, line 39 skipping to change at page 16, line 39
3.2.7. The Table of Pending Seqno Requests 3.2.7. The Table of Pending Seqno Requests
The table of pending seqno requests contains a list of seqno requests The table of pending seqno requests contains a list of seqno requests
that the local node has sent (either because they have been that the local node has sent (either because they have been
originated locally, or because they were forwarded) and to which no originated locally, or because they were forwarded) and to which no
reply has been received yet. This table is indexed by triples of the reply has been received yet. This table is indexed by triples of the
form (prefix, plen, router-id), and every entry in this table form (prefix, plen, router-id), and every entry in this table
contains the following data: contains the following data:
o the prefix, router-id, and seqno being requested; o the prefix, plen, 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 seqno request; it There is one timer associated with each pending seqno request; it
governs both the resending of requests and their expiry. governs both the resending of requests and their expiry.
skipping to change at page 18, line 22 skipping to change at page 18, line 22
not establish a new promise: the deadline carried by the previous not establish a new promise: the deadline carried by the previous
Hello of the same type still applies to the next Hello (if the most Hello of the same type still applies to the next Hello (if the most
recent scheduled Hello of the right kind was received at time t0 and recent scheduled Hello of the right kind was received at time t0 and
carried interval i, then the previous promise of sending another carried interval i, then the previous promise of sending another
Hello before time t0 + i still holds). We say that a Hello is Hello before time t0 + i still holds). We say that a Hello is
"scheduled" if it carries a non-zero interval, and "unscheduled" "scheduled" if it carries a non-zero interval, and "unscheduled"
otherwise. otherwise.
There are two kinds of Hellos: Multicast Hellos, which use a per- There are two kinds of Hellos: Multicast Hellos, which use a per-
interface Hello counter (the Multicast Hello seqno), and Unicast interface Hello counter (the Multicast Hello seqno), and Unicast
Hellos, which use a per-neighbour counter (the Multicast Hello Hellos, which use a per-neighbour counter (the Unicast Hello seqno).
seqno). A Multicast Hello with a given seqno MUST be sent to all A Multicast Hello with a given seqno MUST be sent to all neighbours
neighbours on a given interface, either by sending it to a multicast on a given interface, either by sending it to a multicast address or
address or by sending it to one unicast address per neighbour (hence, by sending it to one unicast address per neighbour (hence, the term
the term "Multicast Hello" is a slight misnomer). A Unicast Hello "Multicast Hello" is a slight misnomer). A Unicast Hello carrying a
carrying a given seqno should normally be sent to just one neighbour given seqno should normally be sent to just one neighbour (over
(over unicast), since the sequence numbers of different neighbours unicast), since the sequence numbers of different neighbours are not
are not in general synchronised. in general synchronised.
Multicast Hellos sent over multicast can be used for neighbour Multicast Hellos sent over multicast can be used for neighbour
discovery; hence, a node SHOULD send periodic (scheduled) Multicast discovery; hence, a node SHOULD send periodic (scheduled) Multicast
Hellos unless neighbour discovery is performed by means outside of Hellos unless neighbour discovery is performed by means outside of
the Babel protocol. A node MAY send Unicast Hellos or unscheduled the Babel protocol. A node MAY send Unicast Hellos or unscheduled
Hellos of either kind for any reason, such as reducing the amount of Hellos of either kind for any reason, such as reducing the amount of
multicast traffic or improving reliability on link technologies with multicast traffic or improving reliability on link technologies with
poor support for link-layer multicast. poor support for link-layer multicast.
A node MAY send a scheduled Hello ahead of time. A node MAY change A node MAY send a scheduled Hello ahead of time. A node MAY change
skipping to change at page 46, line 27 skipping to change at page 46, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix... | Prefix...
+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+
A Seqno Request TLV prompts the receiver to send an Update for a A Seqno Request TLV prompts the receiver to send an Update for a
given prefix with a given sequence number, or to forward the request given prefix with a given sequence number, or to forward the request
further if it cannot be satisfied locally. further if it cannot be satisfied locally.
Fields : Fields :
Type Set to 10 to indicate a Seqno Request message. Type Set to 10 to indicate a Seqno 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.
AE The encoding of the Prefix field. This MUST NOT be 0. AE The encoding of the Prefix field. This MUST NOT be 0.
Plen The length of the requested prefix. Plen The length of the requested prefix.
Seqno The sequence number that is being requested. Seqno The sequence number that is being requested.
skipping to change at page 49, line 47 skipping to change at page 49, line 47
sent from a link-local IPv6 address; since routers don't forward sent from a link-local IPv6 address; since routers don't forward
link-local IPv6 packets, this provides protection against spoofed link-local IPv6 packets, this provides protection against spoofed
Babel packets being sent from the global Internet. No such natural Babel packets being sent from the global Internet. No such natural
protection exists when Babel packets are carried over IPv4. protection exists when Babel packets are carried over IPv4.
7. Acknowledgments 7. Acknowledgments
A number of people have contributed text and ideas to this A number of people have contributed text and ideas to this
specification. The authors are particularly indebted to Matthieu specification. The authors are particularly indebted to Matthieu
Boutier, Gwendoline Chouasne, Margaret Cullen, Donald Eastlake, Toke Boutier, Gwendoline Chouasne, Margaret Cullen, Donald Eastlake, Toke
Hoiland-Jorgensen and Joao Sobrinho. Earlier versions of this Hoiland-Jorgensen, Joao Sobrinho and Martin Vigoureux. Earlier
document greatly benefited from the input of Joel Halpern. The versions of this document greatly benefited from the input of Joel
address compression technique was inspired by [PACKETBB]. Halpern. The address compression technique was inspired by
[PACKETBB].
8. References 8. References
8.1. Normative References 8.1. Normative References
[BABEL-DTLS]
Decimo, A., Schinazi, D., and J. Chroboczek, "Babel
Routing Protocol over Datagram Transport Layer Security",
Internet Draft draft-ietf-babel-dtls-04, February 2019.
[BABEL-HMAC]
Do, C., Kolodziejak, W., and J. Chroboczek, "HMAC
authentication for the Babel routing protocol", Internet
Draft draft-ietf-babel-hmac-04, March 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997. DOI 10.17487/RFC2119, March 1997.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, June 2017.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017. May 2017.
8.2. Informative References 8.2. Informative References
[BABEL-DTLS]
Decimo, A., Schinazi, D., and J. Chroboczek, "Babel
Routing Protocol over Datagram Transport Layer Security",
Internet Draft draft-ietf-babel-dtls-04, February 2019.
[BABEL-HMAC]
Do, C., Kolodziejak, W., and J. Chroboczek, "HMAC
authentication for the Babel routing protocol", Internet
Draft draft-ietf-babel-hmac-04, March 2019.
[DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- [DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination-
Sequenced Distance-Vector Routing (DSDV) for Mobile Sequenced Distance-Vector Routing (DSDV) for Mobile
Computers", ACM SIGCOMM'94 Conference on Communications Computers", ACM SIGCOMM'94 Conference on Communications
Architectures, Protocols and Applications 234-244, 1994. Architectures, Protocols and Applications 234-244, 1994.
[DUAL] Garcia Luna Aceves, J., "Loop-Free Routing Using Diffusing [DUAL] Garcia Luna Aceves, J., "Loop-Free Routing Using Diffusing
Computations", IEEE/ACM Transactions on Networking 1:1, Computations", IEEE/ACM Transactions on Networking 1:1,
February 1993. February 1993.
[EIGRP] Albrightson, B., Garcia Luna Aceves, J., and J. Boyle, [EIGRP] Albrightson, B., Garcia Luna Aceves, J., and J. Boyle,
skipping to change at page 51, line 23 skipping to change at page 51, line 16
periodic routing messages", IEEE/ACM Transactions on periodic routing messages", IEEE/ACM Transactions on
Networking 2, 2, 122-136, April 1994. Networking 2, 2, 122-136, April 1994.
[OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[PACKETBB] [PACKETBB]
Clausen, T., Dearlove, C., Dean, J., and C. Adjih, Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Format", RFC 5444, February 2009. Format", RFC 5444, February 2009.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, June 2017.
[RIP] Malkin, G., "RIP Version 2", RFC 2453, November 1998. [RIP] Malkin, G., "RIP Version 2", RFC 2453, November 1998.
Appendix A. Cost and Metric Computation Appendix A. Cost and Metric Computation
The strategy for computing link costs and route metrics is a local The strategy for computing link costs and route metrics is a local
matter; Babel itself only requires that it comply with the conditions matter; Babel itself only requires that it comply with the conditions
given in Section 3.4.3 and Section 3.5.2. Different nodes may use given in Section 3.4.3 and Section 3.5.2. Different nodes may use
different strategies in a single network and may use different different strategies in a single network and may use different
strategies on different interface types. This section describes the strategies on different interface types. This section describes the
strategies used by the sample implementation of Babel. strategies used by the sample implementation of Babel.
skipping to change at page 56, line 4 skipping to change at page 55, line 50
acknowledgments, by no more than the associated deadline; and other acknowledgments, by no more than the associated deadline; and other
TLVs by no more than one-half the Multicast Hello interval. TLVs by no more than one-half the Multicast Hello interval.
Appendix C. Considerations for protocol extensions Appendix C. Considerations for protocol extensions
Babel is an extensible protocol, and this document defines a number Babel is an extensible protocol, and this document defines a number
of mechanisms that can be used to extend the protocol in a backwards of mechanisms that can be used to extend the protocol in a backwards
compatible manner: compatible manner:
o increasing the version number in the packet header; o increasing the version number in the packet header;
o defining new TLVs;
o defining new TLVs;
o defining new sub-TLVs (with or without the mandatory bit set); o defining new sub-TLVs (with or without the mandatory bit set);
o defining new AEs; o defining new AEs;
o using the packet trailer. o using the packet trailer.
This appendix is intended to guide designers of protocol extensions This appendix is intended to guide designers of protocol extensions
in chosing a particular encoding. in chosing a particular encoding.
The version number in the Babel header should only be increased if The version number in the Babel header should only be increased if
skipping to change at page 61, line 5 skipping to change at page 61, line 5
o Added list of obsoleted drafts to the abstract. o Added list of obsoleted drafts to the abstract.
o Updated references. o Updated references.
F.11. Changes since draft-ietf-babel-rfc6126bis-08 F.11. Changes since draft-ietf-babel-rfc6126bis-08
o Added recommendation that route selection should not take seqnos o Added recommendation that route selection should not take seqnos
into account. into account.
F.12. Changes since draft-ietf-babel-rfc6126bis-09
o Editorial changes only.
Authors' Addresses Authors' Addresses
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. 26 change blocks. 
55 lines changed or deleted 61 lines changed or added

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