One document matched: draft-mrw-homenet-rtg-comparison-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc6126 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6126.xml'>
<!ENTITY rfc7298 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7298.xml'>
<!ENTITY rfc1142 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1142.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-mrw-homenet-rtg-comparison-00.txt">
<front>
<title>HOMENET IS-IS and Babel Comparison</title>
<author initials="M." surname="Wasserman" fullname="Margaret Wasserman">
<organization>Painless Security</organization>
<address>
<postal>
<street>356 Abbott Street</street>
<city>North Andover</city> <region>MA</region>
<code>01845</code>
<country>USA</country>
</postal>
<phone>+1 781 405-7464</phone>
<email>mrw@painless-security.com</email>
<uri>http://www.painless-security.com</uri>
</address>
</author>
<author initials="C." surname="Hopps" fullname="Christian E. Hopps">
<organization>Deutsche Telekom</organization>
<address>
<email>chopps@rawdofmt.org</email>
</address>
</author>
<author initials="J." surname="Chroboczek" fullname="Juliusz Chroboczek">
<organization>University of Paris-Diderot (Paris 7)</organization>
<address>
<email>jch@pps.univ-paris-diderot.fr</email>
</address>
</author>
<date month="February" year="2015"/>
<area>Internet</area>
<workgroup>Homenet Working Group</workgroup>
<abstract>
<t>
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).
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document compares IS-IS (ISO/IEC 10589:2002) <xref
target="RFC1142"/> and Babel <xref target="RFC6126"/> across
several criteria related to their use in home networks, as
defined by the HOMENET WG (HOMENETs).
</t>
<t>
Although there are substantial differences between the IS-IS
and Babel routing protocols, both routing protocols work well,
and either of them could be used in a home network. There are
many characteristics of these protocols that make them more or
less suitable for use in HOMENETs, as defined in
(reference homenet architecture and HNCP documents), and those
characteristics are explored in this document.
</t>
</section>
<section title="Protocols and Extensions Included in Comparison">
<t>
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.
</t>
<section title="IS-IS Protocol and Extensions">
<t>
In addition to the base IS-IS protocol specification
(ISO/IEC 10589:2002), this comparison considers the
following IS-IS extensions:
</t>
</section>
<section title="Babel Protocol and Extensions">
<t>
In addition to the base Babel Protocol specification (RFC
6126), this comparison considers the following Babel
extensions:
</t>
<t>
Source-Specific Routing <xref target="BABEL-SS"/>, described in
more detail in <xref target="SS-ROUTING"/>.
</t>
<t>
Extension Mechanism for the Babel Routing Protocol<xref target="BABEL-EXT"/>
</t>
</section>
</section>
<section title="Routing Algorithms">
<t>
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.
[chopps: Perhaps we should see if we can find an external reference for
comparing DVRP to link-state RPs for this section].
</t>
<section title="Link State Algorithm">
<t>
Link state algorithms distribute information for each
node to compute a tree representing the entire network.
</t>
<t>
Link state algorithms scale well in both very large and
very dense networks.
</t>
</section>
<section title="Distance-Vector Algorithm (Babel)">
<t>
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 shortest path to reach the destination.
</t>
</section>
<section title="Algorithm Comparison">
<t>
Loop-avoiding Distance Vector scales beautifully to very large
networks -- the amount of state is linear in the number of
nodes, and 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.
</t>
<t>
Naive link state has somewhat worse scaling properties, since it
has state that is proportional to the number of edges in the
network graph, and requires strict state synchronisation between
nodes. Real-world link-state protocols work around that issue
by splitting the network into multiple "areas", and performing
distance-vector routing between areas. It is unclear whether
this workaround is suitable for Homenet.
</t>
</section>
</section>
<section title="Support for Source-Specific Routing">
<t>
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.
</t>
<t>
Both Babel and IS-IS have extensions for source-specific routing.
</t>
<section title="Source Specific Routing in IS-IS">
<t>[XXX: chopps]</t>
<t>
Reports indicate that IS-IS has critical issues (routing loops)
in a mixed environment where some routers support
Source-Specific Routing, and some routers do not. However, this
is not likely to be a problem for Homenet, as we will require
Source-Specific Routing on all routers.
</t>
</section>
<section title="Source Specific Routing in Babel">
<t>
The Source-specific extension to the Babel routing protocol
<xref target="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 implementation
is currently being merged into the standard Babel
implementation, and is scheduled to be included in version 1.6
(planned for March 2015).
</t>
</section>
<section title="Discussion">
<t>
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 routing pathologies
such as routing loops. Interoperability between plain Babel and
Source-Specific Babel is described in detail in Section VI.A of
<xref target="SS-ROUTING"/>.
</t>
<t>
Reports indicate that source-specific IS-IS has critical issues
(routing loops) in a mixed environment where some routers
support Source-Specific Routing, and some routers do not.
However, this is not likely to be a problem for Homenet, as we
will require Source-Specific Routing on all routers.
</t>
<t>
[How will we enforce that? -- jch]
</t>
</section>
</section>
<section title="Support for Link Metrics">
<section title="Link Metrics in IS-IS">
<t>
IS-IS supports 2 types of link metrics a legacy link metric (which
should probably not be considered for HOMENET use) and a modern
extended (24-bit) link metric. Additionally multi-topology support
allows for a variable number of metrics per link.
</t>
</section>
<section title="Link Metrics in Babel">
<t>
In Babel, metrics are unsigned 16-bit integers, which means that
metrics are arbitrary integers between 0 and 65534 (the value
65535 is reserved to mean "infinity"); this has been found to be
sufficient even in the chaotic environment of wireless mesh
networks. If needed, the Babel extension mechanism can be used
to extend the metric space in arbitrary ways (not just
integers), which has already been done by the radio interference
extensions to Babel <xref target="BABEL-Z"/>.</t>
</section>
</section>
<section title="Support for Attached Stub Networks">
<t>[I don't understand why this issue is important for Homenet. -- jch]</t>
<section title="IS-IS Support for Stub Networks">
<t>
A stub network in IS-IS is supported by the advertisement of
reachability to a prefix by a router in its LSP. [How does this
prevent the network from being used for transit? -- jch]
</t>
</section>
<section title="Babel Supportt for Stub Networks">
<t>
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.
</t>
</section>
</section>
<section title="Security Features">
<section title="Security Features in IS-IS">
<t>
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) based on security associations (link, area and domain
scoped).
</t>
<t>[What does that mean? Just support for HMAC-based
authentication, or am I missing something? -- jch]</t>
</section>
<section title="Security Features in Babel">
<t>
Babel supports an extensible HMAC-based cryptographic
authentication mechanism <xref target="RFC7298"/>.
</t>
</section>
</section>
<section title="Support for Multicast">
<t>
Although the HOMENET WG has not yet determined how/if 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.
</t>
<section title="Multicast Routing in IS-IS">
<t>
The IS-IS protocol supports multicast routing. However, none of
the available implementations include support for multicast.
[XXX: chopps: what do we mean by supporting multicast routing?]
</t>
<t>[Does the Homenet implementation support multicast? Does any
open source implementation support multicast? -- jch]</t>
</section>
<section title="Multicast Routing in Babel">
<t>
There is no support for multicast routing in Babel.
</t>
</section>
</section>
<section title="Implementation Status">
<t>
There are Homenet implementations of both IS-IS and Babel.
</t>
<t>
Only the Homenet implementation of IS-IS supports source-specific
routing, which is a hard requirement for Homenet. If
source-specific routing is not required, there are several
independent, interoperable implementations of IS-IS (all major
router vendors implement IS-IS), including some open source
implementations.
</t>
<t>
There are multiple open source implementations of Babel, two of
which support source-specific routing. However, they were both
originally derived from the same codebase.
</t>
</section>
<section title="Code and State Size">
<section title="IS-IS Code and State Size">
<t>
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.
</t>
<t>
[I suggest removing the rest of this section, since it consists
of unsubstantiated, vague claims depending on
a not-yet-implemented version of a not-yet-specified subset of
a large protocol. -- jch]
</t>
<t>
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.
</t>
<t>
For HOMENET we could use a very simple level-2 only implementation
supporting a common topology supporting IPv4 and IPv6 over broadcast
(i.e., ethernet) link types. Additionally, we would need only support
the latest extended metric TLV (i.e., not implement legacy metric
support). Implemented as such the code size should be very manageable.
</t>
<t>
The state actually required by IS-IS is not large, and primarily
correlates to the number of routers in the network (for LSP
storage). The protocol stores it's own link and adjacency data which
is expected to be negligible. Additionally, the protocol stores
received and generated LSPs, and typically an SPF tree with prefix
information attached. This state correlates directly to the number of
routers and prefixes in the network. Each router in the network
generates, a single LSP (possibly fragmented into segments) with
prefix information, a single copy of these LSPs is stored by each
router in the network regardless of the number of links, adjacencies
or the distance (or number of hops) from the storing router to the
advertising router.
</t>
</section>
<section title="Babel Code and State Size">
<t>
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.
</t>
<t>
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).</t> <t>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).
</t>
</section>
</section>
<section title="Scalablity on IEEE 802.11 Wireless Networks">
<t>
[I suggest renaming this section to "Performance on 802.11
wireless networks. Are we trying to get homenets to scale to
millions of nodes? -- jch]
</t>
<section title="IS-IS Scalability on 802.11">
<t>
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.
</t>
<t>
Do we have any information about the scaling of IS-IS on 802.11
networks, in particular?
</t>
</section>
<section title="Babel Scalability on 802.11">
<t>
Babel was carefully optimised for 802.11 networks. In
particular, it has (optional) provisions for link quality
estimation and (optional) provisions for radio-interference
sensitive routing.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Standardization Status">
<section title="IS-IS Standardization">
<t>
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.
</t>
<t>
The source-specific extension to IS-IS is standardized as XXX.
[Will it require a downref? -- jch]
</t>
</section>
<section title="Babel Standardization Status">
<t>
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.
</t>
<t>
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 publish the extensions that are
needed for the HOMENET use case as RFCs.
</t>
</section>
</section>
<section title="Evaluation of RFC 5218 Criteria">
<section title="Critical Success Factors">
<t>
Does the protocol exhibit one or more of the critical initial
success factors as defined in RFC 5218?
</t>
<section title="IS-IS Success Factors">
<t>
IS-IS exhibits the following critical initial success factors:
<list>
<t>Positive Net Value:
<list>
<t> Hardware cost: None. </t>
<t> Operational interface: Existing and extensive. </t>
<t> Retraining: None. </t>
<t> Business dependencies: None. </t>
</list>
</t>
<t>Incremental Deployment: Yes.</t>
<t>Open Code Availability: Yes. Multiple implementations.</t>
<t>Freedom from Usage Restrictions: Yes.</t>
<t>Open Specification Availability: Yes.</t>
<t>Open Maintenance Processes: Yes.</t>
<t>Good Technical Design: Proven with extensive deployment and experience.</t>
<t>Extensible: Yes.</t>
<t>No Hard Scalability bound: Yes.</t>
<t>Threats Sufficiently Mitigated: Yes.</t>
</list>
</t>
</section>
<section title="Babel Success Factos">
<t>
Babel exhibits the following critical initial success factors:
<list>
<t>Positive Net Value:
<list>
<t> Hardware cost: None. </t>
<t> Operational interface: ??. </t>
<t> Retraining: None. </t>
<t> Business dependencies: None. </t>
</list>
</t>
<t>Incremental Deployment: Yes.</t>
<t>Open Code Availability: Yes. One implementation.</t>
<t>Freedom from Usage Restrictions: Yes.</t>
<t>Open Specification Availability: Yes.</t>
<t>Open Maintenance Processes: No.</t>
<t>Good Technical Design: Yes, but less widely deployed/proven than IS-IS.</t>
<t>Extensible: Yes.</t>
<t>No Hard Scalability bound: No.</t>
<t>Threats Sufficiently Mitigated: ??.</t>
</list>
</t>
</section>
</section>
<section title="Willing Implementors">
<t>
Are there implementers who are ready to implement the technology
in ways that are likely to be deployed?
</t>
<section title="IS-IS">
<t>
There is only one implementation of source-specific routing
for IS-IS. [Has it ever been extended by people who are not
the authors? If so, who? -- jch]
</t>
<t>
[I suggest the rest of this section should be removed. -- jch]
</t>
<t>
As all major routing vendors have IS-IS implementations as well as
the existence of for sale and open source implementations, the
barrier for implmeneting IS-IS for homenet use is quite low. Given
this we can assume that willingness to implement modifications (if
any) for homenet use is present and strong.
</t>
</section>
<section title="Babel">
<t>
The Babel implementation is open source software (MIT
licensed, non-copyleft), and the codebase has proven of
sufficiently high quality to be easily extended by people who
were not in direct contact with the author <xref target="RFC7298"/>.
</t>
</section>
</section>
<section title="Willing Customers">
<t>
Are there customers (especially high-profile customers) who are
ready to deploy the technology?
</t>
<section title="IS-IS">
<t>
Yes. IS-IS is already widely deployed in operational networks.
</t>
<t>
[I suggest more details should be given. Recall that we're
speaking of source-specific IS-IS here. -- jch]
</t>
</section>
<section title="Babel">
<t>
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.
</t>
</section>
</section>
<section title="Potential Niches">
<t>
Are there potential niches where the technology is compelling?
</t>
<section title="IS-IS">
</section>
<section title="Babel">
<t>
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 metrics were needed,
notably wireless mesh networks and overlay networks.
</t>
</section>
</section>
<section title="Complexity Removal">
<t>
If so, can complexity be removed to reduce cost?
</t>
<section title="IS-IS">
<t>
As mentioned previously IS-IS can be significantly and easily paired
down to fit the more limited scope of homenet use.
</t>
<t>
[Any actual implementations the reader can examine? -- jch]
</t>
</section>
<section title="Babel">
<t>
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.
</t>
<t>
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.</t>
</section>
</section>
<section title="Killer App">
<t>
Is there a potential killer app? Or can the technology work
underneath existing unmodified applications?
</t>
<section title="IS-IS">
<t>
As IS-IS already qualifies as successful (bordering on wildly) a killer
app is not particularly relevant.
</t>
</section>
<section title="Babel">
<t>
Since Babel requires virtually no configuration, it is
particularly suitable to scenarios where a dedicated network
administrator is not available. Additionally, its support for
link quality sensing and non-standard metrics makes it
particularly appealing in highly heterogeneous networks,
(networks built on multiple link-layer technologies with
widely varying performance characteristics).
</t>
</section>
</section>
<section title="Extensible">
<t>
Is the protocol sufficiently extensible to allow potential
deficiencies to be addressed in the future?
</t>
<section title="IS-IS">
<t>
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.
</t>
</section>
<section title="Babel">
<t>
The extension mechanisms built into the Babel protocol
<xref target="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 <xref target="BABEL-SS"/> and one that needed
a non-trivial extension to the space of metrics
<xref target="BABEL-Z"/>.
</t>
</section>
</section>
<section title="Success Predictable">
<t>
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?
</t>
<section title="IS-IS">
<t>
For IS-IS the market has already decided that the protocol is
successful in a fairly wide variety of deployments.
</t>
</section>
<section title="Babel">
<t>
Source-specific Babel is probably the only source-specific
routing protocol that has seen a fair amount of deployment and
is being used in production.
</t>
<t>
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.
</t>
</section>
</section>
</section>
</middle>
<back>
<references title="Informative References">
&rfc6126;
&rfc7298;
<reference anchor="BABEL-SS"><front>
<title>Source-Specific Routing in Babel</title>
<author fullname="Matthieu Boutier" initials="M." surname="Boutier"/>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
<date year="2014" month="November"/>
</front>
<seriesInfo name="Internet Draft" value="draft-boutier-babel-source-specific-00"/>
</reference>
<reference anchor="SS-ROUTING" target="http://arxiv.org/abs/1403.0445">
<front>
<title>Source-sensitive routing</title>
<author initials="M." surname="Boutier" fullname="Matthieu Boutier"/>
<author initials="J." surname="Chroboczek" fullname="Juliusz Chroboczek"/>
<date year="2014" month="December"/>
</front>
</reference>
<reference anchor="BABEL-EXT"><front>
<title>Extension Mechanism for the Babel Routing Protocol</title>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
<date month="June" year="2013"/>
</front>
<seriesInfo name="Internet Draft" value="draft-chroboczek-babel-extension-mechanism-03"/>
</reference>
<reference anchor="BABEL-Z"><front>
<title abbrev="Babel Diversity Routing">Diversity Routing for the Babel
Routing Protocol</title>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
<date year="2014" month="July"/>
</front>
<seriesInfo name="Internet Draft" value="draft-chroboczek-babel-diversity-routing-00"/>
</reference>
&rfc1142;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:39:03 |