Network Working Group L. Toutain
Internet-Draft N. Montavont
Intended status: Informational Institut TELECOM ; TELECOM
Expires: January 1, 2011 Bretagne
D. Barthel
France Telecom R&D
June 30, 2010
Neighbor Discovery Suppression
draft-toutain-6lowpan-ra-suppression-01.txt
Abstract
We propose to strongly reduce the usage of Neighbor Discovery in WSN
by ignoring the global IPv6 prefix inside the WSN. The IPv6 prefix
will be added (resp. removed) by the Border Router during the header
decompression (resp. compression). This proposal has three main
advantages: (i) reduce the number of exchanges inside the WSN, (ii)
reduce the time needed by a sensor node to join the WSN (this is
important when sensors are moving inside the WSN) and finally (iii)
simplify multi-homing management. This document also studies the
impact of this proposal on different architectures (star, mesh, route
over) with LOWPAN_IPHC Encoding Format.
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 January 1, 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
Toutain, et al. Expires January 1, 2011 [Page 1]
Internet-Draft RA Suppression June 2010
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Existing protocols for LoWPAN . . . . . . . . . . . . . . . . 3
2.1. Neighbor Discovery in LoWPAN . . . . . . . . . . . . . . . 3
2.2. Header compression . . . . . . . . . . . . . . . . . . . . 5
3. Suppression of solicited RA . . . . . . . . . . . . . . . . . 5
3.1. Star Topology Packet Format . . . . . . . . . . . . . . . 6
3.2. Mesh Topology Packet Format . . . . . . . . . . . . . . . 7
3.3. Routed Topology Packet Format . . . . . . . . . . . . . . 9
4. ULP checksum adaptation . . . . . . . . . . . . . . . . . . . 9
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Toutain, et al. Expires January 1, 2011 [Page 2]
Internet-Draft RA Suppression June 2010
1. Introduction
6LoWPAN WG aims to adapt IPv6 and associated protocols to sensor
network environment. This leads to two categories of standards:
those to transport IPv6 packets on LoWPAN links and those used to
adapt associated protocols such as Neighbor Discovery Protocol (NDP)
to 6LoWPAN environment. In this document, we propose a new approach
to the address management, compatible with the ones already defined
and that can be used to avoid running NDP on LoWPAN. We discuss the
validity of this proposal in different topologies cases (star, mesh
under and route over) and the implication of its use on the 6LoWPAN
header compression mechanisms.
2. Existing protocols for LoWPAN
2.1. Neighbor Discovery in LoWPAN
While some solutions have been proposed to optimize the encapsulation
of NDP messages, the load imposed by this protocol is still almost
equivalent in WSN and in Ethernet-based networks.
[I-D.ietf-6lowpan-nd] lists the differences between NDP defines in
[RFC4861] and the adaptation for LoWPAN.
In the past, some proposals have suggested limiting the use of
broadcast because of energy constraint, by maintaining stateful
information in the LoWPAN Border Router (LBR).
[I-D.chakrabarti-6lowpan-ipv6-nd] proposes some optimizations to
minimize the number of messages generated by NDP and to limit the use
of broadcasts in the network. NDP functionalities are concentrated
in the LBR instead of being distributed in the network. Duplicate
Address Detection (DAD) and Neighbor Solicitation (NS) are performed
with point-to-point requests from the sensors to the LBR rather than
with multicast packets spanning the whole WSN. Furthermore, nodes
intercept initial multicast Router Solicitation (RS) messages and
forward them directly to the PC instead of broadcasting them to the
whole network.
[I-D.thubert-6lowpan-backbone-router] extends the above proposal by
allowing multiple routers in a WSN to share the same prefix. LBR
only have a partial view of the addresses allocated on the WSN. They
use a transit link to proxy NS for DAD and address resolution
procedures. In addition, backbone routers have an L2 anycast address
allowing sensors to easily contact the closest router.
These solutions have evolved to a consensus among 6LoWPAN WG,
described in [I-D.ietf-6lowpan-nd] which releases some constraints
imposed by [RFC4861]. DAD is no more mandatory for IID built on
Toutain, et al. Expires January 1, 2011 [Page 3]
Internet-Draft RA Suppression June 2010
well-known unique values (such as EUI-64 or DHCP allocated
addresses). If DAD is needed, the query is sent to the LBR which
will check the uniqueness of the address. Periodic Router
Advertisements are disabled and nodes have to explicitly request RA
through RS. Some options are added in RA to maintain a mapping
between well known prefixes and a context value.
One major question is what is the need for source prefixes inside the
WSN. In fact, prefix allocation requires a protocol which is
difficult to deploy in a WSN environment and, once allocated,
prefixes may require a more complex management of the network. For
instance, none of these proposals touches on multi-homing or
interaction with routing protocol such as RPL. Figure 1 shows a very
simple network with two LBR announcing different prefixes in the
LoWPAN.
+----+ +----+
/-----| R1 |---------------| R2 |-----\
| +----+ +----+ |
| o o o |
| o O |
| A o |
\-------------------------------------/
Figure 1: Address compression with RFC 4944
This is a very classical multi-homing problem in IPv6. Node A
selects a prefix announced by router R2, but packets are routed
through R1. R1's ISP may reject the packet since the prefix of the
source address ? was not allocated by this ISP.
Our motivation is to avoid announcing the IPv6 prefix to sensors that
do not need to know their global IPv6 address, while still
guaranteeing end-to-end communication between any equipment in the
Internet and these sensors. Indeed, some categories of sensors do
not require the knowledge of the prefix used in the network, i.e.,
their source address, as long as gateways are able to add and remove
this information. For instance:
o a mobile sensor unidirectionally reporting periodic values to a
central database located outside the WSN does not need to know its
IPv6 address;
o a fixed sensor may have its address stored in the DNS database and
can therefore be contacted from outside the WSN without having to
know its own global address.
Our proposal does not require any change to the 6LoWPAN header
compression scheme [I-D.ietf-6lowpan-hc] that suppresses the source
Toutain, et al. Expires January 1, 2011 [Page 4]
Internet-Draft RA Suppression June 2010
network prefix in compressed IPv6 headers.
2.2. Header compression
6LoWPAN defines in [I-D.ietf-6lowpan-hc] a header compression scheme
that divides the IPv6 address into the two distinct parts, the prefix
and the interface identifier. The source address is compressed using
the following algorithm. A first bit (SAC) in the compressed header
tells if the source address is link-local or global, then two bits
(SAM) indicate the length of the elided part:
o 00: the address is sent in extenso,
o 01: only the 64 bits of the IID are sent,
o 10: 16 last bits of the IID are sent inline,
o 11: the whole source address is elided and the IID will be
reconstructed using the Layer 2 source address.
Except when SAM value is 00, the source prefix is not sent nor
received by the Sensor Node. When a context is specified (CID=1), up
to 16 prefix can be compressed. The relationship between the context
value and the prefix can be carried in modified RA messages as
described in [I-D.ietf-6lowpan-nd]. We propose to reserve value 15
for prefix not announced through RA. The compression method for the
destination address is almost the same based on the DAC and DAM bits.
3. Suppression of solicited RA
We propose not to distribute the IPv6 prefix inside the LoWPAN, which
totally avoids the need for sending RS / RA exchange. Suppressing
the initial RS/RA exchange requires the following changes in sensor
nodes' behavior:
o Sensor nodes do not learn the source prefix(es). With 6LoWPAN
header compression, using the source address prefix can be avoided
on the link, since a context value may be carried in the
compressed header.
o sensor nodes do not know their default router's address. In
Route-Over, the IPv6 address of the default LBR can be learned
from the routing protocol. For other topologies (star and mesh-
under), we propose to use a predefined Layer 2 anycast address to
identify default routers. (see sections Section 3.1 and
Section 3.2)
We reserve a context value (e.g., 0xF) to indicate that the prefix is
not carried in LoWPAN. The value OxF may be chosen in order to be
compatible with current implementations. In the following we discuss
the three different topologies star, mesh-under and route-over. We
finish the section by given sensor nodes and LBR behavior.
Toutain, et al. Expires January 1, 2011 [Page 5]
Internet-Draft RA Suppression June 2010
3.1. Star Topology Packet Format
In a Star topology (i.e. all the Sensor nodes are directly connected
to the LBR), the source address of a packet generated by a sensor
node can be totally elided (SAM=11) and the LBR may use the L2
information in the frame to reconstruct the IID. The destination
address field should be the default router L2 address, which is
usually learned from RA messages. If no RA is sent, the sensor node
does not know the L2 address of the default router. To solve this
issue, sensors may be configured with a predefined L2 anycast address
that will be used when no L2 unicast address is known. The context
value of the compression header must be 0xF for the source address
prefix (i.e. the LBR must add the prefix and recompute L4 checksum).
On the reverse path (from the LBR to the sensor node), 0xF indicates
that the gateway has removed the prefix and has adapted the L4
checksum (see section Section 4).
From Sensor Node to LBR:
+-----------L2---------+----------6LP---------------------+---
|DA=L2Anycast SA=SN | CID=1 SAC=1 SAM=11 | ... 0xFx ...| ULP
+----------------------+----------------------------------+---
Form LBR to Sensor Node:
+-----------L2---------+----------6LP----------------------+---
|DA=SN SA=LBR | CID=1 DAC=1 DAM=11 | ... 0xxF ... | ULP
+----------------------+-----------------------------------+---
Figure 2: Packet Header in Star Toplogy
Consider Figure Figure 3 where a star topology with a sensor node
located in an area reachable by two LBRs is represented. The use of
an anycast address could make the two LBR to both forward packets
from the sensor node (to an outside network, e.g., the Internet) with
several (two in the case of Figure Figure 3) different source
addresses, composed of the (different) prefixes associated with each
LBR and the same interface ID.
To avoid this, the anycast address should only be used with the first
frames when the LBR address is unknown; when a Sensor Node receives a
reply from a LBR, it uses this address as unicast instead of the L2
anycast address.
Toutain, et al. Expires January 1, 2011 [Page 6]
Internet-Draft RA Suppression June 2010
---------+-----------+-------
| |
+--+--+ +--+--+
| LBR | _| LBR |
,'| |`.,' | |.
` +-----+ `` +-----+ `
/ / \ \
| | | |
| |(S) | |
| | | |
\ \ / /
. PANid1 \/ PANid2 /
',pref1 ,'',pref2 ,
`''-''` `''-''`
Figure 3: Star Topology
3.2. Mesh Topology Packet Format
In a Mesh topology, "routing" is done at layer 2. [RFC4944] provides
a mesh header to carry the source and destination addresses. The
Layer 2 header carries hop-by-hop source and destination addresses.
From Sensor Node to LBR:
+--------L2----+----mesh----+----------HC----------------------+---
|DA=hop SA=hop | SN Anycast | CID=1 SAC=1 SAM=11 | ... 0xFx ...| ULP
+--------------+------------+----------------------------------+---
Form LBR to Sensor Node:
+--------L2----+----mesh----+----------HC----------------------+---
|DA=hop SA=hop | LBR SN | CID=1 SAC=1 SAM=11 | ... 0xFx ...| ULP
+--------------+------------+----------------------------------+---
Figure 4: Packet Header in Star Toplogy
Figure 5 represents a mesh topology; a routing protocol at layer 2
allows establishing the routes in the sensors network, especially
from the sensor nodes to the LBR(s). Just as in the star topology,
L2 anycast address can be used by the sensor nodes to reach a LBR
(the L2 anycast address can be viewed as an identifier of a virtual
equipment). LBR must inject routes to this L2 anycast address, so
every nodes can forward packets to the closest LBR. A layer-2
anycast address is used in the mesh header only when a sensor node
Toutain, et al. Expires January 1, 2011 [Page 7]
Internet-Draft RA Suppression June 2010
sends a packet and can only be used as the destination address. The
next hop is obtained from the mesh routing table. In Figure 5 S
sends a packet toward the gateway. The route goes through R which is
in reach of two gateways. Since R has to select a Next Hop only one
LBR will receive the packet even if several LBRs share the same
PANid.
Anycast addresses should not be used as source addresses. Therefore,
when a gateway forwards a packet to a sensor node, it sets the
latter's physical address in the mesh header.
One drawback of this approach appears when messages sent by the
sensor have to be fragmented: if the routes are unstable within the
sensor network, some fragments may reach one default router and other
fragments another router, making reassembly impossible. However,
such situation is expected to be very uncommon and the sensors may
use the LBR address received in the mesh header to increase
stability. A trade-off is required between the sensors' mobility and
the stability of the default router location.
The use of anycast addresses is also a solution for the issue of dead
router detection. When a LBR fails, the routing protocol
automatically forwards the frame to another active LBR.
-------+----------------------------+--------------
| |
+-+--+ +--+-+
/---| |----------------------| |------\
| | PC1|X------\ /-------->| PC2| |
| +----+ \ / +----+ |
| |L2 Anycast \/ |L2 Anycast
| L2 Anycast / MAC R->pC2 |
| / Mesh S->Anycast |
| (R) |
| ^ |
| | MAC: S -> R |
| | Mesh: S -> Anycast |
| (S) |
| |
| |
\-------------------------------------------/
Figure 5: Mesh Topology
Toutain, et al. Expires January 1, 2011 [Page 8]
Internet-Draft RA Suppression June 2010
3.3. Routed Topology Packet Format
In a route-over network, packets are routed at layer 3. Since the
Layer 2 addresses contained in the frame are generally that of
intermediate nodes, IPHC compression of source or destination address
cannot be as good as in mesh-under. We find similar information in
the routing header to that contained in a mesh header, except it is
stored after the HC field. Figure 5 represents a case where IID is
fully sent after the HC field, but other SAM values such as 00 (with
SAC/DAC equal to 0) and 01 can also be used.
From Sensor Node to LBR:
+-L2-+----------HC--------------------------+---
| | CID=1 SAC=1 SAM=10 | ... 0xFx IID ...| ULP
+----+--------------------------------------+---
Form LBR to Sensor Node:
+-L2-+----------HC--------------------------+---
| | CID=1 DAC=1 DAM=10 | ... 0xxF IID ...| ULP
+----+--------------------------------------+---
Figure 6: Packet Header in Route-Over Topology
The routing toward the LBR is done by the default route installed in
the FIB of Sensor Nodes acting as routers in the WSN. A L2 anycast
address is not necessary to identify the gateway.
4. ULP checksum adaptation
Sensor nodes may use their own layer-4 protocol (ULP: Upper Layer
Protocol) however, regarding 6LoWPAN layer-4 compression values, UDP,
TCP or ICMP are expected. IPv6 mandates the use of an L4 checksum
for these protocols. The L4 checksum covers the data field and also
a pseudo- header including IPv6 source and destination addresses.
The checksum algorithm is based on a sum of all the 16 bits words of
the message. In our scheme, when a sensor node sends a packet to the
outside world, it does not know its own global IPv6 address and
cannot fill the source address field. Therefore, it has to compute
an incomplete L4 checksum, setting the prefix part of the source
address to zero. When receiving such a packet, the LBR can verify
the validity of the checksum and fix its value by adding the prefix
checksum computed using the same algorithm. When receiving a packet
from the outside world, the LBR can also adapt the L4 checksum by
Toutain, et al. Expires January 1, 2011 [Page 9]
Internet-Draft RA Suppression June 2010
subtracting the corresponding value. When a LBR receives an IPv6
packet from the Internet, it may be the case that it does not know if
the Sensor Node supports RA suppression. In this situation, it must
send the packet with the destination address uncompressed. The LBR
may maintain a cache of addresses of Sensor Nodes that have
previously sent packets using context 15. If the destination is in
the cache, the LBR may adapt the checksum and use prefix compression.
5. Conclusion
Although this proposal suppresses the first Neighbor Discovery
exchanges to allow very resource-constrained equipments to
communicate with any IPv6 hosts, the current IPv6 model is not
broken. These optimizations may be applied to some classes of the
sensors which do not require the knowledge of their own global IPv6
address. These optimizations enhance the performance of the network
by limiting the number of packets sent, especially broadcast, and by
reducing the time required for a node to enter the network. These
optimizations are not mandatory and are fully compatible with the
current behavior of the 6LoWPAN network.
6. Acknowledgement
This work is supported by the French Ministry of Foreign Affair
within the Tiny6 project, by NIA (National Information Society
Agency) of Korea with the MoMo project and the by the French National
Research Agency via the ARESA2 project. A special thank to Dominique
Barthel, Ratnajit Bhattacharjee, Claude Chaudet, Guillaume Chelius,
Younghee Lee, Neelesh Srivastava, Bruno Stevant Sarah Tarrapey and
Deepanshu Vasal.
7. Security Considerations
8. Normative References
[I-D.chakrabarti-6lowpan-ipv6-nd]
Chakrabarti, S. and E. Nordmark, "LowPan Neighbor
Discovery Extensions",
draft-chakrabarti-6lowpan-ipv6-nd-05 (work in progress),
July 2008.
[I-D.ietf-6lowpan-hc]
Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-07
Toutain, et al. Expires January 1, 2011 [Page 10]
Internet-Draft RA Suppression June 2010
(work in progress), April 2010.
[I-D.ietf-6lowpan-nd]
Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
Discovery Optimization for Low-power and Lossy Networks",
draft-ietf-6lowpan-nd-09 (work in progress), April 2010.
[I-D.thubert-6lowpan-backbone-router]
Thubert, P., "6LoWPAN Backbone Router",
draft-thubert-6lowpan-backbone-router-01 (work in
progress), July 2008.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
Authors' Addresses
Laurent Toutain
Institut TELECOM ; TELECOM Bretagne
2 rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France
Email: Laurent.Toutain@telecom-bretagne.eu
Nicolas Montavont
Institut TELECOM ; TELECOM Bretagne
2 rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France
Email: Nicolas.Montavont@telecom-bretagne.eu
Toutain, et al. Expires January 1, 2011 [Page 11]
Internet-Draft RA Suppression June 2010
Dominique Barthel
France Telecom R&D
28 Chemin du Vieux Chene
38243 Meylan Cedex
France
Email: dominique.barthel@orange-ftgroup.com
Toutain, et al. Expires January 1, 2011 [Page 12]