HOMENET IS-IS and Babel Comparison
draft-mrw-homenet-rtg-comparison-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Margaret Cullen , Christian Hopps , Juliusz Chroboczek | ||
| Last updated | 2015-02-15 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mrw-homenet-rtg-comparison-01
Homenet Working Group M. Wasserman
Internet-Draft Painless Security
Intended status: Informational C. Hopps
Expires: August 19, 2015 Deutsche Telekom
J. Chroboczek
University of Paris-Diderot (Paris 7)
February 15, 2015
HOMENET IS-IS and Babel Comparison
draft-mrw-homenet-rtg-comparison-01.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 August 19, 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 August 19, 2015 [Page 1]
Internet-Draft HOMENET IS-IS and Babel Comparison February 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocols and Extensions Included in Comparison . . . . . . . 4
2.1. IS-IS Protocol and Extensions . . . . . . . . . . . . . . 5
2.2. Babel Protocol and Extensions . . . . . . . . . . . . . . 5
3. Routing Algorithms . . . . . . . . . . . . . . . . . . . . . 5
3.1. Link State Algorithm . . . . . . . . . . . . . . . . . . 5
3.2. Loop-Avoiding Distance-Vector Algorithm (Babel) . . . . . 6
3.3. Algorithm Comparison . . . . . . . . . . . . . . . . . . 6
4. Convergence Times . . . . . . . . . . . . . . . . . . . . . . 6
4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Babel . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7
5. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 7
5.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Babel . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7
6. Support for Source-Specific Routing . . . . . . . . . . . . . 8
6.1. Source-Specific Routing in IS-IS . . . . . . . . . . . . 8
6.2. Source-Specific Routing in Babel . . . . . . . . . . . . 8
6.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8
7. Support for Link Metrics . . . . . . . . . . . . . . . . . . 8
7.1. Link Metrics in IS-IS . . . . . . . . . . . . . . . . . . 9
7.2. Link Metrics in Babel . . . . . . . . . . . . . . . . . . 9
8. Support for Attached Stub Networks . . . . . . . . . . . . . 9
8.1. IS-IS Support for Stub Networks . . . . . . . . . . . . . 9
8.2. Babel Support for Stub Networks . . . . . . . . . . . . . 10
9. Security Features . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Security Features in IS-IS . . . . . . . . . . . . . . . 10
9.2. Security Features in Babel . . . . . . . . . . . . . . . 10
10. Support for Multicast . . . . . . . . . . . . . . . . . . . . 10
10.1. Multicast Routing in IS-IS . . . . . . . . . . . . . . . 10
10.2. Multicast Routing in Babel . . . . . . . . . . . . . . . 10
11. Implementation Status . . . . . . . . . . . . . . . . . . . . 10
12. Code and State Size . . . . . . . . . . . . . . . . . . . . . 11
12.1. IS-IS Code and State Size . . . . . . . . . . . . . . . 11
12.2. Babel Code and State Size . . . . . . . . . . . . . . . 12
12.3. Comparison . . . . . . . . . . . . . . . . . . . . . . . 12
13. Performance on IEEE 802.11 Wireless Networks . . . . . . . . 13
13.1. IS-IS Performance on 802.11 . . . . . . . . . . . . . . 13
13.2. Babel Performance on 802.11 . . . . . . . . . . . . . . 13
14. Standardization Status . . . . . . . . . . . . . . . . . . . 13
Wasserman, et al. Expires August 19, 2015 [Page 2]
Internet-Draft HOMENET IS-IS and Babel Comparison February 2015
14.1. IS-IS Standardization . . . . . . . . . . . . . . . . . 13
14.2. Babel Standardization Status . . . . . . . . . . . . . . 13
15. Evaluation of RFC 5218 Criteria . . . . . . . . . . . . . . . 14
15.1. Critical Success Factors . . . . . . . . . . . . . . . . 14
15.1.1. IS-IS Success Factors . . . . . . . . . . . . . . . 14
15.1.2. Babel Success Factos . . . . . . . . . . . . . . . . 15
15.2. Willing Implementors . . . . . . . . . . . . . . . . . . 15
15.2.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 15
15.2.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 16
15.3. Willing Customers . . . . . . . . . . . . . . . . . . . 16
15.3.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 16
15.3.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 16
15.4. Potential Niches . . . . . . . . . . . . . . . . . . . . 16
15.4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 16
15.4.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 16
15.5. Complexity Removal . . . . . . . . . . . . . . . . . . . 16
15.5.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 17
15.5.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 17
15.6. Killer App . . . . . . . . . . . . . . . . . . . . . . . 17
15.6.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 17
15.6.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 17
15.7. Extensible . . . . . . . . . . . . . . . . . . . . . . . 17
15.7.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 17
15.7.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 18
15.8. Success Predictable . . . . . . . . . . . . . . . . . . 18
15.8.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 18
15.8.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 18
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
17. Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
This document compares IS-IS (ISO/IEC 10589:2002) [RFC1142] and Babel
[RFC6126] according to several criteria related to their use in home
networks (HOMENETs), as defined by the HOMENET WG.
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 a HOMENET is 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.
Wasserman, et al. Expires August 19, 2015 [Page 3]
Internet-Draft HOMENET IS-IS and Babel Comparison February 2015
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.
HOMENETs are built and grow organically, and often end up consisting
of multiple link technologies with widely different performance
characteristics (twisted-pair Ethernet, IEEE 802.11 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.
Contrary to popular perception, the Plastic Home Router is usually
equipped with a reasonably fast CPU and reasonable amounts of flash
and RAM; at the time of writing, a (non-superscalar) 700MHz MIPS CPU
with 16MB of flash and 64MB of RAM is typical. However, we expect
smaller devices to participate in the HOMENET protocols, at least as
stub routers. The ability to scale down the HOMENET protocols is
therefore likely to encourage their wider adoption.
[Isn't it also the case that the HOMENET routing protocol will be
implemented on lower-end embedded devices, such as nodes in a low-
power wireless network? What is considered to be a reasonable low-
end system requirement for a HOMENET router? -- mrw]
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 using a protocol that scales well from
the outset may be desirable.
2. Protocols and Extensions Included in Comparison
Both IS-IS and Babel are living protocols that 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.
Wasserman, et al. Expires August 19, 2015 [Page 4]
Internet-Draft HOMENET IS-IS and Babel Comparison February 2015
2.1. IS-IS Protocol and Extensions
In addition to the base IS-IS protocol specification (ISO/IEC
10589:2002), this comparison considers the following IS-IS
extensions:
o ISIS Auto-Configuration [ISIS-AUTOCONF];
o Source-Specific routing in IS-IS [ISIS-SS].
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.
Wasserman, et al. Expires August 19, 2015 [Page 5]
Internet-Draft HOMENET IS-IS and Babel Comparison February 2015
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 to the neighbor who 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).
3.3. Algorithm Comparison
Loop-Avoiding Distance Vector scales to very large networks -- the
amount of state is linear in the number of nodes, and, due to the
absence of pathologies during reconvergence, does not need to be
propagated in a timely manner. It scales badly in extremely dense
deployments, where a single node has thousands of direct neighbours;
such deployments are unlikely, and clearly outside the scope of
HOMENET.
Link state algorithms scales to very large, very dense networks.
IS-IS distributes link and prefix information for each node in a
single Logical LSP (possibly fragmented). It uses these LSPs to
compute a tree representing the entire network. There is no
duplication of state based on the number of adjacencies or unique
paths to a given prefix.
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 a new LSP 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
Wasserman, et al. Expires August 19, 2015 [Page 6]
Internet-Draft HOMENET IS-IS and Babel Comparison February 2015
depends on the FIB hardware and design and not the routing protocol
choice.
We easily should expect sub-second convergence for any change in
reachability (addition or subtraction) in any conceivable homenet
deployment.
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.
4.3. Discussion
Both protocols enjoy fast convergence. However, unless there is a
high level of integration between the routing protocol and the link
layer, 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 two hello intervals on Babel wired links (8s by
default). (Babel performs link quality estimation on wireless links,
so the delay is somewhat more difficult to quantify there.)
5. Autoconfiguration
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
Wasserman, et al. Expires August 19, 2015 [Page 7]
Internet-Draft HOMENET IS-IS and Babel Comparison February 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
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 quantify the
desirability of a link by assigning a metric to it.
Wasserman, et al. Expires August 19, 2015 [Page 8]
Internet-Draft HOMENET IS-IS and Babel Comparison February 2015
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, it is
able to dynamically assign metrics to links depending on their lower-
layer characteristics. In practice, Babel assigns lower (better)
metrics to wired links than to wireless ones, dynamically measures
loss rates in order to favour lossless wireless links, favours routes
with non-interfering radio frequencies, and avoids high-latency
tunnels.
Obviously, such a wealth of information can lead to contradictory
data in edge cases; however, 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].
8. Support for Attached Stub Networks
A stub network is one that is attached to a HOMENET, possibly through
multiple HOMENET routers, but must not be used for transit. For
example, a stub network could be a sensor network which would
collapse under the HOMENET traffic should it ever 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
8.1. IS-IS Support for Stub Networks
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".
Wasserman, et al. Expires August 19, 2015 [Page 9]
Internet-Draft HOMENET IS-IS and Babel Comparison February 2015
8.2. Babel Support for Stub Networks
Babel supports flexible filtering of routes, and a stub network can
be designated by simply setting up the necessary filtering rules.
For resource-limited deployments, a minimalistic, stub-only
implementation of Babel is available.
9. Security Features
[I think this section is badly written. We should just state whether
each protocol supports auth or encryption, and whether it supports
symmetric or something more exciting. -- jch]
9.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 (e.g., HMAC-
MD5, HMAC-SHA1, ... HMAC-SHA512). Currently, the HOMENET
implementation of IS-IS uses the cleartext password set to a
predefined value for auto-configuration purposes.
9.2. Security Features in Babel
Babel supports symmetric key authentication using an extensible HMAC-
based cryptographic authentication mechanism [RFC7298].
10. 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.
10.1. Multicast Routing in IS-IS
The IS-IS protocol supports multicast routing. However, none of the
available implementations include support for multicast.
10.2. Multicast Routing in Babel
There is no support for multicast routing in Babel.
11. Implementation Status
There are HOMENET implementations of both IS-IS and Babel.
Wasserman, et al. Expires August 19, 2015 [Page 10]
Internet-Draft HOMENET IS-IS and Babel Comparison February 2015
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.
12. Code and State Size
12.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).
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.
Wasserman, et al. Expires August 19, 2015 [Page 11]
Internet-Draft HOMENET IS-IS and Babel Comparison February 2015
Concrete numbers lacking.
12.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.
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 12kB (dynamically linked). Its memory usage (as reported
by the operating system) is 200kB, and remains constant (it doesn't
perform any dynamic memory allocation).
12.3. Comparison
Table 1 summarises the sizes of the available HOMENET routing
protocol implementations. (Data courtesy of Steven Barth and Markus
Stenberg.)
+----------------+--------------------+----------------+------------+
| | babeld (source- | sbabeld (stub- | AutoISIS |
| | specific) | only) | |
+----------------+--------------------+----------------+------------+
| Version | 2598774 | cc7d681 | 0.8.0 |
| Date | 2014-09-08 | 2014-11-21 | 2014-08-26 |
| License | MIT | MIT | Apache 2.0 |
| Lines of Code | 10.000 (C) | 1.000 (C) | 7.000 |
| | | | (Erlang) |
| Installed size | 129kB | 13kB | 11,385kB |
| (AMD64) | | | |
| Total | 129kB | 13kB | 14,155kB |
| installed size | | | |
| Baseline RSS | ~300kB | ~200kB | ~22,000kB |
+----------------+--------------------+----------------+------------+
Table 1: Comparison of HOMENET implementation size
Wasserman, et al. Expires August 19, 2015 [Page 12]
Internet-Draft HOMENET IS-IS and Babel Comparison February 2015
In this table, "Installed size" is the size reported by the package
manager for the routing daemon's package(s) (including the 1.6MB of
the "Beam" Erlang VM in the case of IS-IS), while "Total installed
size" is the sum of the size of the deamon's packages and all its
dependencies, excluding the C library.
13. Performance on IEEE 802.11 Wireless Networks
13.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.
[Do we have any information about the performance of IS-IS on 802.11
networks, in particular? -- mrw]
13.2. Babel Performance on 802.11
Babel has been carefully optimised for 802.11 networks. In
particular, it performs link quality estimations of wireless links in
a manner that works well with the 802.11 MAC. In addition, Babel has
provisions for estimating radio interference [BABEL-Z], which is
essential for providing decent throughput on multi-hop radio routes.
Babel was designed to work well on pure mesh networks (networks where
a packet might exit through the same interface as the one it came
from), but this is probably out of scope for HOMENET.
14. Standardization Status
14.1. IS-IS Standardization
IS-IS is an ISO Standard documented in ISO/IEC 10589:2002. There is
an active IETF IS-IS Working Group (ISIS) that maintains and extends
the IS-IS protocol, and the IS-IS protocol has been extended in
several ISIS 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].
14.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
Wasserman, et al. Expires August 19, 2015 [Page 13]
Internet-Draft HOMENET IS-IS and Babel Comparison February 2015
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.
15. Evaluation of RFC 5218 Criteria
15.1. Critical Success Factors
Does the protocol exhibit one or more of the critical initial success
factors as defined in RFC 5218?
15.1.1. IS-IS Success Factors
IS-IS exhibits the following critical initial success factors:
Positive Net Value:
Hardware cost: None.
Operational interface: Existing and extensive.
Retraining: None.
Business dependencies: None.
Incremental Deployment: Yes.
Open Code Availability: Yes. One implementation of the HOMENET
extensions, multiple proprietary implementations of the base
protocol.
Freedom from Usage Restrictions: Yes.
Open Specification Availability: Yes.
Open Maintenance Processes: Yes.
Good Technical Design: Proven with extensive deployment and
experience with the base protocol, little deployment of the
HOMENET extensions.
Extensible: Yes.
No Hard Scalability bound: Yes.
Wasserman, et al. Expires August 19, 2015 [Page 14]
Internet-Draft HOMENET IS-IS and Babel Comparison February 2015
Threats Sufficiently Mitigated: Yes.
15.1.2. Babel Success Factos
Babel exhibits the following critical initial success factors:
Positive Net Value:
Hardware cost: None.
Operational interface: tcpdump and wireshark support, dedicated
monitoring software.
Retraining: None.
Business dependencies: None.
Incremental Deployment: Yes.
Open Code Availability: Yes. Multiple implementations derived
from a common source.
Freedom from Usage Restrictions: Yes.
Open Specification Availability: Yes.
Open Maintenance Processes: IANA registry in the process of being
created.
Good Technical Design: Yes.
Extensible: Yes.
No Hard Scalability bound: Yes.
Threats Sufficiently Mitigated: probably.
15.2. Willing Implementors
Are there implementers who are ready to implement the technology in
ways that are likely to be deployed?
15.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).
Wasserman, et al. Expires August 19, 2015 [Page 15]
Internet-Draft HOMENET IS-IS and Babel Comparison 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.
15.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].
15.3. Willing Customers
Are there customers (especially high-profile customers) who are ready
to deploy the technology?
15.3.1. IS-IS
Yes. IS-IS is already widely deployed in operational networks.
15.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.
15.4. Potential Niches
Are there potential niches where the technology is compelling?
15.4.1. IS-IS
15.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.
15.5. Complexity Removal
If so, can complexity be removed to reduce cost?
Wasserman, et al. Expires August 19, 2015 [Page 16]
Internet-Draft HOMENET IS-IS and Babel Comparison February 2015
15.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.
15.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.
15.6. Killer App
Is there a potential killer app? Or can the technology work
underneath existing unmodified applications?
15.6.1. IS-IS
As IS-IS already qualifies as successful (bordering on wildly) a
killer app is not particularly relevant.
15.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).
15.7. Extensible
Is the protocol sufficiently extensible to allow potential
deficiencies to be addressed in the future?
15.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.
Wasserman, et al. Expires August 19, 2015 [Page 17]
Internet-Draft HOMENET IS-IS and Babel Comparison February 2015
15.7.2. Babel
The extension mechanisms built into the Babel protocol [BABEL-EXT]
have been shown to be a solid basis on which many backwards-
compatible extensions have been built, including one that
fundamentally changes the structure of announcements [BABEL-SS] and
one that needs a non-trivial extension to the space of metrics
[BABEL-Z].
15.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?
15.8.1. IS-IS
For IS-IS the market has already decided that the protocol is
successful in a fairly wide variety of deployments. [We're speaking
of source-specific, autoconfiguring IS-IS here? And are we speaking
of small, unadministered networks? -- jch]
15.8.2. Babel
Source-specific Babel is probably the only source-specific routing
protocol that has seen deployment and is being used in production.
Plain Babel has seen a modest amount of deployment, most notably for
routing over wireless mesh networks and large-scale overlay networks.
However, it remains a young protocol, certainly much younger than IS-
IS.
16. Acknowledgments
The authors are grateful for the input of Steven Barth, Denis
Ovsienko and Mark Townsley.
17. Informative References
[BABEL-EXT]
Chroboczek, J., "Extension Mechanism for the Babel Routing
Protocol", Internet Draft draft-chroboczek-babel-
extension-mechanism-03, June 2013.
Wasserman, et al. Expires August 19, 2015 [Page 18]
Internet-Draft HOMENET IS-IS and Babel Comparison February 2015
[BABEL-SS]
Boutier, M. and J. Chroboczek, "Source-Specific Routing in
Babel", Internet Draft draft-boutier-babel-source-
specific-00, November 2014.
[BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing
Protocol", Internet Draft draft-chroboczek-babel-
diversity-routing-00, 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", Internet Draft draft-
liu-isis-auto-conf-03, October 2014.
[ISIS-SS] Baker, F. and D. Lamparter, "IPv6 Source/Destination
Routing using IS-IS", Internet Draft draft-baker-ipv6-
isis-dst-src-routing-02, October 2014.
[RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", RFC
1142, February 1990.
[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.
[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
Wasserman, et al. Expires August 19, 2015 [Page 19]
Internet-Draft HOMENET IS-IS and Babel Comparison February 2015
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 August 19, 2015 [Page 20]