Internet DRAFT - draft-mrw-homenet-rtg-comparison
draft-mrw-homenet-rtg-comparison
Homenet Working Group M. Wasserman
Internet-Draft Painless Security
Intended status: Informational C. Hopps
Expires: September 6, 2015 Deutsche Telekom
J. Chroboczek
University of Paris-Diderot (Paris 7)
March 5, 2015
Homenet IS-IS and Babel Comparison
draft-mrw-homenet-rtg-comparison-02.txt
Abstract
This document is intended to provide information to members of the
IETF Home Networks Working Group (Homenet WG), so that we can make an
informed decision regarding which routing protocol to use in home
networks. The routing protocols compared in this document are: The
Babel Routing Protocol (Babel) and The Intermediate System to
Intermediate System Intra-Domain Routing Protocol (IS-IS).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Wasserman, et al. Expires September 6, 2015 [Page 1]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocols and Extensions Included in Comparison . . . . . . . 5
2.1. IS-IS Protocol and Extensions . . . . . . . . . . . . . . 5
2.2. Babel Protocol and Extensions . . . . . . . . . . . . . . 6
3. Routing Algorithms . . . . . . . . . . . . . . . . . . . . . 6
3.1. Link State Algorithm . . . . . . . . . . . . . . . . . . 6
3.2. Loop-Avoiding Distance-Vector Algorithm (Babel) . . . . . 6
3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7
4. Convergence Times . . . . . . . . . . . . . . . . . . . . . . 7
4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Babel . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8
5. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 8
5.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Babel . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8
6. Support for Source-Specific Routing . . . . . . . . . . . . . 9
6.1. Source-Specific Routing in IS-IS . . . . . . . . . . . . 9
6.2. Source-Specific Routing in Babel . . . . . . . . . . . . 9
6.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 9
7. Support for Link Metrics . . . . . . . . . . . . . . . . . . 10
7.1. Link Metrics in IS-IS . . . . . . . . . . . . . . . . . . 10
7.2. Link Metrics in Babel . . . . . . . . . . . . . . . . . . 10
7.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 11
8. Support for Stub Networks and Stub Routers . . . . . . . . . 11
8.1. IS-IS Support for Stub Networks and Stub Routers . . . . 12
8.2. Babel Support for Stub Networks . . . . . . . . . . . . . 12
8.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 13
9. Support for non-IEEE 802.2 link layers . . . . . . . . . . . 13
9.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.2. Babel . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Security Features . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Security Features in IS-IS . . . . . . . . . . . . . . . 13
10.2. Security Features in Babel . . . . . . . . . . . . . . . 13
10.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 14
11. Support for Multicast . . . . . . . . . . . . . . . . . . . . 14
11.1. Multicast Routing in IS-IS . . . . . . . . . . . . . . . 14
11.2. Multicast Routing in Babel . . . . . . . . . . . . . . . 14
11.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 14
12. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
13. Code and State Size . . . . . . . . . . . . . . . . . . . . . 15
Wasserman, et al. Expires September 6, 2015 [Page 2]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
13.1. IS-IS Code and State Size . . . . . . . . . . . . . . . 15
13.2. Babel Code and State Size . . . . . . . . . . . . . . . 15
13.3. Comparison . . . . . . . . . . . . . . . . . . . . . . . 16
14. Ease of porting . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. IS-IS ease of porting . . . . . . . . . . . . . . . . . 17
14.2. Babel ease of porting . . . . . . . . . . . . . . . . . 17
14.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 18
15. Behaviour upon resource exhaustion . . . . . . . . . . . . . 18
15.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . 18
15.2. Babel . . . . . . . . . . . . . . . . . . . . . . . . . 18
16. Performance and scaling on IEEE 802.11 Wireless Networks . . 18
16.1. IS-IS Performance on 802.11 . . . . . . . . . . . . . . 19
16.2. Babel Performance on 802.11 . . . . . . . . . . . . . . 19
16.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 20
17. Standardization Status . . . . . . . . . . . . . . . . . . . 20
17.1. IS-IS Standardization . . . . . . . . . . . . . . . . . 20
17.2. Babel Standardization Status . . . . . . . . . . . . . . 20
18. Evaluation of RFC 7368 Criteria . . . . . . . . . . . . . . . 21
19. Evaluation of RFC 5218 Criteria . . . . . . . . . . . . . . . 22
19.1. Critical Success Factors . . . . . . . . . . . . . . . . 22
19.1.1. IS-IS Success Factors . . . . . . . . . . . . . . . 22
19.1.2. Babel Success Factors . . . . . . . . . . . . . . . 23
19.2. Willing Implementors . . . . . . . . . . . . . . . . . . 24
19.2.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 24
19.2.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 24
19.3. Willing Customers . . . . . . . . . . . . . . . . . . . 24
19.3.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 24
19.3.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 24
19.4. Potential Niches . . . . . . . . . . . . . . . . . . . . 25
19.4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 25
19.4.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 25
19.5. Complexity Removal . . . . . . . . . . . . . . . . . . . 25
19.5.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 25
19.5.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 25
19.6. Killer App . . . . . . . . . . . . . . . . . . . . . . . 25
19.6.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 26
19.6.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 26
19.7. Extensible . . . . . . . . . . . . . . . . . . . . . . . 26
19.7.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 26
19.7.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 26
19.8. Success Predictable . . . . . . . . . . . . . . . . . . 27
19.8.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 27
19.8.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 27
20. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
21. Informative References . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
Wasserman, et al. Expires September 6, 2015 [Page 3]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
1. Introduction
This document compares IS-IS (ISO/IEC 10589:2002) [ISO10589] and
Babel [RFC6126] according to several criteria related to their use in
home networks (Homenets), as defined by the Homenet WG.
[There has been a request that this document compare OSPF as well as
Babel and IS-IS. If the WG would find that useful, we would need an
OSPF expert who is willing to provide text on OSPF similar to the
information that has been provided for IS-IS and Babel.]
Please note that this document does not represent the consenus of any
group, not even the authors. It is an organized collection of facts
and well-informed opinions provided by experts on Babel and IS-IS
that may be useful to the Homenet WG in choosing a routing protocol.
The Homenet environment is different from the environment of a
professionally administered network. The most obvious difference is
that most home networks are not administered: any protocols used must
be robust and fully self-configuring, and any tuning knobs that they
provide will be unused in the vast majority of deployments. There
may be exceptions to the "no configuration" rule in some
environments. For instance, Homenet products may be used in
environments where network security is important enough to warrant
the configuration of security information, such as keys or
certificates. However, even in those environments, minimal
configuration should be necessary to deploy a Homenet network.
Another difference is that Homenets are usually built out of a
specific class of cheap device, the "Plastic Home Router". A Plastic
Home Router's firmware is installed at the factory, and is most
likely never updated. Additionally, experience shows that home
routers are often used way beyond their warranty period, and even
after their manufacturer leaves the router business. This, again,
argues in favour of simple, robust protocols that are easy to
implement and can be expected to keep functioning without software
updates.
A Plastic Home Router is usually equipped with a reasonable CPU but
fairly small amounts of flash and RAM. At the time of writing, a
typical example of the bottom of the range has a 200MHz MIPS 4KEc CPU
(8kB data cache), but only 4MB of flash and 8MB of RAM. More
expensive multi-purpose products may have a 700MHz MIPS 24Kc with
32MB of flash and as much as 128MB of RAM.
We expect smaller devices to want to participate in the Homenet
protocols. In particular, some vendors have expressed interest in
producing sensor-class hardware that is able to interoperate with
Wasserman, et al. Expires September 6, 2015 [Page 4]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
Homenet (smart thermostats, home automation hardware, etc.). It is
therefore desirable to be able to scale down the Homenet protocols
down to a few tens of kB, at least in a stub role.
Homenets are built and grow organically, and often end up consisting
of multiple link technologies with widely different performance
characteristics (twisted-pair Ethernet at gigabit speed, IEEE 802.11
(WiFi) and its multiple variants, Powerline Ethernet, etc.). It is
desirable for a Homenet routing protocol to be able to dynamically
optimise paths according to the link characteristics.
Experts appear to disagree on the expected size of a Homenet: we have
heard estimates ranging from just one router up to 250 routers. In
any case, while scaling beyond a few thousand nodes is not likely to
be relevant to Homenet in the foreseeable future, the Homenet
protocols, if successful, will be repurposed to larger networks,
whether we like it or not, and it is desirable to use a protocol that
scales well.
2. Protocols and Extensions Included in Comparison
Both the IS-IS and Babel protocols are updated and extended over
time. This section lists the extensions that were considered in this
comparison. Additional protocol extensions could affect some of the
information included in this document.
2.1. IS-IS Protocol and Extensions
In addition to the base IS-IS protocol specification [ISO10589], this
comparison considers the following IS-IS extensions:
Homenet related specifications
o ISIS Auto-Configuration [ISIS-AUTOCONF];
o Source-Specific routing in IS-IS [ISIS-SS].
Base protocol specifications.
o Use of OSI IS-IS for Routing in TCP/IP and Dual Environments
[RFC1195]
o IS-IS Extensions for Traffic Engineering [RFC5305]
o Routing IPv6 with IS-IS [RFC5308]
Wasserman, et al. Expires September 6, 2015 [Page 5]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
2.2. Babel Protocol and Extensions
In addition to the base Babel Protocol specification (RFC 6126), this
comparison considers the following Babel extensions:
o Extension Mechanism for the Babel Routing Protocol [BABEL-EXT];
o Source-Specific Routing [BABEL-SS], described in more detail in
[SS-ROUTING].
3. Routing Algorithms
IS-IS is a Link State routing protocol, and Babel is a Loop-Avoiding
Distance Vector routing protocol. There are some differences between
these algorithms, particularly in terms of scalability, how much
information is exchanged when the routing topology changes, and how
far topology changes are propagated.
3.1. Link State Algorithm
Link state algorithms distribute information for each node to all
other nodes in the network using a flooding algorithm. This database
of information is then used by each node to compute the best path to
the other nodes in the network.
One benefit of this algorithm is that each node contains the full
knowledge of the topology of the network. This information can be
used by other applications outside the routing protocol itself.
Additionally the flooding algorithm has been found as an efficient
method for other applications to distribute node-specific application
data, although some care must be taken with this use so as not to
disrupt the fundamental routing function.
3.2. Loop-Avoiding Distance-Vector Algorithm (Babel)
Distance-vector algorithms distribute information about the path
length to reach each destination through a given neighbor. Packets
are forwarded through the neighbor that is advertising the best path
towards the destination.
Babel, like EIGRP, DSDV, and to a certain extent BGP, uses a loop-
avoiding distance-vector algorithm: it avoids creating a loop even
during reconvergence, there is no "counting to infinity", and even
short-lived "microloops" are avoided in most cases.
Wasserman, et al. Expires September 6, 2015 [Page 6]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
3.3. Discussion
From a purely algorithmic point of view, both kinds of algorithms are
known to scale well beyond the needs of Homenet. Issues of scaling
over wireless and lossy links is discussed in Section 16.
4. Convergence Times
Convergence time is defined as the amount of time after a link
failure is detected during which the network is not fully
operational. It does not include the time necessary to detect a link
failure.
4.1. IS-IS
Given fast flooding of any change in the network, IS-IS has been
shown to acheive sub 200ms end-to-end convergence even in very large
provider networks (single area 900+ nodes). Basically the time for
convergence is the time to propagate new link state from one end of
the network to the other plus the SPF (tree computation interval) and
FIB loading time. The flooding is done without delay and prior to
running the SPF (tree-calculation) algorithm. Thus is roughly
proportional to propagation delay across the diameter of the network.
The tree calculation is sub 20ms on modern CPUs. FIB load time
depends on the FIB hardware and design and not the routing protocol
choice.
[According to Gredler, "today, 1000-2000 routers in a single area are
said to represent the upper boundary of IS-IS [...] The authors do
not endorse these optimistic area numbers, since a lot is dependent
on other factors than just the raw number of routers." (p. 84). And
I'm pretty sure he's not thinking of 200MHz CPUs with 8kB data
caches, 802.11 and powerline. -- jch]
We easily should expect sub-second convergence for any change in
reachability (addition or subtraction) in any conceivable Homenet
deployment that does not use IEEE 802.11 for router-to-router links
(see Section 16).
4.2. Babel
Since Babel maintains a redundant routing table, it is most often
able to reconverge almost instantaneously after a link failure (this
is similar to e.g. EIGRP). In the case where no feasible routes are
available, Babel reconverges in 20ms per hop to the source.
Wasserman, et al. Expires September 6, 2015 [Page 7]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
4.3. Discussion
Both protocols enjoy fast convergence. However, the time needed to
reconverge is dwarfed by the amount of time needed to detect a link
failure, which is the hold time in IS-IS (30s by default), and 2.5
hello intervals on Babel wired links (2.5*4s, i.e. 10s by default).
(Babel performs link quality estimation on wireless links, so the
delay is a little higher when wireless links are involved.)
This can be mitigated somewhat by using smaller timers, at the cost
of higher overhead, especially on wireless links, which tend to
suffer from abominable per-frame overhead. IS-IS supports hold times
as small as 1s, while Babel supports hello intervals as low as 10ms
(leading to a 25ms hold time). (Either protocol could of course be
combined with BFD, which supports arbitrarily small hold times.)
It has been suggested that physical layer carrier sense could be used
to detect broken links in a timely manner. Unfortunately, this
technique is not useful in Homenet, since most Plastic Home Routers
put their Ethernet ports behind an internal switch in order to
provide 5 or more Ethernet ports using a single NIC: carrier sense
indicates the status of the internal link to the switch, not that of
the user-visible Ethernet link. Carrier sense has also been found to
be unreliable on wireless links.
5. Autoconfiguration
Most home networks are not administered, so a routing protocol needs
to be entirely self-configuring in order to be suitable for Homenets.
5.1. IS-IS
The only required configuration for IS-IS is a unique area/system
identifier. The Homenet implementation of IS-IS uses an
autoconfiguration extension defined in an Internet Draft
[ISIS-AUTOCONF], to set this value.
5.2. Babel
Babel is a fully self-configuring protocol -- the standard
implementation of Babel only requires a list of interfaces in order
to start routing.
5.3. Discussion
When combined with HNCP, both protocols are able to run in an
unadministered network (but see also Section 7).
Wasserman, et al. Expires September 6, 2015 [Page 8]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
6. Support for Source-Specific Routing
Source-Specific Routing is a hard requirement for Homenets, as it
will allow traffic to be routed to the correct outbound network based
on host source address selection. Routing packets to the wrong
outbound network could result in packets being dropped due to ISP
ingress filtering rules.
Both Babel and IS-IS have extensions for source-specific routing.
6.1. Source-Specific Routing in IS-IS
IS-IS support for source specific routing is implemented with the
addition of a sub-TLV to a reachability (prefix) TLV. The
implementation assumes that all IS-IS routers have support for the
sub-TLV. This assumption is safe to make due to the requirement that
all homenet IS-IS routers also use a homenet specific area ID and
cleartext password. Mixing in IS-IS routers without support for
source specific routing is not supported as it may cause routing
loops.
6.2. Source-Specific Routing in Babel
The Source-specific extension to the Babel routing protocol
[BABEL-SS] has been implemented for over a year, has been made widely
available and has seen a fair amount deployment as part of OpenWRT
and CeroWRT. The source-specific code is currently in the process of
being merged into the standard Babel implementation, and is scheduled
to be included in version 1.6 (planned for March 2015).
Babel's source-specific extensions were carefully designed so that
source-specific and ordinary (non-specific) routers can coexist in a
single routing domain, without causing routing loops. However,
unless there is a connected backbone of source-specific routers, any
non-specific routers present in the Homenet may experience
blackholes. Interoperability between plain Babel and Source-Specific
Babel is described in detail in Section VI.A of [SS-ROUTING].
6.3. Discussion
Both protocols have been extended with support for source-specific
routing. The IS-IS extension is not able to coexist with non-
extended implementations, but this is probably not a serious problem
for Homenet.
Wasserman, et al. Expires September 6, 2015 [Page 9]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
7. Support for Link Metrics
Typical Homenets are built out of multiple link technologies with
very different performance characteristics -- Gigabit Ethernet can
easily have three orders of magnitude higher throughput than a
marginal wireless link. Both IS-IS and Babel model the notion of
greater or lesser desirability of a link by a value called a metric;
the smaller the metric, the more desirable the link.
The following example illustrates the importance of assigning
suitable metrics to links in a home network:
Internet --- A --- B....C --- is Ethernet
. . ... is WiFi
........
A is the CPE (edge router), and lives in a storeroom. B is the
home's main router, lives in the living room, and is connected to A
over Ethernet. C is a wireless router in the guest room, or perhaps
in the garden shed. All the routers are equipped with wireless
interfaces.
Suppose that the wireless link B..C is solid, but the longer A..C
link has very high packet loss. Murphy's law dictates that the link
A..C will be just good enough for the routing instances on A and C to
become neighbours. If the routing protocol doesn't take link quality
into account in its metric computation, even if it is smart enough to
prefer wired links to wireless ones, it will prefer the lossy route
A..C to the solid route A-B..C.
7.1. Link Metrics in IS-IS
The Homenet implementation of IS-IS uses the wide-metric (24-bit)
link metric. Additionally IS-IS includes multi-topology support
allowing for a variable number of metrics per link, as well as per-
link and per-prefix tags allowing for coloring of links and
reachability, and finally per-link and per-prefix sub-tlv's allowing
for any future additional extensions.
7.2. Link Metrics in Babel
Since Babel was originally designed for heterogeneous networks, the
protocol is able to automatically include a number of sources of
information in its metric computation. The current implementation is
able to automatically take the following criteria into account:
o whether a link is wired or wireless;
Wasserman, et al. Expires September 6, 2015 [Page 10]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
o packet loss;
o link latency [BABEL-RTT];
o intra-route radio interference [BABEL-Z].
This wealth of information can produce conflicting data in edge
cases. Babel's loop-avoidance mechanisms ensure that the network
remains in a consistent state in all cases, and a hysteresis
mechanism ensures that, should a feedback loop occur, the frequency
of oscillations remains bounded [DELAY-BASED].
7.3. Discussion
Babel has reasonably good support for dynamically computed metrics
for IEEE 802.11 links and high-latency tunnels. The current
implementation doesn't have explicit support for variable-speed
Ethernet and Powerline Ethernet, both technologies are bundled into a
single "good quality link" category.
Current implementations of IS-IS will supply a default metric for
links if not configured. We are unaware of any implementation that
computes this default metric dynamically, rather it is static and
supplied by the vendor. While support for dynamically computed
metrics could potentially be added to IS-IS, this is not completely
trivial to do right, since a naive approach would cause unacceptable
churn, potentially leading to repeated SPF computations and transient
microloops. Suitable mitigation techniques could probably be
developed, but they would likely be different from the mitigation
techniques that work well in Babel, since the link-state algorithm
used by IS-IS and the triggered updates used by Babel have
fundamentally different dynamics.
8. Support for Stub Networks and Stub Routers
A stub network is one that is attached to a Homenet, possibly through
multiple Homenet routers, but must not be used for transit. In the
following example, if the dotted link between C and D is a stub
network, then it must not be used for transit even if the link
between A and B fails:
---- A ----- B -----
| |
| |
C ..... D
Wasserman, et al. Expires September 6, 2015 [Page 11]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
Similarly a stub router is a router which may advertise and be a
destination for stub networks but should never be used for transit
traffic.
A number of people have expressed interest in attaching sensor class
equipment to Homenets, such as smart thermostats and home automation
hardware. Presumably, the sensor-class devices will run over a
dedicated low-power link (e.g. IEEE 802.15.4), with a small number
of devices acting as gateways between the homenet and the low power
network. Ideally, the gateway nodes would not be dedicated devices,
but merely sensor nodes that happen to have been equipped with an
Ethernet or WiFi interface.
Since low power links have orders of magnitude lower throughput than
Homenet links, routing Homenet traffic through the low power link
would cause it to collapse. Designating this link as a stub network
avoids this issue.
8.1. IS-IS Support for Stub Networks and Stub Routers
In IS-IS reachability (prefixes) and topology (links/adjacencies) are
separate things. IS-IS supports stub-networks as defined above
simply by advertising the prefix associated with a link, but not the
link itself. This is sometimes referred to as a "passive link".
Further an IS-IS router has the ability to set a bit (the overload
bit) to indicate that it should not be used for any transit traffic,
and that it will only be considered a destination for the prefixes it
has advertised, i.e., it is a stub router as defined above. As per
the IS-IS standard [ISO10589] an IS-IS router marked as such is not
expected to participate in the propagation of link state or the SPF
computation.
8.2. Babel Support for Stub Networks
As all distance vector protocols, Babel supports fairly arbitrary
route filtering. Designating a stub network is done with two
statements in the current implementation's filtering language.
For resource-limited deployments, a minimalistic, stub-only
implementation of Babel is available that consists of less than 1000
lines of C code that compile to a dozen kilobytes of text. Just like
the standard implementation, the stub implementation is mostly
portable code, and should be easily ported to any embedded
environment that supports the "sockets" API.
Wasserman, et al. Expires September 6, 2015 [Page 12]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
8.3. Discussion
A tiny, stub-only implementation of Babel is available.
A tiny, stub-router-only implementation of IS-IS is available. This
is the "tinyisis" referred to later in the document when comparing
implementation sizes.
9. Support for non-IEEE 802.2 link layers
Most link technologies employed in a Homenet use the IEEE 802.2 frame
format; this is notably the case of Ethernet, IEEE 802.11 and common
powerline technologies. However, other framing formats exist, and at
least PPP, PPPoE, IEEE 802.15.4, GRE and various VPN technologies are
likely to be used in Homenets.
9.1. IS-IS
IS-IS is built directly above the link layer (IS-IS control data is
not encapsulated within IP packets), and therefore needs explicit
support for every type of lower layer encapsulation. It is not known
what particular kinds of framing the Homenet implementation of IS-IS
supports.
9.2. Babel
Babel is built above UDP over link-local IPv6, and is able to run
with no modifications over any link that supports IPv6.
10. Security Features
10.1. Security Features in IS-IS
IS-IS offers multiple levels of security from none, to simple clear-
text (password) authentication, to fully generic cryptographic
authentication using any number of hashing algorithms [RFC5304].
Currently, the Homenet implementation of IS-IS uses the cleartext
password set to a predefined value for auto-configuration purposes.
10.2. Security Features in Babel
Babel supports symmetric key authentication using an extensible HMAC-
based cryptographic authentication mechanism [RFC7298]. This
mechanism is not vulnerable to replay attacks.
Wasserman, et al. Expires September 6, 2015 [Page 13]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
10.3. Discussion
Both protocols support password authentication. This probably
provides the necessary hooks for the Homenet Configuration Protocol
(HNCP) to implement whatever security policies are required by
Homenet.
11. Support for Multicast
Although the Homenet WG has not yet determined whether to support
multicast in Homenet Networks, it might be desirable to pick a
routing protocol that supports multicast, so that it will be easier
to add multicast support in the future.
11.1. Multicast Routing in IS-IS
The IS-IS protocol supports multicast routing. However, none of the
available implementations include support for multicast.
11.2. Multicast Routing in Babel
There is no support for multicast routing in Babel.
11.3. Discussion
Some experts believe that it may be better to run a dedicated
multicast routing protocol rather than extensions to a unicast
routing protocol.
12. Implementation Status
There are Homenet implementations of both IS-IS and Babel.
The Homenet implementation of IS-IS is the only IS-IS implementation
that supports source-specific routing, which is a hard requirement
for Homenet. If source-specific routing is not required, there are
several independent, interoperable proprietary implementations of IS-
IS (all major router vendors implement IS-IS). We are not aware of
any production-quality open-source implementation of IS-IS other than
the Homenet one.
There are multiple open source implementations of Babel, two of which
support source-specific routing. All implementations (except the
stub-only version) were originally derived from the same codebase.
Wasserman, et al. Expires September 6, 2015 [Page 14]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
13. Code and State Size
13.1. IS-IS Code and State Size
The Homenet implementation of IS-IS consists of 7000 lines of Erlang
code and has an installed size of over 11MB. Its initial memory
usage (as reported by the operating system) is 22MB, and its working
set increases by XXX bytes for each new edge in the network graph.
To put these numbers into perspective, in a network with XXX nodes
each of which has XXX neighbours, the Homenet implementation of IS-IS
requires XXX bytes for its data structures.
The code size of IS-IS depends greatly on what aspects of the
protocol have been implemented. IS-IS supports multiple address
families as well as completely different protocol stacks (OSI and
IP), multiple area hierachical operation with automatic virtual link
support for repairing area partitions, and multiple link types.
Additionally many other protocol features have been added over time
to augment the protocol or replace previous behavior. The protocol
lends itself well to not only extension, but pairing down of
features.
For Homenet we need a level-1 only implementation supporting a common
topology for IPv4 and IPv6 over broadcast (i.e., ethernet) link
types. Additionally, we only require support of the latest extended
metric TLVs (i.e., not implement legacy metric support).
[Does that mean that we don't care about PPP, PPPeE, GRE etc?]
The operational state required by IS-IS is proportional to the number
of routers, links, and prefixes in the network. Each router in the
network generates and advertises a Link State Protocol Data Unit
(LSP) that describes it's attached links and prefixes. A copy of
each of these LSPs is stored by each router in the network. IS-IS
uses these LSPs to construct a shortest-path-first (SPF) tree with
attached prefix information from which routes to the prefixes are
created.
Concrete numbers lacking.
13.2. Babel Code and State Size
The source-specific implementation of Babel, which implements many
non-Homenet extensions to the protocol, consists of roughly 10000
lines of C and has an installed size of less than 130kB on AMD-64.
Its initial memory usage (as reported by the operating system) is
300kB.
Wasserman, et al. Expires September 6, 2015 [Page 15]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
The amount of state stored by a Babel router is at worst one routing
table entry for each destination through each neighbour. In the
source-specific implementation, one routing entry occupies roughly
100 bytes of memory. To put these figures into perspective, in a
network with 1000 nodes, a Babel router with 10 neighbours needs
roughly a megabyte of memory to store its routing table (not counting
malloc overhead).
The stub-only implementation of Babel consists of 900 lines of C and
compiles to 13kB (dynamically linked). Its memory usage (as reported
by the operating system) is 200kB, and remains constant (it doesn't
perform any dynamic memory allocation).
The stub-only implementation of IS-IS consists of 1300 lines of C and
compiles to 18kB (stripped and dynamically linked). Its base memory
usage (as reported by 32-bit linux) is 330kB.
13.3. Comparison
Table 1 summarises the sizes of the available Homenet routing
protocol implementations. (Babel data courtesy of Steven Barth and
Markus Stenberg.)
+------------+------------+------------+---------------+------------+
| | babeld | sbabeld | AutoISIS (SS) | tinyisis |
| | (SS) | (stub) | | (stub) |
+------------+------------+------------+---------------+------------+
| Version | 2598774 | cc7d681 | [update]0.8.0 | 3ed2068 |
| Date | 2014-09-08 | 2014-11-21 | 2014-08-26 | 2015-02-22 |
| License | MIT | MIT | Apache 2.0 | Apache 2.0 |
| Lines of | 10000 (C) | 1000 (C) | 7000 (Erlang) | 1300 (C) |
| Code | | | | |
| Installed | 129kB | 13kB | 732kB | 17kB |
| size | | | | |
| (AMD64) | | | | |
| Total | 129kB | 13kB | 7MB | 17kB |
| installed | | | | |
| size | | | | |
| Baseline | ~300kB | ~200kB | 11MB | 330kB |
| RSS | | | | |
+------------+------------+------------+---------------+------------+
Table 1: Comparison of Homenet implementation size
In this table, "Installed size" is the size reported by the package
manager for the routing daemon's package(s), while "Total installed
size" is the sum of the size of the deamon's packages and all its
dependencies, excluding the C library.
Wasserman, et al. Expires September 6, 2015 [Page 16]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
The erlang AutoISIS has not been optimized for space or features
(i.e., it is a full IS-IS multilevel multi-address family
implementation). One example of how this affects the reported
numbers, is that the erlang logging package is taking up 4MB of ram.
Additionally, as erlang is interpreted and not compiled as with the C
implementations, there's not much use in directly comparing the
numbers themselves.
[We should add the size of the native Quagga isisd. While this
implementation is incomplete and doesn't support the Homenet
extensions, it should give us an idea how much we can hope to scale
IS-IS down. It's roughly 20000 lines of C, not counting the
additional 20000 for zebra. -- jch]
14. Ease of porting
If successful, the Homenet protocols will be implemented on exotic
devices, such as sensor-class devices, set-top boxes and mobile
phones. Rather than a full Unix system, such devices sometimes
provide a more exotic environment, such as an embedded operating
system or one designed for mobile phones.
14.1. IS-IS ease of porting
As IS-IS runs directly over layer 2, an implementation needs to be
able to send and receive layer 2 frames itself. On Unix systems,
this can be done using raw sockets or by hooking into the Berkeley
Packet Filter. Such interfaces might not be available on non-Unix
systems, and even on Unix are restricted to priviledged processes.
14.2. Babel ease of porting
Babel is layered above UDP. Except for a thin layer interfacing to
the kernel, the reference implementation of Babel consists of
portable code using the familiar "sockets" API (RFC 3493). Enabling
forwarding and manipulating the kernel's routing tables is the only
priviledged operation it performs.
Babel has been successfully ported to Android. Android does not
currently allow unpriviledged code to manipulate the kernel's routing
table, so Babel can only run on "rooted" phones. Should a future
version of Android provide the ability to manipulate the kernel's
routing table, Babel could conceivably be packaged as an installable
"app".
Wasserman, et al. Expires September 6, 2015 [Page 17]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
14.3. Discussion
IS-IS is somewhat difficult to port, due to the requirement for raw
sockets. Except for the requirement to install routes, Babel is
portable code, and has been successfully ported to Android.
15. Behaviour upon resource exhaustion
15.1. IS-IS
The IS-IS protocol has an overload indicator. When the protocol is
unable to acquire a needed resource, it enters overloaded state.
This state is signaled to the other routers and the overloaded router
is considered to be destination only (i.e., it becomes a stub
router).
15.2. Babel
Babel degrades gracefully. Since Babel is a distance-vector
protocol, a Babel implementation can simply drop excess routes when
it runs out of memory. As long as the default route is not
discarded, connectivity will be degraded but not completely lost.
The current implementation of Babel discards redundant routes before
it starts dropping announcements, but doesn't yet prioritise the
default route. (This behaviour was tested when somebody
redistributed the entire IPv6 default-free zone into a Babel network.
We had a lot of fun that day.)
16. Performance and scaling on IEEE 802.11 Wireless Networks
We expect wireless networks, and notably IEEE 802.11 wireless
networks, to be in wide use in Homenets, not only for client
connections but also for router-to-router connections. In fact, some
of us believe that the ability to cheaply and easily extend wireless
coverage by adding a wireless router is a "killer feature" of
Homenet, one that is easy to explain both to one's boss and to end
users.
IEEE 802.11 has some rather unpleasant performance characteristics.
First, wireless links are of very variable quality. Second,
multicast traffic is sent at a lowest common denominator speed,
typically 2Mbit/s, which makes multicast outrageously expensive (13ms
for a full-size frame). Third, multicast traffic is not protected by
link-layer ARQ, which makes multicast packet drops very common,
especially in the presence of collisions, which are particularly
likely when the routing protocol is in the process of reconverging.
Wasserman, et al. Expires September 6, 2015 [Page 18]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
This has some consequences for routing protocols:
o the routing protocol must be able to deal with varying link
qualities (see Section 7);
o if the routing protocol uses multicast for transmitting control
data, it must deal gracefully with packet loss during
reconvergence;
o the routing protocol must avoid sending large bursts of multicast
traffic from multiple nodes simultaneously during reconvergence.
IEEE 802.11 has two main modes of operation. In "infrastructure
mode", a small number of "access points" (APs), often just one,
communicate with a number of "stations" (STAs); communication between
two stations transits through one or at most two APs. In "IBSS mode"
(also called "ad hoc mode"), communication is unrestricted, and any
node can directly communicate with any other node in range; as there
is no link-layer forwarding, IBSS mode does not guarantee that
communication is transitive. Virtually all home network deployments
today use infrastructure mode, with the router acting as AP and
client devices acting as stations. We believe that IBSS may be out
of scope for Homenet, but we expect that people will attempt to use
the Homenet protocols in IBSS mode, whether we like it or not.
16.1. IS-IS Performance on 802.11
IS-IS is in active use in in the Internet in large non-hierachical
(i.e., level-2 or single area level-1) deployments with hundreds of
nodes. The protocol has proven to be very scalable.
We are not aware of any results in the open litterature about the
behaviour of IS-IS over IEEE 802.11. In particular, we do not know
how IS-IS's reliable flooding mechanism behaves over IEEE 802.11.
16.2. Babel Performance on 802.11
Babel has been carefully optimised for IEEE 802.11 networks. While
Babel transmits most control data over multicast, it applies large
amounts of random jitter (on the order of seconds) to all but its
most urgent control messages. Roughly speaking, Babel sends in a
timely manner those control messages that are likely to repair a
broken route, but delays sending those messages that merely announce
a slightly better route than one that is already available. This
mechanism has been shown to work well in dense wireless deployments,
with recent versions of Babel being able to avoid link-layer
meltdowns even when a whole network is being rebooted simultaneously.
Wasserman, et al. Expires September 6, 2015 [Page 19]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
As explained in Section 7, Babel performs link quality estimation on
wireless links in a manner that works relatively well with the 802.11
MAC. In addition, Babel has provisions for estimating radio
interference [BABEL-Z], which is necessary in order to provide decent
throughput on multi-hop radio routes.
Babel has been designed to work well in IBSS mode, where
communication is not transitive and therefore a packet may be routed
through the same interface it was received on.
16.3. Discussion
Babel has been designed with wireless networks in mind, and has been
shown to work reasonably well even in the extremely hostile
environment of wireless mesh networks built over IEEE 802.11 in IBSS
("ad hoc") mode.
We are not aware of any results about the behaviour of IS-IS's
reliable flooding sub-protocol over IEEE 802.11 multicast. IS-IS
will not work over IEEE 802.11 IBSS mode without changes, since both
the pseudonode optimisation and DIS election assume that
communication is transitive.
17. Standardization Status
17.1. IS-IS Standardization
IS-IS is an ISO Standard documented in ISO/IEC 10589:2002 [ISO10589]
There is an active IETF IS-IS Working Group (isis-wg) that maintains
and extends the IS-IS protocol, and the IS-IS protocol has been
extended in several IS-IS Working Group documents.
The autoconfiguration and source-specific extensions to IS-IS, which
are both hard requirements for Homenet, are documented in (non-WG)
Internet Drafts [ISIS-AUTOCONF] [ISIS-SS].
17.2. Babel Standardization Status
Babel is documented in an Experimental RFC (RFC 6126) published in
2011, and it has been updated in several individual-submission RFCs
and Internet Drafts. An Internet Draft establishing an IANA registry
of Babel extensions has been submitted for publication as an RFC
[BABEL-EXT].
The use of Babel in a Standards Track Homenet RFC would require a
"downref" to non-Standards Track documents. It would also be
necessary to finish publishing the extensions that are needed for the
Homenet use case as RFCs.
Wasserman, et al. Expires September 6, 2015 [Page 20]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
18. Evaluation of RFC 7368 Criteria
Section 3.5 of [RFC7368] lists a set of criteria that the Homenet
routing protocol must satisfy.
o border discovery: out of scope, as this is done by HNCP.
o self configuring: both protocols are self-configuring, see
Section 5.
o behaviour during reconfiguration and reconvergence:
* both protocols are able to establish adjacencies and to route
IPv6 before they even receive an IPv6 address due to their use
of stable neighbour identifiers;
* Babel will avoid creating loops even during reconvergence, but
might create temporary blackholes;
* IS-IS may create short-lived loops during reconvergence;
* since HNCP doesn't depend on unicast, in principle it is not
impacted by the routing protocol's behaviour during
reconvergence; however, on a wireless network, the interference
caused by routing loops may delay HNCP's reconvergence.
o the Homenet routing protocol should be based on a previously
deployed protocol:
* IS-IS is more widely deployed in carrier networks,
* there is more experience with running Babel on Plastic Home
Routers
* Only the Babel implementation of source-specific routing has
seen any deployment.
o support for IPv4: both protocols are intrinsically double-stack --
a single routing instance is able to carry both IPv6 and IPv4.
o multiple types of physical interfaces must be accounted for: only
Babel is able to differentiate between different link
technologies, see Section 7; nothing is known about IS-IS's
behaviour on wireless links.
o minimising convergence time: both protocols converge fast, see
Section 4.
Wasserman, et al. Expires September 6, 2015 [Page 21]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
o support the generic use of multiple Internet connections: both
protocols support source-specific routing, see Section 6.
o scalable to higher hop counts: both protocols have reasonably wide
metrics (24 bits in IS-IS, 16 bits in Babel).
o support for attached LLNs and other non-transit networks: both
protocols are able to designate a link as non-transit. Tiny stub
implementations of Babel and IS-IS are available. See Section 8.
o support for Multicast: IS-IS is able to carry multicast routes,
Babel is not.
19. Evaluation of RFC 5218 Criteria
19.1. Critical Success Factors
Does the protocol exhibit one or more of the critical initial success
factors as defined in RFC 5218?
19.1.1. IS-IS Success Factors
IS-IS exhibits the following critical initial success factors:
o Positive Net Value:
* Hardware cost: None.
* Operational interface: Existing and extensive.
* Retraining: None.
* Business dependencies: None.
o Incremental Deployment: Yes.
o Open Code Availability: Yes. One implementation of the Homenet
extensions, multiple proprietary implementations of the base
protocol.
o Freedom from Usage Restrictions: Yes.
o Open Specification Availability: Yes.
o Open Maintenance Processes: Yes.
Wasserman, et al. Expires September 6, 2015 [Page 22]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
o Good Technical Design: Proven with extensive deployment and
experience with the base protocol, little deployment of the
Homenet extensions.
o Extensible: Yes.
o No Hard Scalability bound: Yes.
o Threats Sufficiently Mitigated: Yes.
19.1.2. Babel Success Factors
Babel exhibits the following critical initial success factors:
o Positive Net Value:
* Hardware cost: None.
* Operational interface: tcpdump and wireshark support, dedicated
monitoring software.
* Retraining: None.
* Business dependencies: None.
o Incremental Deployment: Yes.
o Open Code Availability: Yes. Multiple implementations derived
from a common source.
o Freedom from Usage Restrictions: Yes.
o Open Specification Availability: Yes.
o Open Maintenance Processes: IANA registry in the process of being
created.
o Good Technical Design: Yes.
o Extensible: Yes.
o No Hard Scalability bound: Yes.
o Threats Sufficiently Mitigated: probably.
Wasserman, et al. Expires September 6, 2015 [Page 23]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
19.2. Willing Implementors
Are there implementers who are ready to implement the technology in
ways that are likely to be deployed?
19.2.1. IS-IS
There is only one implementation of autoconfiguration and source-
specific routing for IS-IS. There are some other open source
implementations of the base protocol, but they are incomplete (as of
February 2015).
As all major routing vendors have (proprietary) IS-IS
implementations, the barrier for implmeneting IS-IS for Homenet use
is probably manageable, assuming that the willingness to implement
modifications needed for Homenet use is present.
19.2.2. Babel
The Babel implementation is open source software (MIT licensed), and
the codebase has proven of sufficiently high quality to be easily
extended by people who were not in direct contact with the author
[RFC7298].
With the exception of a small number of functions used for
interfacing with the kernel's routing tables, Babel is portable code,
and is easily ported to any environment that supports the familiar
"sockets" API.
19.3. Willing Customers
Are there customers (especially high-profile customers) who are ready
to deploy the technology?
19.3.1. IS-IS
Yes. IS-IS is already widely deployed in operational networks.
19.3.2. Babel
Source-Specific Babel is currently deployed as part of the OpenWRT
and CeroWRT operating systems. Additionally, the current version is
used as a testbed for the Homenet configuration protocol.
Wasserman, et al. Expires September 6, 2015 [Page 24]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
19.4. Potential Niches
Are there potential niches where the technology is compelling?
19.4.1. IS-IS
[TBD]
19.4.2. Babel
Babel is a simple and flexible routing protocol. Like most distance-
vector protocols, it requires little to no configuration in most
topologies, and has proved popular in scenarios where competent
network administration was not available. In addition, it has been
shown to be particularly useful in scenarios where non-standard
dynamically computed metrics are beneficial, notably wireless mesh
networks and overlay networks.
19.5. Complexity Removal
If so, can complexity be removed to reduce cost?
19.5.1. IS-IS
As mentioned previously IS-IS can be significantly and easily pared
down to fit the more limited scope of homenet use. However, no such
pared down implementation exists, and the subset of the protocol that
needs to be implemented has never been formally defined.
19.5.2. Babel
Babel is a fairly simple protocol -- RFC 6126 is just 40 pages long
(not counting informative appendices), and it has been successfully
explained to fourth year university students in less than two hours.
The stub-only implementation of Babel consists of 900 lines of C
code, and has deliberately been kept as simple as possible. We
expect a competent engineer to get up to speed with it within hours.
19.6. Killer App
Is there a potential killer app? Or can the technology work
underneath existing unmodified applications?
Wasserman, et al. Expires September 6, 2015 [Page 25]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
19.6.1. IS-IS
As IS-IS already qualifies as successful (bordering on wildly) a
killer app is not particularly relevant.
19.6.2. Babel
Since Babel requires virtually no configuration, it is particularly
suitable to scenarios where a dedicated network administrator is not
available. Additionally, its support for dynamically computed non-
standard metrics makes it particularly appealing in highly
heterogeneous networks, (networks built on multiple link-layer
technologies with widely varying performance characteristics).
19.7. Extensible
Is the protocol sufficiently extensible to allow potential
deficiencies to be addressed in the future?
19.7.1. IS-IS
IS-IS has been shown to be incredibly extensible, originally designed
for a completely different protocol stack (OSI) it was easily adapted
for IP use, then to multiple address families (IPv4, IPv6) and multi-
topology. Indeed one of the major drivers of IS-IS's success is its
extensibility and adaptability.
19.7.2. Babel
The extension mechanisms built into the Babel protocol [BABEL-EXT]
have been used to build a number of extensions, including one that
significantly extends the structure of announcements [BABEL-SS] and
one that needs a non-trivial extension to the space of metrics
[BABEL-Z].
All Babel extensions that have been defined interoperate with the
original protocol, as defined in RFC 6126, to the extent possible.
For example, a router that doesn't implement the radio interference
extension will just ignore the frequency information attached to
route updates, which may lead to slightly sub-optimal routing but
will cause neither blackholes nor routing loops. To the contrary, a
router that doesn't support the source-specific extensions will
silently ignore any source-specific update, and therefore route
according to the non-specific subset of available routes, which might
cause blackholes, but under no circumstances will cause routing
loops. Backwards compatibility provisions are described in Section 4
of [BABEL-EXT].
Wasserman, et al. Expires September 6, 2015 [Page 26]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
19.8. Success Predictable
If it is not known whether the protocol will be successful, should
the market decide first? Or should the IETF work on multiple
alternatives and let the market decide among them? Are there factors
listed in this document that may predict which is more likely to
succeed?
19.8.1. IS-IS
For IS-IS the market has already decided that the protocol is
successful in a fairly wide variety of deployments.
19.8.2. Babel
Plain (non-source-specific) Babel has seen a modest amount of
deployment, most notably for routing over wireless mesh networks and
intercontinental overlay networks. Babel is included as an
installable package in many Linux distributions, which makes it
easily available to interested parties.
Source-specific Babel is probably the only source-specific routing
protocol that has seen any deployment. Source-specific Babel is
available as an installable package for OpenWRT, and is used by
default by CeroWRT.
20. Acknowledgments
The authors are grateful for the input of Steven Barth, Denis
Ovsienko, Mark Townsley, and Curtis Villamizar.
21. Informative References
[BABEL-EXT]
Chroboczek, J., "Extension Mechanism for the Babel Routing
Protocol", draft-chroboczek-babel-extension-mechanism-03
(work in progress), June 2013.
[BABEL-RTT]
Jonglez, B. and J. Chroboczek, "Delay-based Metric
Extension for the Babel Routing Protocol", Internet Draft
draft-jonglez-babel-rtt-extension-00, July 2014.
[BABEL-SS]
Boutier, M. and J. Chroboczek, "Source-Specific Routing in
Babel", draft-boutier-babel-source-specific-00 (work in
progress), November 2014.
Wasserman, et al. Expires September 6, 2015 [Page 27]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
[BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing
Protocol", draft-chroboczek-babel-diversity-routing-00
(work in progress), July 2014.
[DELAY-BASED]
Jonglez, B. and M. Boutier, "A delay-based routing
metric", March 2014, <http://arxiv.org/abs/1403.3488>.
[ISIS-AUTOCONF]
Liu, B., "ISIS Auto-Configuration", draft-liu-isis-auto-
conf-03 (work in progress), October 2014.
[ISIS-SS] Baker, F. and D. Lamparter, "IPv6 Source/Destination
Routing using IS-IS", draft-baker-ipv6-isis-dst-src-
routing-02 (work in progress), October 2014.
[ISO10589]
ISO/IEC, "Intermediate system to Intermediate system
intra-domain routeing information exchange protocol for
use in conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473) Second
Edition", Novmeber 2002.
ISO 10589:2002 Second Edition
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, October 2008.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October
2008.
[RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126,
April 2011.
[RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code
(HMAC) Cryptographic Authentication", RFC 7298, July 2014.
[RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
"IPv6 Home Networking Architecture Principles", RFC 7368,
October 2014.
Wasserman, et al. Expires September 6, 2015 [Page 28]
Internet-Draft Homenet IS-IS and Babel Comparison March 2015
[SS-ROUTING]
Boutier, M. and J. Chroboczek, "Source-sensitive routing",
December 2014, <http://arxiv.org/abs/1403.0445>.
Authors' Addresses
Margaret Wasserman
Painless Security
356 Abbott Street
North Andover, MA 01845
USA
Phone: +1 781 405-7464
Email: mrw@painless-security.com
URI: http://www.painless-security.com
Christian E. Hopps
Deutsche Telekom
Email: chopps@chopps.org
Juliusz Chroboczek
University of Paris-Diderot (Paris 7)
Email: jch@pps.univ-paris-diderot.fr
Wasserman, et al. Expires September 6, 2015 [Page 29]
