One document matched: draft-ietf-6lowpan-routing-requirements-06.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!--ENTITY RFC3561 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3561.xml"-->
<!--ENTITY RFC3626 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3626.xml"-->
<!ENTITY RFC3756 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3756.xml">
<!ENTITY RFC3819 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3819.xml">
<!ENTITY RFC4944 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC4919 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4919.xml">
<!ENTITY RFC5548 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5548.xml">
<!ENTITY RFC5673 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5673.xml">
<!ENTITY I-D.ietf-manet-smf PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-manet-smf-09.xml">
<!ENTITY I-D.ietf-6lowpan-nd PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-6lowpan-nd-08.xml">
<!ENTITY I-D.ietf-6lowpan-hc PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-6lowpan-hc-06.xml">
<!ENTITY I-D.ietf-roll-protocols-survey PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-roll-protocols-survey-07.xml">
<!ENTITY I-D.ietf-roll-home-routing-reqs PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-roll-home-routing-reqs-11.xml">
<!ENTITY I-D.ietf-roll-building-routing-reqs PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-roll-building-routing-reqs-09.xml">
<!-- 5548 now -->
<!-- ENTITY I-D.ietf-roll-urban-routing-reqs PUBLIC "" -->
<!-- "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-roll-urban-routing-reqs-04.xml"> -->
<!-- 5673 now, changes in -05version, feb 22,2010 -->
<!--ENTITY I-D.ietf-roll-indus-routing-reqs PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-roll-indus-routing-reqs-06.xml" -->
]>
<!--rfc ipr="full" docName="draft-ietf-6lowpan-routing-requirements-06" category="info" -->
<rfc ipr="pre5378Trust200902" docName="draft-ietf-6lowpan-routing-requirements-06" category="info" >
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes" ?>
<front>
<title abbrev="6LoWPAN Routing Requirements">
Problem Statement and Requirements for 6LoWPAN Routing
</title>
<author initials="E." surname="Kim" fullname="Eunsook Eunah Kim">
<organization>ETRI</organization>
<address>
<postal>
<street>161 Gajeong-dong</street>
<street>Yuseong-gu</street>
<city>Daejeon</city>
<code>305-700</code>
<country>Korea</country>
</postal>
<phone>+82-42-860-6124</phone>
<email>eunah.ietf@gmail.com</email>
</address>
</author>
<author initials="D." surname="Kaspar" fullname="Dominik Kaspar">
<organization>Simula Research Laboratory</organization>
<address>
<postal>
<street>Martin Linges v 17</street>
<city>Snaroya</city>
<code>1367</code>
<country>Norway</country>
</postal>
<phone>+47-6782-8223</phone>
<email>dokaspar.ietf@gmail.com</email>
</address>
</author>
<author initials="C." surname="Gomez" fullname="Carles Gomez">
<organization>Tech. Univ. of Catalonia/i2CAT</organization>
<address>
<postal>
<street>Escola Politecnica Superior de Castelldefels</street>
<street>Avda. del Canal Olimpic, 15</street>
<city>Castelldefels</city>
<code>08860</code>
<country>Spain</country>
</postal>
<phone>+34-93-413-7206</phone>
<email>carlesgo@entel.upc.edu</email>
</address>
</author>
<author initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization>Universität Bremen TZI</organization>
<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen</city>
<code>D-28359</code>
<country>Germany</country>
</postal>
<phone>+49-421-218-63921</phone>
<facsimile>+49-421-218-7000</facsimile>
<email>cabo@tzi.org</email>
</address>
</author>
<date year="2010" />
<area>General</area>
<workgroup>6LoWPAN Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>
6LoWPANs are formed by devices that are compatible with the IEEE 802.15.4
standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format
specification define how mesh topologies could be obtained and maintained.
Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported.
<vspace/>
This document provides the problem statement and design space for 6LoWPAN routing.
It defines the routing requirements for 6LoWPAN networks, considering the low-power
and other particular characteristics of the devices and links.
The purpose of this document is not to recommend specific solutions,
but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing,
which can lead to further analysis and protocol design.
This document is intended as input to groups working on routing
protocols relevant to 6LoWPAN, such as the IETF ROLL WG.
</t>
</abstract>
</front>
<middle>
<!--================ PROBLEM STATEMENT===============-->
<section anchor="problems" title="Problem Statement">
<t>
6LoWPANs are formed by devices that are compatible with the IEEE 802.15.4
standard <xref target="IEEE802.15.4"/>.
Most of the LoWPAN devices are distinguished by their low bandwidth,
short range, scarce memory
capacity, limited processing capability and other attributes of
inexpensive hardware. The characteristics of nodes
participating in LoWPANs are assumed to be those described in the 6LoWPAN problem statement <xref target="RFC4919"/>,
and the IPv6 over IEEE 802.15.4 <xref target="RFC4944"/> document which has specified
how to carry IPv6 packets over IEEE 802.15.4 and similar networks.
</t>
<t>
IEEE 802.15.4 networks support star and mesh topologies.
However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format
specification (<xref target="RFC4944"/>) define
how mesh topologies could be obtained and maintained. Thus, 6LoWPAN
formation and multi-hop routing should be supported by either at below IP layer (the adaptation layer or LLC)
or the IP layer. A number of IP routing protocols have been developed in various
IETF working groups. However, these existing routing protocols may not
satisfy the requirements of multi-hop routing in 6LoWPANs, for the following
reasons:
<list style="symbols">
<t>
6LoWPAN nodes have special types and roles, such as nodes drawing their power from primary batteries,
power-affluent nodes, mains-powered and high-performance gateways,
data aggregators, etc. 6LoWPAN routing protocols should support multiple device types
and roles.
</t>
<t>
More stringent requirements apply to LoWPANs, as opposed
to higher performance or non-battery-operated networks.
6LoWPAN nodes are characterized by small memory sizes,
low processing power, and are running on very limited power supplied
by primary non-rechargeable batteries (a few KBytes of RAM,
a few dozens of KBytes of ROM/flash memory, and a few MHz of CPU is
typical). A node's lifetime is usually defined by the lifetime of
its battery.
</t>
<t>
Handling sleeping nodes is very critical in LoWPANs, more than in
traditional ad-hoc networks. LoWPAN nodes might stay in sleep mode
for most of the time. Taking advantage of appropriate times for
transmissions is important for efficient packet forwarding.
</t>
<t>
Routing in 6LoWPANs might possibly translate to a simpler problem
than routing in higher-performance networks. LoWPANs might be either
transit networks or stub networks. Under the assumption that LoWPANs
are never transit networks (as implied by <xref target="RFC4944"/>),
routing protocols may be drastically simplified.
This document will focus on the requirements for stub
networks. Additional requirements may apply to transit networks.
</t>
<t>
Routing in LoWPANs might possibly translate to a harder problem
than routing in higher-performance networks. Routing in LoWPANs
requires power optimization, stable operation in lossy environments,
data-aware routing, etc. These requirements are not easily
satisfiable all at once <xref target="I-D.ietf-roll-protocols-survey"/>.
</t>
</list>
These properties create new challenges on obtaining robust and reliable routing within LoWPANs.
</t>
<t>
The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals" <xref target="RFC4919"/>)
briefly mentions four requirements on routing protocols:
<list>
<t>(a) low overhead on data packets</t>
<t>(b) low routing overhead</t>
<t>(c) minimal memory and computation requirements</t>
<t>(d) support for sleeping nodes considering battery saving</t>
</list>
These four high-level requirements describe the basic requirements for 6LoWPAN routing.
Based on the fundamental features of 6LoWPAN, more detailed routing requirements
are presented in this document, which can lead to further analysis and protocol design.
</t>
<t>
Considering the problems above, detailed 6LoWPAN routing requirements
must be defined. Application-specific features affect the design of
6LoWPAN routing requirements and the corresponding solutions.
However, various applications can be profiled by similar technical
characteristics, although the related detailed requirements might differ
(e.g., a few dozens of nodes in a home lighting system need appropriate
scalability for its applications, while millions of nodes for a
highway infrastructure system also need appropriate scalability).
</t>
<t>
This routing requirements document states the routing requirements of 6LoWPAN
applications in general, providing examples for different cases of routing.
It does not imply a single routing solution to be favorable for all 6LoWPAN applications.
</t>
</section>
<!--=============== TERMINOLOGY ====================-->
<section anchor="terminology" title="Terminology">
<t>
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 <xref target="RFC2119"/>.
</t>
<t>
Readers are expected to be familiar with all the terms and concepts
that are discussed in <xref target="RFC4919">"IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions,
Problem Statement, and Goals"</xref>, and <xref target="RFC4944">
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks"</xref>.
</t>
<t>
This specification makes use of the terminology defined in the
"Neighbor Discovery for 6LoWPAN" <xref target="I-D.ietf-6lowpan-nd"/>.
<!--
and defines the following additional terms:
<list style="hanging">
<t hangText="LoWPAN Mesh Node"></t>
<t>
A LoWPAN node that forwards data between arbitary source-destination pairs
in 6LoWPAN adaptation layer using link-layer addresses (and thus only exist
in Mesh Under LoWPANs). A Mesh Node may also serve as a LoWPAN Host.
</t>
</list>
-->
</t>
</section>
<!--=============== DESIGN SPACE ==============-->
<section title="Design Space">
<t>
Apart from a wide variety of conceivable routing algorithms for 6LoWPAN,
it is possible to perform routing in the IP-layer, using a Route Over approach
or in the adaptation layer defined by the
6LoWPAN format document <xref target="RFC4944"/>, using the Mesh Under approach (see <xref target="NetworkStack"/>).
</t>
<t>
The Route Over approach relies on IP routing and therefore supports
routing over possibly various types of interconnected links.
<vspace/>
Note: The ROLL WG is now working on Route Over approaches for Low power
and Lossy Networks (LLNs), not specifically for 6LoWPAN.
This document focuses on 6LoWPAN-specific requirements; it may be used in
conjunction with the more application-oriented requirements defined by the ROLL WG.
</t>
<t>
The Mesh Under approach performs the multi-hop communication below the IP link.
The most significant consequence of Mesh Under mechanism is that
the characteristics of IEEE 802.15.4 directly affect the 6LoWPAN routing mechanisms,
including the use of 64-bit (or 16-bit short) MAC addresses instead of IP
addresses. A 6LoWPAN would therefore be seen as a single IP link.
</t>
<t>
Most statements in this document consider both the Route Over and Mesh Under cases.
</t>
<figure anchor='NetworkStack' title="Mesh Under (left) and Route Over routing (right)">
<preamble>
<xref target="NetworkStack"/> shows the place of 6LoWPAN routing in the entire network stack.
</preamble>
<artwork>
+-----------------------------+ +-----------------------------+
| Application Layer | | Application Layer |
+-----------------------------+ +-----------------------------+
| Transport Layer (TCP/UDP) | | Transport Layer (TCP/UDP) |
+-----------------------------+ +-----------------------------+
| Network Layer (IPv6) | | Network +---------+ |
+-----------------------------+ | Layer | Routing | |
| 6LoWPAN +---------+ | | (IPv6) +---------+ |
| Adaptation | Routing*| | +-----------------------------+
| Layer +---------+ | | 6LoWPAN Adaptation Layer |
+-----------------------------+ +-----------------------------+
| IEEE 802.15.4 (MAC) | | IEEE 802.15.4 (MAC) |
+-----------------------------+ +-----------------------------+
| IEEE 802.15.4 (PHY) | | IEEE 802.15.4 (PHY) |
+-----------------------------+ +-----------------------------+
* Here, 'Routing' is not equivalent to IP routing,
but includes the functionalities of path computation and
forwarding under the IP layer.
</artwork>
<postamble/>
</figure>
<t>
In order to avoid packet fragmentation and the overhead for reassembly,
routing packets should fit into a single IEEE 802.15.4 physical frame
and application data should not be expanded to an extent that they
no longer fit.
</t>
<!--================================-->
<section title="Reference Network Model">
<t>
For multi-hop communication in 6LoWPAN, when a Route Over mechanism is in use,
all LoWPAN Routers perform IP routing within the stub network.
Not only the ER but also other intermediate nodes become LoWPAN Routers and perform
standard Layer 3 (IP) routing (see <xref target="x6LoWPAN-rover-conf"/>).
In this case, the link-local scope covers the set of nodes within symmetric radio range of a node.
</t>
<t> <!--some text changes, feb 17,2009-->
When a 6LoWPAN follows the Mesh Under configuration,
the LoWPAN Edge Router (ER) is the only IPv6 router in the 6LoWPAN (see <xref target="x6LoWPAN-mesh-conf"/>).
This means that the IPv6 link-local scope includes all nodes in the LoWPAN.
For this, a Mesh Under mechanism MUST be provided to support multi-hop transmission.
</t>
<figure anchor='x6LoWPAN-rover-conf' title="An example of a Route Over LoWPAN">
<preamble></preamble>
<artwork>
h h
/ | ER: Edge Router
ER --- r --- r --- h r: LoWPAN Router
/ \ h: LoWPAN Host
h r --- h
|
/ \
r - r -- h
</artwork>
</figure>
<figure anchor='x6LoWPAN-mesh-conf' title="An example of a Mesh Under LoWPAN">
<preamble></preamble>
<artwork>
h h
/ | ER: Edge Router
ER --- m --- m --- h m: Mesh Node
/ \ h: LoWPAN Host
h m --- h
|
/ \
m - m -- h
</artwork>
</figure>
<t>
When multiple 6LoWPANs are formed with globally unique IPv6 addresses
in the 6LoWPANs, and node (a) of 6LoWPAN [A] wants to communicate
with node (b) of 6LoWPAN [B], the normal IPv6 mechanisms will be employed.
For Route Over, the IPv6 address of (b) is set as the destination of the packets, and
the nodes perform IP routing to the ER for these outgoing packets.
Additionally, a default route to the ER could be inserted into the 6LoWPAN routing system.
For Mesh Under, there is one IP hop from a node (a) to ER of [A],
no matter how many radio hops they are apart from each other. This, of course, assumes
the existence of a Mesh Under routing protocol in order to reach the ER.
</t>
</section>
<!--==============================-->
<section title="6LoWPAN Headers for Routing">
<t>
When a Route Over mechanism is built over the IPv6 layer, the Dispatch value
can be chosen as one of the Dispatch patterns for 6LoWPAN, followed by a compressed
or uncompressed IPv6 header, and Route Over routing header will be included in the payload of IPv6 packet.
The 6LoWPAN compression format for IPv6 Datagrams <xref target="I-D.ietf-6lowpan-hc"/>
includes next header compression (NHC) and the routing header could be followed by NHC.
</t>
<figure anchor='x6LoWPAN-HCRouteOverHeader' title="6LoWPAN IPHC packet format and Route Over routing">
<preamble>
<xref target="x6LoWPAN-HCRouteOverHeader"/> depicts an example of
6LoWPAN encapsulated Route Over routing packets for the new header compression format
defined in <xref target="I-D.ietf-6lowpan-hc"/>:</preamble>
<artwork>
+------------------------+-------------+------------------------+--
|Dispatch + LOWPAN_IPHC | IPv6 Header | Payload(Routing packet)|...
+------------------------+-------------+------------------------+--
+------------------------+-------------+-----+----------------+--
|Dispatch + LOWPAN_IPHC | IPv6 Header | NHC | Routing header |...
+------------------------+-------------+-----+----------------+--
</artwork><postamble/>
</figure>
<t>
In the simplest case for a Mesh Under where layer two forwarding can
be performed without piggy-backing routing protocol information,
the mesh-header defined in RFC 4944 <xref target="RFC4944"/> is sufficient, see <xref target="x6LoWPANmesh"/>.
Frame Delivery in a Link-Layer Mesh is described in the Section 11 in RFC 4944.
</t>
<figure anchor='x6LoWPANmesh' title="6LoWPAN Mesh Header">
<artwork>
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0|V|F|HopsLft| originator address, final address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork><postamble/>
</figure>
<t>
However, beyond the mesh header, additional information may need to be transmitted for full
routing functionality.
If a Mesh Under routing protocol is built for operation in 6LoWPAN's
adaptation layer, routing control packets with MAC addresses are placed after the
6LoWPAN Dispatch. A new Dispatch value is REQUIRED to be assigned, see <xref target="x6LoWPANMeshUnderFHeader"/>.
As shown in <xref target="x6LoWPANMeshUnderFHeader"/>,
multiple routing protocols can be supported by the usage of different
Dispatch bit sequences.
</t>
<figure anchor='x6LoWPANMeshUnderFHeader' title="6LoWPAN packet format with a Mesh Under mechanism">
<artwork>
+---------------------+----------------+---------+----
| Dispatch (new val.) | Routing header | ...
+---------------------+----------------+---------+----
</artwork><postamble/>
</figure>
</section>
</section> <!-- end of Chapter2:Design space-->
<!--========================================================-->
<!--========================================================-->
<!-- start of section 3.scenario and parameters -->
<section anchor="scenarios" title="Scenario Considerations and Parameters for 6LoWPAN Routing">
<t>
IP-based LoWPAN technology is still in its early stage of
development, but the range of conceivable usage scenarios is
tremendous. The numerous possible applications of sensor networks
make it obvious that mesh topologies will be prevalent in LoWPAN
environments and robust routing will be a necessity for expedient
communication. Research efforts in the area of sensor networking
have put forth a large variety of multi-hop routing algorithms
<xref target="refs.bulusu"/>.
Most related work focuses on optimizing
routing for specific application scenarios, which can be realized using
several models of communication, including the following ones <xref target="refs.cctc"/>:
<list style="symbols">
<!-- changes to meet Misha Dohler's comment , feb 17,2009>
<t>Flooding (in very small networks)</t>
<t>Data-aware routing (dissemination vs. gathering)</t>
<t>Event-driven vs. query-based routing</t>
<t>Geographic routing</t>
<t>Probabilistic routing</t>
<t>Hierarchical routing</t>
<-->
<t>Flooding (in very small networks)</t>
<t>Hierarchical routing</t>
<t>Geographic routing</t>
<t>Self-organizing coordinate routing</t>
</list>
Depending on the topology of a LoWPAN and the application(s) running over it,
different types of routing may be used. However, this document abstracts from
application-specific communication and describes general routing requirements
valid for overall routing in LoWPANs.
</t>
<t>
The following parameters can be used to describe specific scenarios
in which the candidate routing protocols could be evaluated.
</t>
<t>
<list style="letters">
<t>Network Properties:
<list style="symbols">
<t>
Number of Devices, Density and Network Diameter: <vspace/>
These parameters usually affect the routing state directly
(e.g. the number of entries in a routing table or neighbor
list). Especially in large and dense networks, policies must
be applied for discarding "low-quality" and stale routing
entries in order to prevent memory overflow.
</t>
<t>
Connectivity: <vspace/>
Due to external factors or programmed disconnections, a LoWPAN
can be in several states of connectivity; anything in the
range from "always connected" to "rarely connected". This
poses great challenges to the dynamic discovery of routes
across a LoWPAN.
</t>
<t>
Dynamicity (including mobility): <vspace/>
Location changes can be induced by unpredictable external
factors or by controlled motion, which may in turn cause route
changes. Also, nodes may dynamically be introduced into a
LoWPAN and removed from it later. The routing state and the
volume of control messages may heavily depend on the number
of moving nodes in a LoWPAN and their speed, as well as how
quickly and frequently environmental characteristics influencing radio propagation change.
</t>
<t>
Deployment: <vspace/>
In a LoWPAN, it is possible for nodes to be scattered randomly
or to be deployed in an organized manner. The deployment can
occur at once, or as an iterative process, which may also
affect the routing state.
</t>
<t>
Spatial Distribution of Nodes and Gateways: <vspace/>
Network connectivity depends on the spatial distribution of the nodes,
and on other factors such as device number, density and transmission
range. For instance, nodes can be placed on a grid, or can be randomly placed in
an area (as can be modeled by a bidimensional Poisson distribution), etc.
In addition, if the LoWPAN is connected to other networks through
infrastructure nodes called gateways, the number and spatial
distribution of gateways affects network congestion and available
data rate, among others.
</t>
<t>
Traffic Patterns, Topology and Applications: <vspace/>
The design of a LoWPAN and the requirements on its application
have a big impact on the network topology and the most efficient routing type to be
used. For different traffic patterns (point-to-point,
multipoint-to-point, point-to-multipoint) and network
architectures, various routing mechanisms have been
developed, such as data-aware, event-driven, address-centric,
and geographic routing.
</t>
<t>
Classes of Service: <vspace/>
For mixing applications of different criticality on one LoWPAN, support of multiple classes of
service may be required in resource-constrained LoWPANs and may
require a certain degree of routing protocol overhead.
</t>
<t>
Security: <vspace/>
LoWPANs may carry sensitive information and require a high
level of security support where the availability, integrity,
and confidentiality of data are of prime relevance. Secured messages
cause overhead and affect the power consumption of LoWPAN
routing protocols.
</t>
</list> <!-- end of network parameters-->
</t>
<t>Node Parameters:
<list style="symbols">
<t>
Processing Speed and Memory Size: <vspace/>
These basic parameters define the maximum size of the routing
state and the maximum complexity of its processing. LoWPAN nodes may have different performance
characteristics.
</t>
<t>
Power Consumption and Power Source: <vspace/>
The number of battery- and mains-powered nodes and their positions in the topology created by them in
a LoWPAN affect routing protocols in their selection of
paths that optimize network lifetime.
</t>
<t>
Transmission Range: <vspace/>
This parameter affects routing. For example, a
high transmission range may cause a dense network, which in
turn results in more direct neighbors of a node, higher
connectivity and a larger routing state.
</t>
<t>
Traffic Pattern: <vspace/>
This parameter affects routing since highly loaded nodes (either
because they are the source of packets to be transmitted or due
to forwarding) may contribute to higher delivery
delays and may consume more energy than lightly loaded nodes.
This applies to both data packets and routing control messages.
</t>
</list> <!--end of node parameters-->
</t>
<t>Link Parameters:
<vspace/>
This section discusses link parameters that apply
to IEEE 802.15.4 legacy mode (i.e. not making use of improved modulation schemes).
<list style="symbols">
<t>
Throughput:
<vspace/>
<vspace/>
The maximum user data throughput of a bulk data transmission between a single sender and
a single receiver through an unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is
as follows <xref target="refs.Latre"/>:
<list style="symbols">
<t>16-bit MAC addresses, unreliable mode: 151.6 kbit/s </t>
<t>16-bit MAC addresses, reliable mode: 139.0 kbit/s </t>
<t>64-bit MAC addresses, unreliable mode: 135.6 kbit/s </t>
<t>64-bit MAC addresses, reliable mode: 124.4 kbit/s </t>
</list>
<vspace/>
<vspace/>
In the case of 915 MHz band:
<list style="symbols">
<t> 16-bit MAC addresses, unreliable mode: 31.1 kbit/s </t>
<t> 16-bit MAC addresses, reliable mode: 28.6 kbit/s </t>
<t> 64-bit MAC addresses, unreliable mode: 27.8 kbit/s </t>
<t> 64-bit MAC addresses, reliable mode: 25.6 kbit/s </t>
</list>
<vspace/>
<vspace/>
In the case of 868 MHz band:
<list style="symbols">
<t> 16-bit MAC addresses, unreliable mode: 15.5 kbit/s </t>
<t> 16-bit MAC addresses, reliable mode: 14.3 kbit/s </t>
<t> 64-bit MAC addresses, unreliable mode: 13.9 kbit/s </t>
<t> 64-bit MAC addresses, reliable mode: 12.8 kbit/s </t>
</list>
</t>
<t>
Latency: <vspace/>
The range of latencies, depending on payload size, of a frame transmission between a single sender and
a single receiver through an unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions
are as shown next <xref target="refs.Latre"/>. For unreliable mode, the actual latency is provided. For reliable mode,
the round-trip-time including transmission of a layer two acknowledgment is provided:
<list style="symbols">
<t> 16-bit MAC addresses, unreliable mode: [1.92 ms, 6.02 ms] </t>
<t> 16-bit MAC addresses, reliable mode: [2.46 ms, 6.56 ms] </t>
<t> 64-bit MAC addresses, unreliable mode: [2.75 ms, 6.02 ms] </t>
<t> 64-bit MAC addresses, reliable mode: [3.30 ms, 6.56 ms] </t>
</list>
<vspace/>
For the 915 MHz band:
<list style="symbols">
<t> 16-bit MAC addresses, unreliable mode: [5.85 ms, 29.35 ms] </t>
<t> 16-bit MAC addresses, reliable mode: [8.35 ms, 31.85 ms] </t>
<t> 64-bit MAC addresses, unreliable mode: [8.95 ms, 29.35 ms] </t>
<t> 64-bit MAC addresses, reliable mode: [11.45 ms, 31.85 ms] </t>
</list>
<vspace/>
For the 868 MHz band:
<list style="symbols">
<t> 16-bit MAC addresses, unreliable mode: [11.7 ms, 58.7 ms] </t>
<t> 16-bit MAC addresses, reliable mode: [16.7 ms, 63.7 ms] </t>
<t> 64-bit MAC addresses, unreliable mode: [17.9 ms, 58.7 ms] </t>
<t> 64-bit MAC addresses, reliable mode: [22.9 ms, 63.7 ms] </t>
</list>
</t>
</list> <!-- end of link parameters-->
</t>
</list> <!-- end of parameter list-->
</t>
</section> <!-- end of Chapter3: Scenarios and Parameters-->
<!--==============================================-->
<!--==============================================-->
<!-- start of section 4.routing requirements -->
<section anchor="Requirements" title="6LoWPAN Routing Requirements">
<t>
This section defines a list of requirements for 6LoWPAN routing.
An important design property specific to low-power networks is that LoWPANs
have to support multiple device types and roles, such as:
<list style="symbols">
<t>host nodes drawing their power from primary batteries or using energy harvesting (both called "power-constrained nodes" in the following)</t>
<t>mains-powered host nodes (an example for what we call "power-affluent nodes")</t>
<t>power-affluent (but not necessarily mains-powered) high-performance gateway(s)</t>
<t>nodes with various functionality (data aggregators, relays, local manager/coordinators, etc.)</t>
</list>
Due to these different device types and roles LoWPANs need to consider
the following two primary attributes:
<list style="symbols">
<t>
Power conservation: some devices are mains-powered, but many are
battery-operated and need to last several months to a few years
with a single AA battery. Many devices are mains-powered most of
the time, but still need to function for possibly extended periods
from batteries (e.g. on a construction site before building power
is switched on for the first time).
</t>
<t>
Low performance: tiny devices, small memory sizes, low-performance
processors, low bandwidth, high loss rates, etc.
</t>
</list>
These fundamental attributes of LoWPANs affect the design of routing
solutions. Whether existing routing specifications are
simplified and modified, or new solutions are introduced in order to
fit the low-power requirements of LoWPANs, they need to meet the requirements
described in the following.
</t>
<!--====================================-->
<!-- start of Section 4.1: Device -->
<section anchor="reqs1" title="Support of 6LoWPAN Device Properties">
<t>
The general objectives listed in this section should be met
by 6LoWPAN routing protocols. The importance of each requirement is
dependent on what node type the protocol is running on and what
the role of the node is. The following requirements consider the presence of battery-powered nodes in LoWPANs.
</t>
<t>
[R01] 6LoWPAN routing protocols SHOULD allow implementation with small code size
and require low routing state to fit the typical 6LoWPAN node capacity.
Generally speaking, the code size is bounded by available flash memory size, and the routing table is bounded by RAM size, possibly limiting it to less than 32 entries.
</t>
<t>
<list>
<t> <!-- R01: small code-->
The RAM size of LoWPAN nodes often ranges between 4 KB (2 KB minimum) and 10 KB,
and program flash memory normally consists of 48 KB to 128 KB.
(e.g., in the current market, MICAz has 128 KB program flash,
4 KB EEPROM, 512 KB external flash ROM; TIP700CM has 48 KB program
flash, 10 KB RAM, 1 MB external flash ROM).
</t>
<t>
Due to these hardware restrictions, code SHOULD
fit within a small memory size; no more than 48 KB to 128 KB of flash memory including
at least a few tens of KB of application code size.
(As a general observation, a routing protocol of low
complexity may help achieving
the goal of reducing power consumption, improves robustness,
requires lower routing state, is easier to analyze, and may be
less prone to security attacks.)
</t>
<t>
In addition, operation with limited amounts of routing state (such as routing tables and neighbor lists)
SHOULD be maintained since some typical memory sizes preclude storing
state of a large number of nodes. For instance, industrial monitoring applications
may need to support at maximum 20 hops <xref target="RFC5673"/>.
Small networks can be designed to support a smaller number of hops.
While the need for this is highly dependent on the network architecture,
there should be at least one mode of operation that can
function with 32 forwarding entries or less.
</t>
</list> <!-- end of R01-->
</t>
<t> <!-- R02: minimal power -->
[R02] 6LoWPAN routing protocols SHOULD cause minimal power
consumption by the efficient use of control packets
(e.g., minimize expensive IP multicast which causes link broadcast to the entire
LoWPAN) and by the efficient routing of data packets.
</t>
<t>
<list>
<t>
One way of battery lifetime optimization is by achieving a minimal
control message overhead. Compared to functions such as
computational operations or taking sensor samples, radio communications
is by far the dominant factor of power consumption <xref target="refs.SmartDust"/>.
Power consumption of transmission and/or reception depends linearly
on the length of data units and on the frequency of transmission
and reception of the data units <xref target="refs.Shih"/>.
</t>
<t>
The energy consumption of two
example RF controllers for low-power nodes is shown in <xref target="refs.Hill"/>.
The TR1000 radio consumes 21 mW when transmitting at 0.75 mW,
and 15 mW on reception (with a receiver sensitivity of -85 dBm).
The CC1000 consumes 31.6 mW when transmitting 0.75 mW, and 20 mW for receiving (with a receiver sensitivity
of -105 dBm). The power endurance under the concept of
an idealized power source is explained in <xref target="refs.Hill"/>.
Based on the energy of an idealized AA battery,
the CC1000 can transmit for approximately 4 days straight or receive
for 9 consecutive days. Note that availability for reception consumes
power as well.
</t>
<t>
As multicast may cause flooding in the LoWPAN, a 6LoWPAN routing
protocol SHOULD minimize the control cost by multicasting routing packets.
</t>
<t>
Control cost of routing protocols in low power and lossy
networks is discussed in more detail in <xref target="I-D.ietf-roll-protocols-survey"/>.
</t>
</list> <!-- end of R03-->
</t>
</section> <!-- end of section 4.1 -->
<!--==================================-->
<!-- start of section 4.2 : Link -->
<section anchor="reqs2" title="Support of 6LoWPAN Link Properties">
<t>
6LoWPAN links have the characteristics of low <!--bandwidth --> data rate and possibly high loss rates.
The routing requirements described in this section are derived from
the link properties.
</t>
<t> <!-- R03: no fragmentation-->
<!-- Proposed text change , eunah, feb 17,2009>
[R03] 6LoWPAN routing protocol control messages SHOULD not create
fragmentation of physical layer (PHY) frames.</t>
<-->
[R03] 6LoWPAN routing protocol control messages SHOULD NOT exceed a single IEEE 802.15.4 frame size
in order to avoid packet fragmentation and the overhead for reassembly.
<!-- give ur opinion on this text changes. i think we need better wording..-->
</t>
<t>
<list>
<t>
In order to save energy, routing overhead should be minimized to
prevent fragmentation of frames.
Therefore, 6LoWPAN routing should not cause packets to exceed the
IEEE 802.15.4 frame size. This reduces the energy required for
transmission, avoids unnecessary waste of bandwidth, and prevents
the need for packet reassembly. As calculated in RFC4944
<xref target="RFC4944"/>, the maximum size of a 6LoWPAN frame,
in order not to cause fragmentation, is 81 octets.
This may imply the use of semantic fragmentation and/or algorithms
that can work on small increments of routing information.
</t>
</list> <!-- end of R03: no fragmentation-->
</t>
<t> <!-- start of R04: NEWLY added on Nov. 3, by EUNAH-->
[R04] The design of routing protocols for LoWPANs must consider the fact that
packets are to be delivered with sufficient probability according to application requirements.
</t>
<t>
<list>
<t>
Requirements on successful end-to-end packet delivery ratio
(where delivery may be bounded within certain latency) vary depending
on applications. In industrial applications, some non-critical monitoring
applications may tolerate successful delivery ratio of less than 90%
with hours of latency; in some other cases, a delivery ratio of 99.9%
is required <xref target="RFC5673"/>. In building automation applications,
application layer errors must be below 0.01% <xref target="I-D.ietf-roll-building-routing-reqs"/>.
</t>
<t>
Successful end-to-end delivery of packets in an IEEE 802.15.4 mesh
depends on the quality of the path selected by the routing protocol and
on the ability of the routing protocol to cope with short-term and long-term quality variation.
The metric of the routing protocol strongly influences performance of
the routing protocol in terms of delivery ratio.
</t>
<t>
The quality of a given path depends on the individual qualities of the links
(including the devices) that compose that path. IEEE 802.15.4 settings affect
the quality perceived at upper layers. In particular, in IEEE 802.15.4 reliable mode,
if an acknowledgment frame is not received after a given period,
the originator retries frame transmission up to a maximum number of times.
If an acknowledgment frame is still not received by the sender
after performing the maximum number of transmission attempts,
the MAC layer assumes the transmission has failed and notifies the next
higher layer of the failure. Note that excessive retransmission may be detrimental,
see RFC 3819 <xref target="RFC3819"/>.
</t>
</list>
</t>
<t> <!-- start of R05: NEWLY added on Nov. 17 -->
[R05] The design of routing protocols for LoWPANs must consider the
<!-- deleted by Alex comment, Carles suggestion on it- - -end-to-end -->latency requirements of applications and IEEE 802.15.4 link latency characteristics.
</t>
<t>
<list>
<t>
Latency requirements may differ from a few hundreds milliseconds to minutes,
depending on the type of application.
Real-time building automation applications usually need response times
below 500 ms between egress and ingress, while
forced entry security alerts must be routed to one or more fixed or mobile user devices
within 5 s <xref target="I-D.ietf-roll-building-routing-reqs"/>.
Non-critical closed loop applications for industrial automation
have latency requirements that can be as low as 100 ms but many control loops are
tolerant of latencies above 1 s <xref target="RFC5673"/>. In contrast to this,
urban monitoring applications allow latencies smaller than the typical intervals used for
reporting sensed information; for instance, in the order of seconds to
minutes <xref target="RFC5548"/>.
</t>
<t>
The range of latencies of a frame transmission between a single
sender and a single receiver through an ideal unslotted IEEE 802.15.4
2.4 GHz channel is between 2.46 ms and 6.02 ms in 64 bit MAC address
unreliable mode and 2.20 ms to 6.56 ms in 64 bit address reliable
mode. The range of latencies of 868 MHz band is from 11.7 ms to
63.7 ms, depending on the address type and reliable/unreliable
mode used. Note that the latencies may be larger than that depending
on channel load, MAC layer settings
procedure-->, and reliable/unreliable mode choice.
Note that other MAC approaches than the legacy 802.15.4 may be used (e.g. TDMA).
Duty cycling may further affect latency (see [R08]).
</t>
<t>
Note that a tradeoff exists between [R05] and [R04].
</t>
</list> <!-- end of R05-->
</t>
<t> <!-- start of R06-->
[R06] 6LoWPAN routing protocols SHOULD be robust to dynamic loss
caused by link failure or device unavailability either in
the short term
(e.g. due to RSSI variation, interference variation, noise and asynchrony)
or in the long term (e.g. due to a depleted power source, hardware breakdown,
operating system misbehavior, etc.).
</t>
<t>
<list>
<t>
An important trait of 6LoWPAN devices is their unreliability due to
limited system capabilities, and also because they might be closely
coupled to the physical world with all its unpredictable variation.
In harsh environments, LoWPANs easily suffer from
link failure. Collision or link failure easily increases send
and receive queues and can lead to queue overflow and
packet losses.
</t>
<t>
For home applications, where users expect feedback after carrying out actions
(such as handling a remote control while moving around),
routing protocols must converge
within 2 seconds if the destination node of the packet has moved
and must converge within 0.5 seconds if only the sender has moved <xref target="I-D.ietf-roll-home-routing-reqs"/>.
The tolerance of the recovery time can vary depending on the application,
however, the routing protocol must provide the detection of short-term unavailability
and long-term disappearance.
The routing protocol has to exploit network resources (e.g. path redundancy)
to offer good network behavior despite of node failure.
</t>
</list> <!-- end of R06-->
</t>
<t>
[R07] 6LoWPAN routing protocols SHOULD be designed to correctly operate in the presence of link asymmetry.
</t>
<t>
<list>
<t>
Link asymmetry occurs when the probability of successful transmission
between two nodes is significantly higher in one direction than in
the other one. This phenomenon has been reported in a large number of
experimental studies and it is expected that 6LoWPANs will exhibit
link asymmetry.
</t>
</list>
</t>
</section>
<!-- end of section 4.2: link -->
<!--======================================-->
<!-- start of section 4.3 : Network-->
<section anchor="reqs3" title="Support of 6LoWPAN Network Characteristics">
<t>
6LoWPANs can be deployed in different sizes and topologies,
adhere to various models of mobility, be exposed to various levels of interference, etc.
In any case, LoWPANs must maintain low energy consumption.
The requirements described in the following subsection are derived
from the network attributes of 6LoWPANs.
</t>
<t> <!-- R08: sleep node-->
[R08] 6LoWPAN routing protocols SHOULD be reliable despite unresponsive nodes
due to periodic hibernation.
</t>
<t>
<list>
<t>
Many nodes in LoWPAN environments might periodically hibernate
(i.e. disable their transceiver activity) in order to save energy.
Therefore, routing protocols must ensure robust packet
delivery despite nodes frequently shutting off their radio
transmission interface. Feedback from the lower IEEE 802.15.4 layer may be considered
to enhance the power-awareness of 6LoWPAN routing protocols.
</t>
<t>
CC1000-based nodes must operate at a duty cycle
of approximately 2% to survive for one year from idealized AA battery power source
<xref target="refs.Hill"/>.
For home automation purposes, it is suggested
that the devices have to maximize the sleep phase with a duty cycle lower
than 1% <xref target="I-D.ietf-roll-home-routing-reqs"/>, while in building automation applications,
batteries must be operational
for at least 5 years when the sensing devices are transmitting data (e.g. 64 bytes) once
per minute <xref target="I-D.ietf-roll-building-routing-reqs"/>.
</t>
<t>
Dependent on the application in use, packet rates may range
from one per second to one per day or beyond.
Routing protocols may take advantage of knowledge about
the packet transmission rate
and utilize this information in calculating routing paths.
</t>
</list> <!-- end of R08-->
</t>
<t> <!-- R09: metrics -->
[R09] The metric used by 6LoWPAN routing protocols MAY utilize
a combination of the inputs provided by the lower layers and other measures
to optimize path selection considering energy balance and link qualities.
</t>
<t>
<list>
<t>
In homes, buildings, or infrastructure, some nodes will be installed
with mains power. Such power-installed nodes MUST be considered
as relay points for a prominent role in packet delivery.
6LoWPAN routing protocols MUST know the power constraints of the nodes.
</t>
<t>
Simple hop-count-only mechanisms may be inefficient in 6LoWPANs.
There is a Link Quality Indication (LQI), or/and RSSI from
IEEE 802.15.4 that may be taken into account for better metrics.
The metric to be used (and its goal) may depend on
applications and requirements.
</t>
<t>
The numbers in <xref target="LDR"/> represent the Link Delivery Ratio (LDR)
of each pair of nodes. There are studies that show a piecewise linear dependence between LQI and
LDR <xref target="refs.Chen"/>.
</t>
<t>
<figure anchor='LDR' title="An example network">
<preamble></preamble>
<artwork>
0.6
A-------C
\ /
0.9 \ / 0.9
\ /
B
</artwork>
</figure>
</t>
<t>
In this simple example, there are two options in routing from node A
to node C, with the following features:
<list style="letters">
<t>Path AC:
<list style="symbols">
<t>(1/0.6) = 1.67 avg. transmissions needed for each packet (confirmed link layer delivery with retransmissions and negligible ACK loss have been assumed) </t>
<t>one-hop path</t>
<t>good in energy consumption and end-to-end latency of data packets, bad in delivery ratio (0.6)</t>
<t>bad in probability of route reconfigurations</t>
</list>
</t>
<t>Path ABC:
<list style="symbols">
<t>(1/0.9)+(1/0.9) = 2.22 avg. transmissions needed for each packet (under the same assumptions as above) </t>
<t>two-hop path</t>
<t>bad in energy consumption and end-to-end latency of data packets, good in delivery ratio (0.81)</t>
</list>
</t>
</list>
</t>
<t>
If energy consumption of the network must be minimized,
path AC is the best (this path would be chosen based on a hop count
metric). However, if the delivery ratio in that case is not sufficient,
the best path is ABC (it would be chosen by an LQI based metric).
Combinations of both metrics can be used.
</t>
<t>
The metric also affects the probability of route reconfiguration.
Route reconfiguration, which may be triggered by packet losses,
may require transmission of routing protocol messages.
It is possible to use a metric aimed at selecting the path with low route
reconfiguration rate by using LQI as an input to the metric.
Such a path has good properties, including stability and low control message overhead.
</t>
</list> <!-- end of R09:metrics-->
</t>
<t> <!-- R10-->
[R10] 6LoWPAN routing protocols SHOULD be designed to achieve both
scalability from a few nodes to maybe millions of nodes and minimality in terms of used system resources.
</t>
<t>
<list>
<t>
A LoWPAN may consist of just a couple of nodes (for instance in
a body-area network), but may also contain much higher numbers of
devices (e.g. monitoring of a city infrastructure or a highway).
For home automation applications it is envisioned that the routing protocol
must support 250 devices in the network <xref target="I-D.ietf-roll-home-routing-reqs"/>,
while routing protocols for metropolitan-scale sensor networks must be capable of clustering
a large number of sensing nodes into regions
containing on the order of 10^2 to 10^4 sensing nodes each <xref target="RFC5548"/>.
It is therefore necessary that routing mechanisms are designed
to be scalable for operation in various network sizes. However,
due to a lack of memory size and computational power, 6LoWPAN
routing might limit forwarding entries to a small number, such
as at maximum 32 routing table entries.
</t>
</list> <!--end of R10-->
</t>
<t> <!--R11 -->
[R11] The procedure of route repair and related control messages
should not harm overall energy consumption from the routing protocols.
</t>
<t>
<list>
<t>
Local repair improves throughput and end-to-end latency, especially
in large networks. Since routes are repaired quickly, fewer data
packets are dropped, and a smaller number of routing protocol
packet transmissions are needed since routes can be repaired without
source initiated Route Discovery <xref target="refs.Lee"/>.
One important consideration here may be to avoid premature
energy depletion, even in case that impairs other requirements.
</t>
</list> <!-- end of R11-->
</t>
<t> <!-- R12-->
[R12] 6LoWPAN routing protocols SHOULD allow for dynamically adaptive
topologies and mobile nodes. When supporting dynamic topologies and
mobile nodes, route maintenance should keep in mind the goal of
a minimal routing state and routing protocol message overhead.
</t>
<t>
<list>
<t>
Building monitoring applications, for instance, require that the mobile devices
SHOULD be capable of leaving (handing-off) from an old network joining
onto a new network within 15 seconds <xref target="I-D.ietf-roll-building-routing-reqs"/>.
More interactive applications such as used in home automation systems, where users are giving input
and expect instant feedback, mobility requirements are also stricter and,
for moves within a network,
a convergence time below 0.5 seconds is commonly required <xref target="I-D.ietf-roll-home-routing-reqs"/>.
In industrial environments, where mobile equipment such as cranes
move around, the support of vehicular speeds of up to 35 km/h are
required to be supported by the routing protocol <xref target="RFC5673"/>.
Currently, 6LoWPANs are not normally being used for such a fast mobility,
but dynamic association and disassociation MUST be supported in 6LoWPAN.
</t>
<t>
There are several challenges that should be addressed by a 6LoWPAN
routing protocol in order to create robust routing in dynamic
environments:
<list style="symbols">
<t> Mobile nodes changing their location inside a LoWPAN:
<vspace/>
If the nodes' movement pattern is unknown, mobility cannot
easily be detected or distinguished by the routing protocols.
Mobile nodes can be treated as nodes that disappear and re-appear
in another place. Movement pattern tracking increases complexity and can be
avoided by handling moving nodes using reactive route updates.
</t>
<t> Movement of a LoWPAN with respect to other (inter)connected LoWPANs:
<vspace/>
Within stub networks, more powerful gateway nodes need to be
configured to handle moving LoWPANs.
</t>
<t> Nodes permanently joining or leaving the LoWPAN:
<vspace/>
In order to ease routing table updates, reduce their size, and minimize error
control messages, nodes leaving the network may announce their
disassociation to the closest edge router
<!-- eunah inserted the following . feb.18,2009 -->or if any, to a specific node which takes charge of
local association and disassociation.
</t>
</list> <!--end of symbol list-->
</t>
</list> <!-- end of R12-->
</t>
<t> <!-- R13: traffic pattern -->
[R13] A 6LoWPAN routing protocol SHOULD support various traffic patterns:
point-to-point, point-to-multipoint, and multipoint-to-point,
while avoiding excessive multicast traffic in a LoWPAN.
</t>
<t>
<list>
<t>
6LoWPANs often have point-to-multipoint or multipoint-to-point
traffic patterns. Many emerging applications include point-to-point
communication as well. 6LoWPAN routing protocols should
be designed with the consideration of forwarding packets from/to
multiple sources/destinations. Current documents of the ROLL working group
explain that the workload or traffic pattern of use cases for
LoWPANs tends to be highly structured, unlike the any-to-any data
transfers that dominate typical client and server workloads. In many
cases, exploiting such structure may simplify difficult problems
arising from resource constraints or variation in connectivity.
</t>
</list> <!-- end of R13-->
</t>
</section>
<!-- end of section 4.3-->
<!--======================================-->
<!-- start of section :4.4 security -->
<section anchor="reqs4" title="Support of Security">
<t>
The routing requirement described in this subsection allows secure
transmission of routing messages. Solutions may take into account the
specific features of IEEE 802.15.4 MAC layers.
</t>
<t> <!-- R14: security-->
[R14] 6LoWPAN protocols SHOULD support secure delivery of control messages.
A minimal security level can be achieved by utilizing the AES-based mechanism
provided by IEEE 802.15.4.
</t>
<t>
<list>
<t>
Security threats within LoWPANs may be different from existing
threat models in ad-hoc network environments. Neighbor Discovery
in IEEE 802.15.4 links may be susceptible to threats as listed in
RFC3756 <xref target="RFC3756"/>. Bootstrapping may also impose additional threats.
Security is also very important for designing robust routing
protocols, but it should not cause significant transmission
overhead. While there are applications which require very high security,
such as in traffic control, other applications are less easily harmed by
wrong node behavior, such as a home entertainment system.
</t>
<t>
The IEEE 802.15.4 MAC provides an AES-based security mechanism. Routing
protocols need to define how this mechanism can be used to obtain
the intended security, either for the routing protocol alone or
in conjunction with the security used for the data. Byte overhead of the mechanism, which depends
on the security services selected, must be considered. In the worst
case in terms of overhead, the mechanism consumes 21 bytes of MAC
payload.
</t>
<t> <!-- This is inserted to resolve Issue Tracker #4. Suggested by Carles, Feb. 18.2009 -->
IEEE 802.15.4 does not specify protection for acknowledgement frames.
Since the sequence numbers of data frames are sent in the clear,
an adversary can forge an acknowledgement for each data frame.
This weakness can be combined with targeted jamming to prevent delivery of
selected packets. In consequence, IEEE 802.15.4 acknowledgements cannot be relied upon.
In applications that require high security, the routing protocol must not exploit
feedback from acknowledgements (e.g. to keep track of neighbor connectivity, see [R16]).
</t>
</list> <!-- end of R14 -->
</t>
</section>
<!-- end of section: 4.4 secuirty -->
<!--==========================================-->
<!-- start of section: 4.5 mesh-under -->
<section anchor="reqs5" title="Support of Mesh-under Forwarding">
<!-- The following text is deleted by Carles, Feb.18.2009 >
Reception of an acknowledgement after a frame transmission may
render unnecessary the transmission of explicit Hello messages, for example.
</t -->
<t> <!-- The following text is inserted instead of the above text -->
One LoWPAN may be built as one IPv6 link. In this case, Mesh Under
forwarding/routing mechanisms must be supported. The routing requirements
described in this subsection allow optimization and correct operation
of routing solutions taking into account the specific features of the mesh-under configuration.
</t>
<t>
[R15] When a routing protocol operates in 6LoWPAN's adaptation layer,
routing tables and neighbor lists MUST support 16-bit short and
64-bit extended addresses.
</t>
<t>
[R16] In order to perform discovery and maintenance of neighbors
(i.e., neighborhood discovery as opposed to ND-style neighbor discovery),
LoWPAN Nodes SHOULD avoid sending separate "Hello" messages.
Instead, link-layer mechanisms (such as acknowledgments) MAY be utilized
to keep track of active neighbors.
</t>
<t>
<list>
<t>
Reception of an acknowledgement after a frame transmission may render
unnecessary the transmission of explicit Hello messages, for example.
In a more general view, any frame received by a node may be used as an input
to evaluate the connectivity between the sender and receiver of that frame.
</t>
</list>
</t>
<t>
[R17] In case there are one or more nodes allocated for the
specific role of local management, such a management node MAY take the
role of keeping track of nodes within the area of the LoWPAN it takes responsibility for.
</t>
<t>
[R18] If the routing protocol functionality includes enabling IP multicast,
then it may want to employ structure in the network for efficient
distribution <xref target="I-D.ietf-manet-smf"/>, such as Connected Dominating Sets
(CDS), Multi-Point Relays (MPR), or relay points sending
point-to-multipoint messages in unicast messages instead
of using link-layer multicast (broadcast).
</t>
</section>
<!-- end of mesh-under req -->
</section>
<!-- end of Requirement section-->
<!--========================================-->
<!--========================================-->
<section title="Security Considerations">
<t>
Security issues are described in Section 4.4 of the security considerations
of RFC 4919 <xref target="RFC4919"/> and RFC 4944 <xref target="RFC4944"/> apply as well.
</t>
<t>
The use of wireless links renders a 6LoWPAN susceptible to attacks
like any other wireless network.
In outdoor 6LoWPANs, the physical exposure of the nodes
allows an adversary to capture, clone or tamper with these devices.
In ad-hoc 6LoWPANs that are dynamic in both their topology and node memberships,
a static security configuration does not suffice.
Spoofed, altered, or replayed routing information might occur while
multihopping could delay the detection and treatment of attacks.
</t>
<t>
This specification expects that the link layer is sufficiently protected,
either by means of physical or IP security for the backbone link or with
MAC sublayer cryptography.
However, link-layer encryption and authentication may not be sufficient
to provide data confidentiality, data authentication, data integrity, and data freshness.
Time synchronization, self-organization and secure localization
for multi-hop routing are also critical to support.
</t>
<t>
For secure multi-hop routing it may be necessary to consider authenticated
broadcast (and multicast) and bidirectional link verification.
Multi-path routing could be considered for increasing security
to prevent selective forwarding.
However, the challenge is that 6LoWPANs already have high resource constraints,
so that ER and LoWPAN nodes may require different security solutions.
</t>
</section>
<section title="IANA Considerations">
<t>
This document has no actions for IANA.
</t>
</section>
<section title="Acknowledgements">
<t>The authors thank Myung-Ki Shin for giving the idea of writing this draft.
The authors also thank S. Chakrabarti who gave valuable
comments for mesh-under requirements and A. Petrescu for
significant review.</t>
</section>
</middle>
<back>
<references title='Normative References'>&RFC2119;&RFC3756;&RFC4919;&RFC4944;&RFC3819;&RFC5548;&RFC5673;
<reference anchor="IEEE802.15.4">
<front>
<title>IEEE Std. 802.15.4-2006 (as amended)</title>
<author><organization>IEEE Computer Society</organization></author>
<date month="" year="2007"/>
</front>
</reference>
</references>
<references title='Informative References'>
<reference anchor="refs.bulusu">
<front>
<title>Wireless Sensor Networks</title>
<author initials="N." surname="Bulusu" fullname="Nirupama Bulusu">
<organization/>
</author>
<author initials="S." surname="Jha" fullname="Sanjay Jha">
<organization/>
</author>
<date month="July" year="2005"/>
</front>
</reference>
&I-D.ietf-6lowpan-nd;
&I-D.ietf-6lowpan-hc;
<reference anchor="refs.SmartDust">
<front>
<title>Smart Dust: Wireless Networks of Millimeter-Scale Sensor Nodes</title>
<author initials="K. S. J." surname="Pister" fullname="">
<organization/>
</author>
<author initials="B. E." surname="Boser" fullname="">
<organization/>
</author>
<date month="" year=""/>
</front>
</reference>
<reference anchor="refs.Hill">
<front>
<title>System Architecture for Wireless Sensor Networks</title>
<author initials="J." surname="Hill" fullname="J. Hill">
<organization/>
</author>
<date month="" year=""/>
</front>
</reference>
<reference anchor="refs.Lee">
<front>
<title>Scalability Study of the Ad Hoc On-Demand Distance-Vector Routing Protocol</title>
<author initials="S. J." surname="Lee" fullname="">
<organization/>
</author>
<author initials="E. M." surname="Belding-Royer" fullname="">
<organization/>
</author>
<author initials="C. E." surname="Perkins" fullname="">
<organization/>
</author>
<date month="March" year="2003"/>
</front>
</reference>
<reference anchor="refs.Shih">
<front>
<title>Physical Layer Driven Protocols and Algorithm Design for Energy-Efficient Wireless Sensor Networks</title>
<author initials="E." surname="Shih" fullname="">
<organization/>
</author>
<date month="July" year="2001"/>
</front>
</reference>
<reference anchor="refs.Chen">
<front>
<title>Ad-Hoc Multicast Routing on Resource-Limited Sensor Nodes</title>
<author initials="B." surname="Chen" fullname="">
<organization/>
</author>
<author initials="K. K." surname="Muniswamy-Reddy" fullname="">
<organization/>
</author>
<author initials="M." surname="Welsh" fullname="">
<organization/>
</author>
<date month="" year="2006"/>
</front>
</reference>
&I-D.ietf-roll-home-routing-reqs;
&I-D.ietf-roll-building-routing-reqs;
&I-D.ietf-roll-protocols-survey;
<reference anchor="refs.Latre">
<front>
<title>Throughput and Delay Analysis of Unslotted IEEE 802.15.4</title>
<author initials="M." surname="Latre" fullname="">
<organization/>
</author>
<author initials="P." surname="De Mil" fullname="">
<organization/>
</author>
<author initials="I." surname="Moerman" fullname="">
<organization/>
</author>
<author initials="B." surname="Dhoedt" fullname="">
<organization/>
</author>
<author initials="P." surname="Demeester" fullname="">
<organization/>
</author>
<date month="May" year="2006"/>
</front>
</reference>
<reference anchor="refs.cctc">
<front>
<title>Quantifying Organization by Means of Entropy</title>
<author initials="J." surname="Lu" fullname="">
<organization/>
</author>
<author initials="F." surname="Valois" fullname="">
<organization/>
</author>
<author initials="M." surname="Dohler" fullname="">
<organization/>
</author>
<author initials="D." surname="Barthel" fullname="">
<organization/>
</author>
<date year="2008"/>
</front>
</reference>
&I-D.ietf-manet-smf;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:01:23 |