TOC 
Network Working GroupE. Beroset
Internet-DraftElster Solutions, LLC.
Intended status: InformationalSeptember 16, 2010
Expires: March 20, 2011 


Mesh Under IPv6 Routing Requirements
draft-beroset-ietf-1hop-routing-reqs-00.txt

Abstract

Wireless mesh routing for low cost wireless mesh devices can be done at a layer under IPv6. This document examines the functional requirements of this kind of routing and to explore why this approach might be used in some contexts. It should be noted that this kind of routing is orthogonal to IP-level routing; there is no inherent conflict between the two.

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 March 20, 2011.

Copyright Notice

Copyright (c) 2010 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.



Table of Contents

1.  Requirements notation
2.  Introduction
3.  Node and Channel Characteristics
4.  Requirements
5.  Security Considerations
6.  References
    6.1.  Normative References
    6.2.  Informative Reference
§  Author's Address




 TOC 

1.  Requirements notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

2.  Introduction

Routing in wireless mesh networks is different from routing in conventional wired networks. In a wireless mesh network, nodes that wish to send messages to distant nodes which may be beyond radio range may rely on intermediate nodes to relay messages, effectively increasing the effective range of all participating nodes. In a conventional wired network, this routing and forwarding function is performed by routers, as distinguished from ordinary nodes which often do not have a routing function. By contrast, in wireless mesh networks, it is not uncommon for every node to also perform a routing and forwarding function. There has already been work done on the requirements for route-over schemes for wireless networks for buildings [RFC5867] (Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, “Building Automation Routing Requirements in Low-Power and Lossy Networks,” June 2010.), homes [RFC5826] (Brandt, A., Buron, J., and G. Porcu, “Home Automation Routing Requirements in Low-Power and Lossy Networks,” April 2010.), industrial automation [RFC5673] (Pister, K., Thubert, P., Dwars, S., and T. Phinney, “Industrial Routing Requirements in Low-Power and Lossy Networks,” October 2009.) and urban applications [RFC5548] (Dohler, M., Watteyne, T., Winter, T., and D. Barthel, “Routing Requirements for Urban Low-Power and Lossy Networks,” May 2009.) but not yet for the route-under variation in which routing is done beneath the IP level.



 TOC 

3.  Node and Channel Characteristics

Nodes in this network may have very little memory, low bandwidth connections, power constraints due to battery power, and an expected long lifetime. An example of such a node may be a wireless telemetry module for a water meter which is expected to last for more than a decade on a single battery.

Further, nodes may have intermittent connectivity due to a variety of reasons, including channel fading, battery depletion in intermediate nodes, or temporary channel impairments such as may be caused by having a vehicle parked in the transmission path. For these reasons, it can be expected that routing information may be quite dynamic, even in the case of a network consisting solely of fixed-location nodes.



 TOC 

4.  Requirements

The routing protocol MUST be transparent to the overlying IP network. That is, each node within the wireless mesh network is one hop away from the IP perspective.

The routing protocol MUST be usable even in the event that the underlying wireless netowrk is not capable of transmitting the full 1260-byte IPv6 datagram, as specified in [RFC4944] (Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks,” September 2007.).

The routing protocol MUST have a low burden on the intermediate nodes. This burden includes computational, memory and power usage. Less obviously, perhaps, is that minimizing the number of timers used is also useful.

The routing protocol MUST have a means by which troubleshooting can be effected. That is, if personnel maintaining the devices must determine, for example, if a particular node is not performing adequately or correctly, some mechanism or data needs to be available to assist in that work.



 TOC 

5.  Security Considerations

Security considerations of routing protocols generally include the prvention and/or detection of denial-of-service (DOS) attacks. In such attacks, an adversary causes one or more nodes to expend its resources to the degree that legitimate users of the network are denied access or suffer reduced performance. It would be useful to consider ways in which this kind of attack could be eliminated. If that is not possible given other requirements, it may be acceptable to reduce their effect and/or provide a mechanism to detect such attacks.



 TOC 

6.  References



 TOC 

6.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks,” RFC 4944, September 2007 (TXT).


 TOC 

6.2. Informative Reference

[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, “Routing Requirements for Urban Low-Power and Lossy Networks,” RFC 5548, May 2009 (TXT).
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, “Industrial Routing Requirements in Low-Power and Lossy Networks,” RFC 5673, October 2009 (TXT).
[RFC5826] Brandt, A., Buron, J., and G. Porcu, “Home Automation Routing Requirements in Low-Power and Lossy Networks,” RFC 5826, April 2010 (TXT).
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, “Building Automation Routing Requirements in Low-Power and Lossy Networks,” RFC 5867, June 2010 (TXT).


 TOC 

Author's Address

  Edward J. Beroset
  Elster Solutions, LLC.
  208 S Rogers Ln
  Raleigh, NC 27610
  US
Phone:  +1 919 250 5424
Email:  edward.j.beroset@us.elster.com
URI:  http://www.elster.com