| Homenet Working Group | M. Wasserman |
| Internet-Draft | Painless Security |
| Intended status: Standards Track | C. Hopps |
| Expires: August 13, 2015 | Deutsche Telekom |
| J. Chroboczek | |
| University of Paris-Diderot (Paris 7) | |
| February 9, 2015 |
HOMENET IS-IS and Babel Comparison
draft-mrw-homenet-rtg-comparison-00.txt
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).
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 13, 2015.
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 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.
This document compares IS-IS (ISO/IEC 10589:2002) [RFC1142] and Babel [RFC6126] across several criteria related to their use in home networks, as defined by the HOMENET WG (HOMENETs).
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.
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.
In addition to the base IS-IS protocol specification (ISO/IEC 10589:2002), this comparison considers the following IS-IS extensions:
In addition to the base Babel Protocol specification (RFC 6126), this comparison considers the following Babel extensions:
Source-Specific Routing [BABEL-SS], described in more detail in [SS-ROUTING].
Extension Mechanism for the Babel Routing Protocol[BABEL-EXT]
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].
Link state algorithms distribute information for each node to compute a tree representing the entire network.
Link state algorithms scale well in both very large and very dense networks.
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.
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.
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.
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.
[XXX: chopps]
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.
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 implementation is currently 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 routing pathologies such as routing loops. Interoperability between plain Babel and Source-Specific Babel is described in detail in Section VI.A of [SS-ROUTING].
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.
[How will we enforce that? -- jch]
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.
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 [BABEL-Z].
[I don't understand why this issue is important for Homenet. -- jch]
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]
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.
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).
[What does that mean? Just support for HMAC-based authentication, or am I missing something? -- jch]
Babel supports an extensible HMAC-based cryptographic authentication mechanism [RFC7298].
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.
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?]
[Does the Homenet implementation support multicast? Does any open source implementation support multicast? -- jch]
There is no support for multicast routing in Babel.
There are Homenet implementations of both IS-IS and Babel.
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.
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.
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.
[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]
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 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.
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.
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).
[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]
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 scaling of IS-IS on 802.11 networks, in particular?
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.
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.
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 source-specific extension to IS-IS is standardized as XXX. [Will it require a downref? -- jch]
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.
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.
Does the protocol exhibit one or more of the critical initial success factors as defined in RFC 5218?
IS-IS exhibits the following critical initial success factors:
Babel exhibits the following critical initial success factors:
Are there implementers who are ready to implement the technology in ways that are likely to be deployed?
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]
[I suggest the rest of this section should be removed. -- jch]
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.
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 [RFC7298].
Are there customers (especially high-profile customers) who are ready to deploy the technology?
Yes. IS-IS is already widely deployed in operational networks.
[I suggest more details should be given. Recall that we're speaking of source-specific IS-IS here. -- jch]
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.
Are there potential niches where the technology is compelling?
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.
If so, can complexity be removed to reduce cost?
As mentioned previously IS-IS can be significantly and easily paired down to fit the more limited scope of homenet use.
[Any actual implementations the reader can examine? -- jch]
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.
Is there a potential killer app? Or can the technology work underneath existing unmodified applications?
As IS-IS already qualifies as successful (bordering on wildly) a killer app is not particularly relevant.
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).
Is the protocol sufficiently extensible to allow potential deficiencies to be addressed in the future?
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.
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 needed a non-trivial extension to the space of metrics [BABEL-Z].
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?
For IS-IS the market has already decided that the protocol is successful in a fairly wide variety of deployments.
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.
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.
| [BABEL-EXT] | Chroboczek, J., "Extension Mechanism for the Babel Routing Protocol", Internet Draft draft-chroboczek-babel-extension-mechanism-03, June 2013. |
| [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. |
| [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. |