< draft-ietf-babel-applicability-09.txt   draft-ietf-babel-applicability-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
Intended status: Informational August 7, 2019 Intended status: Informational August 17, 2019
Expires: February 8, 2020 Expires: February 18, 2020
Applicability of the Babel routing protocol Applicability of the Babel routing protocol
draft-ietf-babel-applicability-09 draft-ietf-babel-applicability-10
Abstract Abstract
Babel is a routing protocol based on the distance-vector algorithm Babel is a routing protocol based on the distance-vector algorithm
augmented with mechanisms for loop avoidance and starvation augmented with mechanisms for loop avoidance and starvation
avoidance. This document describes a number of niches where Babel avoidance. This document describes a number of niches where Babel
has been found to be useful and that are arguably not adequately has been found to be useful and that are arguably not adequately
served by more mature protocols. served by more mature protocols.
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 February 8, 2020. This Internet-Draft will expire on February 18, 2020.
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 2, line 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and background . . . . . . . . . . . . . . . . . 2 1. Introduction and background . . . . . . . . . . . . . . . . . 2
1.1. Technical overview of the Babel protocol . . . . . . . . 2 1.1. Technical overview of the Babel protocol . . . . . . . . 2
2. Properties of the Babel protocol . . . . . . . . . . . . . . 3 2. Properties of the Babel protocol . . . . . . . . . . . . . . 3
2.1. Simplicity and implementability . . . . . . . . . . . . . 3 2.1. Simplicity and implementability . . . . . . . . . . . . . 3
2.2. Robustness . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Robustness . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5
3. Successful deployments of Babel . . . . . . . . . . . . . . . 6 3. Successful deployments of Babel . . . . . . . . . . . . . . . 6
3.1. Heterogeneous networks . . . . . . . . . . . . . . . . . 6 3.1. Heterogeneous networks . . . . . . . . . . . . . . . . . 6
3.2. Large scale overlay networks . . . . . . . . . . . . . . 7 3.2. Large scale overlay networks . . . . . . . . . . . . . . 7
3.3. Pure mesh networks . . . . . . . . . . . . . . . . . . . 7 3.3. Pure mesh networks . . . . . . . . . . . . . . . . . . . 7
3.4. Small unmanaged networks . . . . . . . . . . . . . . . . 7 3.4. Small unmanaged networks . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informational References . . . . . . . . . . . . . . . . 9 7.2. Informational References . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction and background 1. Introduction and background
Babel [RFC6126bis] is a routing protocol based on the familiar Babel [RFC6126bis] is a routing protocol based on the familiar
skipping to change at page 3, line 10 skipping to change at page 3, line 10
convergence in some topologies after a link failure. Babel uses a convergence in some topologies after a link failure. Babel uses a
mechanism pioneered by EIGRP [DUAL] [RFC7868], known as mechanism pioneered by EIGRP [DUAL] [RFC7868], known as
"feasibility", which avoids routing loops and therefore makes "feasibility", which avoids routing loops and therefore makes
counting to infinity impossible. counting to infinity impossible.
Feasibility is a conservative mechanism, one that not only avoids all Feasibility is a conservative mechanism, one that not only avoids all
looping routes but also rejects some loop-free routes. Thus, it can looping routes but also rejects some loop-free routes. Thus, it can
lead to a situation known as "starvation", where a router rejects all lead to a situation known as "starvation", where a router rejects all
routes to a given destination, even those that are loop-free. In routes to a given destination, even those that are loop-free. In
order to recover from starvation, Babel uses a mechanism pioneered by order to recover from starvation, Babel uses a mechanism pioneered by
DSDV [DSDV] and known as "sequenced routes". In Babel, this the Destination-Sequenced Distance-Vector Routing Protocol (DSDV)
mechanism is generalised to deal with prefixes of arbitrary length [DSDV] and known as "sequenced routes". In Babel, this mechanism is
and routes announced at multiple points in a single routing domain generalised to deal with prefixes of arbitrary length and routes
(DSDV was a pure mesh protocol, and only dealt with host routes). announced at multiple points in a single routing domain (DSDV was a
pure mesh protocol, and only carried host routes).
In DSDV, the sequenced routes algorithm is slow to react to a In DSDV, the sequenced routes algorithm is slow to react to a
starvation episode. In Babel, starvation recovery is accelerated by starvation episode. In Babel, starvation recovery is accelerated by
using explicit requests (known as "seqno requests" in the protocol) using explicit requests (known as "seqno requests" in the protocol)
that signal a starvation episode and cause a new sequenced route to that signal a starvation episode and cause a new sequenced route to
be propagated in a timely manner. In the absence of packet loss, be propagated in a timely manner. In the absence of packet loss,
this mechanism is provably complete and clears the starvation in time this mechanism is provably complete and clears the starvation in time
proportional to the diameter of the network, at the cost of some proportional to the diameter of the network, at the cost of some
additional signalling traffic. additional signalling traffic.
skipping to change at page 4, line 39 skipping to change at page 4, line 39
transitive links, unstable link costs, etc.) is likely not to transitive links, unstable link costs, etc.) is likely not to
violate the assumptions of the protocol; violate the assumptions of the protocol;
o robust with respect to novel metrics: an unusual metric o robust with respect to novel metrics: an unusual metric
(continuous, constantly fluctuating, etc.) is likely not to (continuous, constantly fluctuating, etc.) is likely not to
violate the assumptions of the protocol. violate the assumptions of the protocol.
Section 3 below gives examples of successful deployments of Babel Section 3 below gives examples of successful deployments of Babel
that illustrate these properties. that illustrate these properties.
In addition to the above, our implementation experience indicates
that Babel tends to be robust with respect to bugs: in many cases, an
implementation bug does not violate the properties on which Babel
relies, and therefore slows down convergence or causes sub-optimal
routing rather than causing the network to collapse.
These robustness properties have important consequences for the These robustness properties have important consequences for the
applicability of the protocol: Babel works (more or less efficiently) applicability of the protocol: Babel works (more or less efficiently)
in a range of circumstances where traditional routing protocols don't in a range of circumstances where traditional routing protocols don't
work well (or at all). work well (or at all).
2.3. Extensibility 2.3. Extensibility
Babel's packet format has a number of features that make the protocol Babel's packet format has a number of features that make the protocol
extensible (see Appendix C of [RFC6126bis]), and a number of extensible (see Appendix C of [RFC6126bis]), and a number of
extensions have been designed to make Babel work better in situations extensions have been designed to make Babel work better in situations
skipping to change at page 5, line 33 skipping to change at page 5, line 23
o source-specific routing (SADR) [BABEL-SS] allows forwarding to o source-specific routing (SADR) [BABEL-SS] allows forwarding to
take a packet's source address into account, thus enabling a cheap take a packet's source address into account, thus enabling a cheap
form of multihoming [SS-ROUTING]; form of multihoming [SS-ROUTING];
o RTT-based routing [BABEL-RTT] minimises link delay, which is o RTT-based routing [BABEL-RTT] minimises link delay, which is
useful in overlay network (where both hop count and packet loss useful in overlay network (where both hop count and packet loss
are poor metrics). are poor metrics).
Some other extensions have been designed, but have not seen Some other extensions have been designed, but have not seen
deployment yet (and their usefulness is yet to be demonstrated): deployment in production (and their usefulness is yet to be
demonstrated):
o frequency-aware routing [BABEL-Z] aims to minimise radio o frequency-aware routing [BABEL-Z] aims to minimise radio
interference in wireless networks; interference in wireless networks;
o ToS-aware routing [BABEL-TOS] allows routing to take a packet's o ToS-aware routing [BABEL-TOS] allows routing to take a packet's
ToS marking into account for selected routes without incurring the ToS marking into account for selected routes without incurring the
full cost of a multi-topology routing protocol. full cost of a multi-topology routing protocol.
2.4. Limitations 2.4. Limitations
Babel has some undesirable properties that make it suboptimal or even Babel has some undesirable properties that make it suboptimal or even
unusable in some deployments. unusable in some deployments.
2.4.1. Periodic updates 2.4.1. Periodic updates
The main mechanisms used by Babel to reconverge after a topology The main mechanisms used by Babel to reconverge after a topology
change are reactive: triggered updates, triggered retractions and change are reactive: triggered updates, triggered retractions and
explicit requests. However, in the presence of heavy packet loss, explicit requests. However, Babel relies on periodic updates to
Babel relies on periodic updates to clear pathologies. This reliance clear pathologies after a mobility event or in the presence of heavy
on periodic updates makes Babel unsuitable in at least two kinds of packet loss. The use of periodic updates makes Babel unsuitable in
deployments: at least two kinds of environments:
o large, stable networks: since Babel sends periodic updates even in o large, stable networks: since Babel sends periodic updates even in
the absence of topology changes, in well-managed, large, stable the absence of topology changes, in well-managed, large, stable
networks the amount of control traffic will be reduced by using a networks the amount of control traffic will be reduced by using a
protocol that uses a reliable transport (such as OSPF, IS-IS or protocol that uses a reliable transport (such as OSPF, IS-IS or
EIGRP); EIGRP);
o low-power networks: the periodic updates use up battery power even o low-power networks: the periodic updates use up battery power even
when there are no topology changes and no user traffic, which when there are no topology changes and no user traffic, which
makes Babel wasteful in low-power networks. makes Babel wasteful in low-power networks.
2.4.2. Full routing table 2.4.2. Full routing table
While there exist techniques that allow a Babel speaker to function While there exist techniques that allow a Babel speaker to function
with a partial routing table (e.g., by learning just a default route with a partial routing table (e.g., by learning just a default route
or, more generally, performing route aggregation), Babel is designed or, more generally, performing route aggregation), Babel is designed
around the assumption that every router has a full routing table. In around the assumption that every router has a full routing table. In
networks where some nodes are too constrained to hold a full routing networks where some nodes are too constrained to hold a full routing
table, it might be preferable to use a protocol that was designed table, it might be preferable to use a protocol that was designed
from the outset to work with a partial routing table (such as AODVv2 from the outset to work with a partial routing table (such as AODV
[AODVv2], RPL [RFC6550] or LOADng [LOADng]). [RFC3561], RPL [RFC6550] or LOADng [LOADng]).
2.4.3. Slow aggregation 2.4.3. Slow aggregation
Babel's loop-avoidance mechanism relies on making a route unreachable Babel's loop-avoidance mechanism relies on making a route unreachable
after a retraction until all neighbours have been guaranteed to have after a retraction until all neighbours have been guaranteed to have
acted upon the retraction, even in the presence of packet loss. acted upon the retraction, even in the presence of packet loss.
Unless the optional algorithm described in Section 3.5.5 of Unless the second algorithm described in Section 3.5.5 of
[RFC6126bis] is implemented, this entails that a node is unreachable [RFC6126bis] is implemented, this entails that a node is unreachable
for a few minutes after the most specific route to it has been for a few minutes after the most specific route to it has been
retracted. This delay may make Babel slow to recover from a topology retracted. This delay makes Babel slow to recover from a topology
change in networks that perform automatic route aggregation. change in networks that perform automatic route aggregation.
3. Successful deployments of Babel 3. Successful deployments of Babel
This section gives a few examples of environments where Babel has This section gives a few examples of environments where Babel has
been successfully deployed. been successfully deployed.
3.1. Heterogeneous networks 3.1. Heterogeneous networks
Babel is able to deal with both classical, prefix-based ("Internet- Babel is able to deal with both classical, prefix-based ("Internet-
skipping to change at page 7, line 22 skipping to change at page 7, line 14
combine a wired, aggregated backbone with meshy wireless bits at the combine a wired, aggregated backbone with meshy wireless bits at the
edges. edges.
Efficient operation in heterogeneous networks requires the Efficient operation in heterogeneous networks requires the
implementation to distinguish between wired and wireless links, and implementation to distinguish between wired and wireless links, and
to perform link quality estimation on wireless links. to perform link quality estimation on wireless links.
3.2. Large scale overlay networks 3.2. Large scale overlay networks
The algorithms used by Babel (loop avoidance, hysteresis, delayed The algorithms used by Babel (loop avoidance, hysteresis, delayed
updates) allow it to remain stable and efficient in the presence of updates) allow it to remain stable in the presence of unstable
unstable metrics, even in the presence of a feedback loop. For this metrics, even in the presence of a feedback loop. For this reason,
reason, it has been successfully deployed in large scale overlay it has been successfully deployed in large scale overlay networks,
networks, built out of thousands of tunnels spanning continents, built out of thousands of tunnels spanning continents, where it is
where it is used with a metric computed from links' latencies. used with a metric computed from links' latencies.
This particular application depends on the extension for RTT- This particular application depends on the extension for RTT-
sensitive routing [DELAY-BASED]. sensitive routing [DELAY-BASED].
3.3. Pure mesh networks 3.3. Pure mesh networks
While Babel is a general-purpose routing protocol, it has been While Babel is a general-purpose routing protocol, it has been shown
repeatedly shown to be competitive with dedicated routing protocols to be competitive with dedicated routing protocols for wireless mesh
for wireless mesh networks [REAL-WORLD] [BRIDGING-LAYERS]. Although networks [REAL-WORLD] [BRIDGING-LAYERS]. Although this particular
this particular niche is already served by a number of mature niche is already served by a number of mature protocols, notably
protocols, notably OLSR-ETX and OLSRv2 [RFC7181] (equipped e.g. with OLSR-ETX and OLSRv2 [RFC7181] (equipped e.g. with the DAT metric
the DAT metric [RFC7779]), Babel has seen a moderate amount of [RFC7779]), Babel has seen a moderate amount of successful deployment
successful deployment in pure mesh networks. in pure mesh networks.
3.4. Small unmanaged networks 3.4. Small unmanaged networks
Because of its small size and simple configuration, Babel has been Because of its small size and simple configuration, Babel has been
deployed in small, unmanaged networks (e.g., home and small office deployed in small, unmanaged networks (e.g., home and small office
networks), where it serves as a more efficient replacement for RIP networks), where it serves as a more efficient replacement for RIP
[RFC2453], over which it has two significant advantages: the ability [RFC2453], over which it has two significant advantages: the ability
to route multiple address families (IPv6 and IPv4) in a single to route multiple address families (IPv6 and IPv4) in a single
protocol instance, and good support for using wireless links for protocol instance, and good support for using wireless links for
transit. transit.
skipping to change at page 8, line 16 skipping to change at page 8, line 11
This document requires no IANA actions. [RFC Editor: please remove This document requires no IANA actions. [RFC Editor: please remove
this section before publication.] this section before publication.]
5. Security Considerations 5. Security Considerations
As is the case in all distance-vector routing protocols, a Babel As is the case in all distance-vector routing protocols, a Babel
speaker receives reachability information from its neighbours, which speaker receives reachability information from its neighbours, which
by default is trusted by all nodes in the routing domain. by default is trusted by all nodes in the routing domain.
In most deployments, the Babel protocol is run over a network that is At the time of writing, the Babel protocol is usually run over a
secured either at the physical layer (e.g., physically protecting network that is secured either at the physical layer (e.g.,
Ethernet sockets) or at the link layer (using a protocol such as WiFi physically protecting Ethernet sockets) or at the link layer (using a
Protected Access (WPA2)). If Babel is being run over an unprotected protocol such as WiFi Protected Access (WPA2)). If Babel is being
network, then the routing traffic needs to be protected using a run over an unprotected network, then the routing traffic needs to be
sufficiently strong cryptographic mechanism. protected using a sufficiently strong cryptographic mechanism.
At the time of writing, two such mechanisms have been defined. At the time of writing, two such mechanisms have been defined.
Babel-HMAC [HMAC] is a simple and easy to implement mechanism that Babel-MAC [BABEL-MAC] is a simple and easy to implement mechanism
only guarantees authenticity, integrity and replay protection of the that only guarantees authenticity, integrity and replay protection of
routing traffic, and only supports symmetric keying with a small the routing traffic, and only supports symmetric keying with a small
number of keys (typically just one or two). Babel-DTLS [DTLS] is a number of keys (typically just one or two). Babel-DTLS [BABEL-DTLS]
more complex mechanism, that requires some minor changes to be made is a more complex mechanism, that requires some minor changes to be
to a typical Babel implementation and depends on a DTLS stack being made to a typical Babel implementation and depends on a DTLS stack
available, but inherits all of the features of DTLS, notably being available, but inherits all of the features of DTLS, notably
confidentiality, optional replay protection, and the ability to use confidentiality, optional replay protection, and the ability to use
asymmetric keys. asymmetric keys.
Due to its simplicity, Babel-HMAC should be the preferred security Due to its simplicity, Babel-MAC should be the preferred security
mechanism in most deployments, with Babel-DTLS available for networks mechanism in most deployments, with Babel-DTLS available for networks
that require its additional features. that require its additional features.
In addition to the above, the information that a mobile Babel node
announces to the whole routing domain is often sufficient to
determine a mobile node's physical location with reasonable
precision. This might make Babel unapplicable in scenarios where a
node's location is considered confidential.
6. Acknowledgments 6. Acknowledgments
The author is indebted to Jean-Paul Smetz and Alexander Vainshtein The author is indebted to Jean-Paul Smetz and Alexander Vainshtein
for their input to this document. for their input to this document.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC6126bis] [RFC6126bis]
Chroboczek, J. and D. Schinazi, "The Babel Routing Chroboczek, J. and D. Schinazi, "The Babel Routing
Protocol", Internet Draft draft-ietf-babel-rfc6126bis-07, Protocol", Internet Draft draft-ietf-babel-rfc6126bis-14,
November 2018. August 2019.
7.2. Informational References 7.2. Informational References
[AODVv2] Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and [BABEL-DTLS]
V. Mercieca, "Ad Hoc On-demand Distance Vector Version 2 Decimo, A., Schinazi, D., and J. Chroboczek, "Babel
(AODVv2) Routing", draft-ietf-manet-aodvv2-16 (work in Routing Protocol over Datagram Transport Layer Security",
progress), May 2016. Internet Draft draft-ietf-babel-dtls-09, August 2019.
[BABEL-MAC]
Do, C., Kolodziejak, W., and J. Chroboczek, "MAC
authentication for the Babel routing protocol", Internet
Draft draft-ietf-babel-hmac-10, August 2019.
[BABEL-RTT] [BABEL-RTT]
Jonglez, B. and J. Chroboczek, "Delay-based Metric Jonglez, B. and J. Chroboczek, "Delay-based Metric
Extension for the Babel Routing Protocol", draft-jonglez- Extension for the Babel Routing Protocol", draft-jonglez-
babel-rtt-extension-01 (work in progress), May 2015. babel-rtt-extension-01 (work in progress), May 2015.
[BABEL-SS] [BABEL-SS]
Boutier, M. and J. Chroboczek, "Source-Specific Routing in Boutier, M. and J. Chroboczek, "Source-Specific Routing in
Babel", draft-ietf-babel-source-specific-04 (work in Babel", draft-ietf-babel-source-specific-04 (work in
progress), October 2018. progress), October 2018.
skipping to change at page 9, line 45 skipping to change at page 9, line 50
[DELAY-BASED] [DELAY-BASED]
Jonglez, B. and J. Chroboczek, "A delay-based routing Jonglez, B. and J. Chroboczek, "A delay-based routing
metric", March 2014, <http://arxiv.org/abs/1403.3488>. metric", March 2014, <http://arxiv.org/abs/1403.3488>.
[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.
[DTLS] Decimo, A., Schinazi, D., and J. Chroboczek, "Babel
Routing Protocol over Datagram Transport Layer Security",
draft-ietf-babel-dtls-07 (work in progress), July 2019.
[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.
[HMAC] Do, C., Kolodziejak, W., and J. Chroboczek, "HMAC
authentication for the Babel routing protocol", draft-
ietf-babel-hmac-07 (work in progress), June 2019.
[LOADng] Clausen, T., Verdiere, A., Yi, J., Niktash, A., Igarashi, [LOADng] Clausen, T., Verdiere, A., Yi, J., Niktash, A., Igarashi,
Y., Satoh, H., Herberg, U., Lavenu, C., Lys, T., and J. Y., Satoh, H., Herberg, U., Lavenu, C., Lys, T., and J.
Dean, "The Lightweight On-demand Ad hoc Distance-vector Dean, "The Lightweight On-demand Ad hoc Distance-vector
Routing Protocol - Next Generation (LOADng)", draft- Routing Protocol - Next Generation (LOADng)", draft-
clausen-lln-loadng-15 (work in progress), January 2017. clausen-lln-loadng-15 (work in progress), January 2017.
[METAROUTING] [METAROUTING]
Griffin, T. and J. Sobrinho, "Metarouting", 2005. Griffin, T. and J. Sobrinho, "Metarouting", 2005.
In Proceedings of the 2005 conference on Applications, In Proceedings of the 2005 conference on Applications,
skipping to change at page 10, line 34 skipping to change at page 10, line 30
performance of current proactive multi-hop mesh performance of current proactive multi-hop mesh
protocols", Asia-Pacific Conference on Communication 2009, protocols", Asia-Pacific Conference on Communication 2009,
2009. 2009.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November
1998. 1998.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561,
DOI 10.17487/RFC3561, July 2003,
<https://www.rfc-editor.org/info/rfc3561>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, March 2012. Low-Power and Lossy Networks", RFC 6550, March 2012.
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol Version 2", "The Optimized Link State Routing Protocol Version 2",
 End of changes. 23 change blocks. 
65 lines changed or deleted 69 lines changed or added

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