Networking Working Group J. Tripathi, Ed.
Internet-Draft J. de Oliveira, Ed.
Intended status: Informational Drexel University
Expires: July 10, 2014 C. Chauvenet, Ed.
Watteco.
JP. Vasseur, Ed.
Cisco Systems, Inc.
January 6, 2014
Why Reactive Protocols are Ill-Suited for LLNs
draft-tripathi-roll-reactive-applicability-02
Abstract
This document describes serious issues and shortcomings regarding the
use of reactive routing protocols in low power and lossy networks
(LLNs). Routing requirements for various LLN deployments are
discussed in order to judge how reactive routing may or may not
adhere to the necessary criteria.
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 July 10, 2014.
Copyright Notice
Copyright (c) 2014 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
Tripathi, et al. Expires July 10, 2014 [Page 1]Internet-Draft Reactive Protocol Evaluation in LLNs January 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Non-compliance with routing requirements in LLNs . . . . . . 3
3.1. Inability to support P2MP traffic pattern . . . . . . . . 3
3.2. Inability to support MP2P traffic pattern . . . . . . . . 4
4. Dependency of control overhead on application module . . . . 5
5. Flooding issues in LLNs . . . . . . . . . . . . . . . . . . . 6
5.1. Impact of flooding in battery operated nodes . . . . . . 7
6. Impact on memory . . . . . . . . . . . . . . . . . . . . . . 7
7. Lack of support for routing based on node capability . . . . 8
8. High delay for emergency traffic . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. Informative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
In 2008, the IETF chartered a Working Group called ROLL (Routing Over
Low power and Lossy networks) with the objective of specifying
routing requirements of Low power and Lossy Networks (LLN), and then
either select an existing routing protocol or specify and design a
new routing protocol in light of the unique requirements of these
networks. This led to the specification of a new routing protocol
called RPL (see [RFC6550]) along with other specifications related to
RPL.
Despite the existence of a standard track routing protocol for LLN,
discussions have been taken place as to whether other routing
approaches could be suitable, such as deploying reactive routing
protocols in LLNs, such as in smart metering networks, industrial
automation, water management networks, etc.. The aim of this document
is not to discuss a specific reactive routing protocol but why
reactive routing protocols in general are ill-suited for LLNs. For
the sake of illustration, we will refer to a reactive protocol called
LOADng ([I-D.clausen-lln-loadng]) which was introduced at the IETF,
with results seeming to indicate performance improvement over the