One document matched: draft-toutain-6lowpan-ra-suppression-00.txt
Network Working Group L. Toutain
Internet-Draft Institut TELECOM ; TELECOM
Intended status: Informational Bretagne
Expires: February 21, 2009 G. Chelius
INRIA
Y. Lee
ICU
Y. DONG
Southeast University
August 20, 2008
Neighbor Discovery Suppression
draft-toutain-6lowpan-ra-suppression-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 21, 2009.
Abstract
The 6LoWPAN IETF working group is developing protocols to allow IPv6
end-to-end communication with sensors networks. Low-power MAC
protocols such as IEEE 802.15.4 impose a slightly reduced frame size.
To enable IPv6 communication, 6LoWPAN proposes to use fragmentation
and header compression techniques. This document proposes an
extension to the 6LoWPAN proposal and defines a class of sensors that
Toutain, et al. Expires February 21, 2009 [Page 1]
Internet-Draft Point6box August 2008
can be joined at the network level while ignoring their own global
IPv6 address. This architecture centralizes the address management
on the sensor network gateway (the PAN Coordinator) and allows the
suppression of the Neighbor Discovery Protocol. Consequently, the
insertion of sensors in such a network is faster and the traffic
within the network, largely composed of broadcast messages generated
by Neighbor Discovery Protocol, is reduced. We investigate the
impact of this architecture on star and mesh topologies.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Suppression of sollicited RA . . . . . . . . . . . . . . . . . 4
2.1. Stateless 6LoWPAN header compression . . . . . . . . . . . 4
2.2. Impact of anycast address for default router . . . . . . . 6
3. ULP checksum adaptation . . . . . . . . . . . . . . . . . . . 8
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Toutain, et al. Expires February 21, 2009 [Page 2]
Internet-Draft Point6box August 2008
1. Introduction
6LoWPAN [RFC4944] is an adaptation layer used to transport IPv6
packets in Wireless Sensor Networks (WSN) using a layer-2 technology
imposing a reduced frame size, such as IEEE 802.15.4. In order to
improve energy efficiency, IEEE 802.15.4 limits the maximum frame
size to 127 bits, which results in an incompatibility with IPv6
specifications. 6LoWPAN solves this issue for large data packets by
implementing a fragmentation header. For small packets, for instance
Neighbor Discovery Protocol (NDP) messages, 6LoWPAN introduces a
simple header compression scheme, which allows NDP messages to fit
into a single frame. 6LoWPAN supports different kinds of topology
from the simple star topology to more complex architectures based on
layer 2 mesh network or on layer 3 routing. In all topologies, a PAN
Coordinator (PC), refered also in this document as the gateway, is in
charge of network management. This equipment is located at the
boundary between the WSN and the "traditional" Internet and acts also
as a router.
If some solutions have been proposed to optimize the encapsulation of
NDP messages, the load imposed by this protocol is similar in WSN and
in Ethernet-based networks. Some proposals suggest limiting the use
of broadcast, which may be energy consuming on WSN, by maintaining
stateful information on the PAN Coordinator.
[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
on the PC instead of being distributed in the network. Duplicate
Address Detection (DAD) and Neighbor Solicitation (NS) are performed
using point-to-point requests from the sensors to the PC rather than
multicast packets spanning over the whole WSN. Furthermore, nodes
intercept initial multicast Router Solicitation (RS) messages and
forward them directly to the PC instead of broadcasting it to the
whole network.
[I-D.thubert-6lowpan-backbone-router] extends this proposal by
allowing multiple routers in a WSN which share the same prefix.
Backbone routers only have a partial view of the addresses allocated
on the link. 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 nearest
router.
Our proposal to further optimize NDP on WSN focuses on the bootstrap
phase of NDP. Our goal is to avoid the announcement of the IPv6
prefix to some sensors that do not need to know their global IPv6
address while still guaranteeing end-to-end communications between
any equipment on the Internet and these sensors. Indeed, several
Toutain, et al. Expires February 21, 2009 [Page 3]
Internet-Draft Point6box August 2008
sensors do not require the knowledge of the network prefix, as long
as gateways are able to add and remove this information. For
instance:
o a mobile sensor reporting periodically a value 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 is based on the 6LoWPAN header compression scheme that
suppresses the network prefix in compressed IPv6 headers. This
scheme is, in a sense, quite similar to the deployment of private
addresses in an IPv4 network using Network Address Translation (NAT).
The private IPv4 address is analogous to our Interface Identifier
(IID) and the public IPv4 address to the prefix. However, there are
fundamental differences between our proposal and address translation:
o this mechanism can be deactivated when a sensor needs to know its
public IPv6 address. A Router Solicitation (RS) message can be
sent in the sensors network, using the optimization mentioned
above, to get an explicit answer from the gateway.
o this mechanism does not break the end-to-end connectivity, since
no additional memory is required on the gateway that stores the
network prefix rather than an address matching table.
2. Suppression of sollicited RA
A solicited RA message carries information regarding a node insertion
on the link. Suppressing the initial RS/RA exchange requires some
changes in nodes' behavior:
o sensor nodes do not learn the prefix by default. With 6LoWPAN
header compression, the source address prefix usage can be avoided
on the link.
o sensor nodes are not explicitly aware of the default router's
address. We propose to use a predefined anycast address to
identify default routers in a WSN.
2.1. Stateless 6LoWPAN header compression
6LoWPAN defines in [RFC4944] a header compression scheme that divides
the IPv6 address into two distinct parts. The first 64 bits
designate the prefix and the last 64 bits contain the IID. A bitmap
in the IPv6 header allows toggling of implicit and explicit reference
of the prefix in both the source and destination addresses. 6LoWPAN
assumes that a compressed prefix refers to the link-local context.
Hui [I-D.hui-6lowpan-hc1g] proposed a new header compression
discriminator for global addresses, called HC1g. This discriminator
Toutain, et al. Expires February 21, 2009 [Page 4]
Internet-Draft Point6box August 2008
works in the same way as the standardized 6LoWPAN HC1, but instead of
adding the link-local prefix, the global prefix of the link is added
when the full IPv6 packet has to be built.
In our proposal, a new discriminator is not necessary; the 6LoWPAN
compression mechanism does not have to be changed. Only the PC
behavior has to be slightly modified. By examining the type of the
destination address (local or global) and the value of the prefix
(same as the WSN's or different) to define which source address
prefix must be used. When a sensor communicates towards the outside
world, the destination prefix cannot be compressed, since the prefix
can be any IPv6 prefix and no restriction is made on the IID value.
In the PC, a simple algorithm could be used to discriminate which
prefix must be added by the PC when reconstructing the IPv6 header:
o if the destination prefix is compressed or equal to FE80::/64 then
the source prefix is FE80::/64
o in any other case, especially when the packet is directed outside
of the WSN, the source prefix is the one allocated to the WSN and
is known by the PC, since it also acts as a router.
In the reverse direction, when the PC receives a packet from outside
the WSN, it checks the destination prefix to see if it matches the
WSN's and suppresses it when compressing the IPv6 header.
Outgoing packets
Sensor -------------------> PC ---------->
IEEE 802.15.4 L2
1 6LoWPAN Dispatch 40 IPv6
(Mesh Header) Source:WSN pref + L2 src addr
1 HC1 : 1100 xxxx Dest:Global address
16 Global Addr.
1 HL
Incoming packets
Sensor <------------------- PC <----------
byte IEEE 802.15.4 byte L2
1 6LoWPAN Dispatch 40 IPv6
(Mesh Header) Source:Global address
1 HC1 : 1100 xxxx Dest:WSN pref + L2 src addr
16 Global Addr.
1 HL
Figure 1: Address compression with RFC 4944
The PANid must reflect the value of prefix allocated to the link.
This can be done manually, when the PC is configured, or
automatically, based on the prefix value (not described here). In
Toutain, et al. Expires February 21, 2009 [Page 5]
Internet-Draft Point6box August 2008
case of multiple attachments as depicted on Figure 1, a single small
change to the IEEE 802.15.4 standard is necessary.
The IEEE 802.15.4 standard stipulates that in case of a conflict
between two PCs on the PANid value, one of them has to change its
PANid value. In our case, since the PANid value is dependent on the
prefix value, the PANid value cannot be changed. So in that case,
only one PC must remain active, the others may become backup PC but
continue to act as a gateway.
2.2. Impact of anycast address for default router
The RA also carries the L2 address of the default router. If no RA
is sent, the sensor ignores the physical address where packets have
to be sent. To solve this issue, sensors may be configured with a
predefined L2 anycast address that can be overloaded if a RA is
received.
Figure 2 represents a star topology with a sensor node located in an
area reachable by two PCs. No mesh header is assumed in this
configuration. The use of an anycast address could lead to sending
duplicate packets on the Internet bearing two different source
addresses, starting with the prefix associated to each PC and the
same interface ID. The use of PANid prevents this situation since
each star topology has a different PANid (a different prefix is
assigned to each PC). The sensors have to select one of the PANids
to send a frame and only one PC will consider the frame.
---------+-----------+-------
| |
+--+--+ +--+--+
| PC | _| PC |
,'| |`.,' | |.
` +-----+ `` +-----+ `
/ / \ \
| | | |
| |(S) | |
| | | |
\ \ / /
. PANid1 \/ PANid2 /
',pref1 ,'',pref2 ,
`''-''` `''-''`
Figure 2: Star Topology
Toutain, et al. Expires February 21, 2009 [Page 6]
Internet-Draft Point6box August 2008
Figure 3 represents a mesh topology; a routing protocol is necessary
at layer 2 to establish the mesh. A layer-2 anycast address is
similar to a layer-3 anycast address and can be considered as if it
identified a virtual equipment behind the true gateway. Both
gateways inject a route for this address. Sensor Nodes are
configured with this default L2 address in their routing table and
forward all the packets towards that address. Gateways intercept
packets destined to this address by examining in the mesh header. A
layer-2 anycast address is used in the mesh header only when a sensor
node sends a packet and only as the destination address. The next
hop is obtained from the mesh routing table. In Figure 3 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
gateway will receive the packet even if they share the same PANid.
Normally, anycast addresses should not be used as source addresses.
Therefore, when a gateway forwards a packet to a sensor node, it
includes its 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 gateway, making reassembly impossible. However,
such situation is expected to be very uncommon and the sensors may
use the gateway 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 gateway fails, the routing protocol
automatically forwards the frame to another active one.
Toutain, et al. Expires February 21, 2009 [Page 7]
Internet-Draft Point6box August 2008
-------+----------------------------+--------------
| |
+-+--+ +--+-+
/---| |----------------------| |------\
| | PC1|X------\ /-------->| PC2| |
| +----+ \ / +----+ |
| |L2 Anycast \/ |L2 Anycast
| L2 Anycast / MAC R->pC2 |
| / Mesh S->Anycast |
| (R) |
| ^ |
| | MAC: S -> R |
| | Mesh: S -> Anycast |
| (S) |
| |
| |
\-------------------------------------------/
Figure 3: Mesh Topology
3. ULP checksum adaptation
Sensors 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. L4 checksum includes data and also on 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 sends a packet to the
outside world, it does not know its global IPv6 address to 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 border gateway can verify the
validity of the checksum and adapt the value by adding the sum
corresponding to the prefix using the same algorithm. When receiving
a packet from the outside world, the border gateway can also adapt
the L4 checksum by subtracting the corresponding value.
4. Conclusion
Despite this proposal suppress first Neighbor Discovery exchanges, to
allow very simple equipment 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
Toutain, et al. Expires February 21, 2009 [Page 8]
Internet-Draft Point6box August 2008
their own global IPv6 address. These optimizations enhance the
performance of the network by limiting the number of packet sent,
especially broadcast, and by reducing the time required before a node
enters the network. These optimizations are not mandatory and are
fully compatible with the current behavior of the 6LoWPAN network.
5. Acknowledgement
This work is supported by the French Ministry of Foreign Affair
within the Tiny6 project and by NIA (National Information Society
Agency) of Korea with the MoMo project. A special thank to Ratnajit
Bhattacharjee, Claude Chaudet, Younghee Lee, Neelesh Srivastava,
Bruno Stevant and Deepanshu Vasal.
6. Security Considerations
7. 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.hui-6lowpan-hc1g]
Hui, J. and D. Cullerot, "Stateless IPv6 Header
Compression for Globally Routable Packets in 6LoWPAN
Subnetworks", draft-hui-6lowpan-hc1g-00 (work in
progress), July 2007.
[I-D.thubert-6lowpan-backbone-router]
Thubert, P., "6LoWPAN Backbone Router",
draft-thubert-6lowpan-backbone-router-01 (work in
progress), July 2008.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
Toutain, et al. Expires February 21, 2009 [Page 9]
Internet-Draft Point6box August 2008
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
Guillaume Chelius
INRIA
21, avenue Jean Capelle
69621 Villeurbanne
France
Email: Guillaume.Chelius@inria.fr
Yoongsoo Lee
ICU
119, MunjiRo, YusongGu,
Daejon, 305-732
Korea
Email: jslee@icu.ac.kr
Yongqiang DONG
Southeast University
Sipailou 2#
Nanjing 210096
China
Email: dongyq@seu.edu.cn
Toutain, et al. Expires February 21, 2009 [Page 10]
Internet-Draft Point6box August 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Toutain, et al. Expires February 21, 2009 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 09:57:05 |