Internet DRAFT - draft-chakrabarti-lowpan-ipv6-nd
draft-chakrabarti-lowpan-ipv6-nd
Network Working Group S. Chakrabarti
Internet-Draft E. Nordmark
Expires: January 12, 2006 Sun Microsystems, Inc.
July 11, 2005
LowPan Neighbor Discovery Extensions
draft-chakrabarti-lowpan-ipv6-nd-00
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 January 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
IETF LowPan working group defines IPv6 over low-power personal area
network (IEEE 802.15.4). IEEE 802.15.4 link layer does not have
multicast support, although it supports broadcast. Due to the nature
of LowPan network or sensor networks, broadcast messages should be
minimized. This document suggests some alternative to neighbor
discovery related multicast messages in order to reduce signaling in
the low-cost low-powered network.
Chakrabarti & Nordmark Expires January 12, 2006 [Page 1]
Internet-Draft LowPan Neighbor Discovery Extensions July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Minimizing Multicast or LowPan Broadcast for IPv6 . . . . . . 4
3. Neighbor Unreachability Detection . . . . . . . . . . . . . . 6
4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1 Normative References . . . . . . . . . . . . . . . . . . . 11
8.2 Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 13
Chakrabarti & Nordmark Expires January 12, 2006 [Page 2]
Internet-Draft LowPan Neighbor Discovery Extensions July 2005
1. Introduction
The IPv6-over-IEEE 802.15.4 [2] document has specified IPv6 headers
carrying over IEEE 802.15.4 network with the help of a adaptation
layer which sits between the MAC layer and the network layer. The
LowPan network is characterized by low-powered, low bit-rate, short
ranged, low cost network. Thus, all-node multicast defined in
Neighbor Discovery [1] is not often desirable in the LowPan network.
But IEEE 802.15.4 does not have multicast support, however, it
supports broadcast. Broadcast messages could be used in some cases
to represent all-node multicast messages, but periodic broadcast
messages should be minimized in the LowPan network in order to
conserve energy. The goal of this document is to minimize periodic
multicast signals used by Neighbor Discovery [1], minimize total
number of neighbor discovery related signaling messages without
loosing generality of Neighbor Discovery and autoconfiguration. It
also aims to identify the default values for periodic advertisements,
router and prefix lifetime values that are suitable for LowPan
networks.
The IPv6-over-IEEE 802.15.4 [2] document provides mesh routing
capability at the link layer. Yet each node is configured with IPv6
addresses. Thus a IEEE 802.15.4 may look like one single IPv6 subnet
to the IP layer. It may be possible that routing advertisements are
used only for prefix advertisement purpose for auto-configuration of
IPv6 addresses. Yet, neighbor soliciation, neighbor advertisements,
neighbor unreachability detection take place as usual for neighbor to
neighbor communication. Also, some LowPan networks may use IPv6
routing (for example, star topology). Hence minimizing periodic
router signaling messages are required for efficient use of IPv6 in
the LowPan network.
Please note that this version of draft is not complete in determining
a solution for reducing the Neighbor Discovery signaling messages;
the work is in progress by the authors.
Chakrabarti & Nordmark Expires January 12, 2006 [Page 3]
Internet-Draft LowPan Neighbor Discovery Extensions July 2005
2. Minimizing Multicast or LowPan Broadcast for IPv6
IPv6 neighbor discovery uses solicited node multicast for duplicate
address detection, all-node multicast for unsolicited router
advertisement, all-router multicast for the router solicitation
messages. An IPv6 node is supposed to join all-node multicast group
when the IPv6 interface is configured up.
A LowPan network does not have multicast capability in the layer 2.
However, the link-layer provides broadcast functionality, supporting
IPv6 for broadcast would defeat its purpose. Also the Neighbor
Discovery document [1] is designed for regular Internet Network where
nodes are sufficiently powered and they are configured in a stable
infrastructure of network, unlike LowPan or sensor networks. The
strawman idea for this section is to attempt to minimize the
multicast Neighbor Discovery signaling packets.
If a lowpan node wishes to send Router Solicitation, it should only
send the request to the nodes in the local PAN for mesh topology.
For star topology, it is likely that the co-ordinator node acts as a
IPv6 router if the LowPan network chooses to use L3 routing in this
toplogical configuration. In mesh topology all or some nodes have
routing or forwarding capabilities.
Similarly, the router advertisements should be sent only to the local
L2 broadcast address or broadcast PAN ID (0xffff). The default and
minimum interval for unsolicited Routing advertisements should change
to higher value so that the Lowpan nodes do not need to spend a lot
of cycles receiving and processing the signaling messages.
Duplicate address detection is sent to the solicited node multicast
address which is derived from lower 24bits of the target IPv6
address. Should nodes in LowPan network use duplicate address
detection ? Avoiding duplicate address detection will save broadcast
signalling in the PAN-since 802.15.4 does not have multicast
capabilities yet. Besides, each duplicate address detection message
is capable of waking up sleeping reduced function devices in the
network and making the devices less and less energy efficient.
Similarly, sending neighbor soliciation messages for resolving a
link-local address for a IPv6 address is also a waste of bandwidth
and energy in the LowPan network. Thus the following proposal
attempts to distribute the link-layer information of nodes to the PAN
co-ordinator which has higher possibility of being a full-functional
device. Even if the co-ordinator lives a couple of L2 hops away from
the enquiring node (assuming mesh routing at the L2 layer), each
neighbor solicitation in this proposal will involve only a few nodes
in the path of traversal of the packet. This is an unicast
Chakrabarti & Nordmark Expires January 12, 2006 [Page 4]
Internet-Draft LowPan Neighbor Discovery Extensions July 2005
solicitation for resolving address.
The strawman proposal is that the prefix advertising router would set
a flag, so that all hosts should at least send a packet through the
router once for on-link destination nodes. The router sends route-
redirect to the sender for direct-host to host path. But the PAN
router(s) then keep information on all neighboring nodes L2
addresses. A lowpan node. thus sends a neighbor solicitation message
to its router or co-ordinator for resolving the L2-address of the
neighbor. In most cases, the co-ordinator or prefix advertiser would
have an neighbor cache entry for the specified IPv6 target address.
More thoughts are needed to specify the protocol behavior when router
cache entry becomes stale or when a lowpan node moves away from the
PAN. What if the router itself looses power? Should there be
multiple routers/co-ordinators who keep the neighbor information in
distributed fashion - so that absence or failure of one router will
not affect the neighbor solicitation negatively?
Chakrabarti & Nordmark Expires January 12, 2006 [Page 5]
Internet-Draft LowPan Neighbor Discovery Extensions July 2005
3. Neighbor Unreachability Detection
Using the same essence as above, the IPv6 routers in the LowPan
network can reduce Neighbor Unreachability Detection messages. The
lowpan nodes may register their L2 and corresponding IPv6 addresses
to the designated router/co-ordinators periodically (when they are
awake and transmitting) . This will remove the need of frequent
neighbor solicitation by the routers to the hosts and vice-versa.
The host-to-host NUD frequency should be also reduced and
synchronized with the lowpan node's wake-up or radio transmission
time only.
Chakrabarti & Nordmark Expires January 12, 2006 [Page 6]
Internet-Draft LowPan Neighbor Discovery Extensions July 2005
4. Open Issues
o For LowPan nodes, should we say that all NS messages must contain
the source link-layer option to avoid triggering a followup
neighbor solicitation in reverse direction?
o What is the best way to keep the neighbor cache information
distributed among different routers/co-ordinators for fault-
tolerance?
o Should a node de-register itself from router/co-ordinator's
neighbor cache if it decides to move away?
o What is the default lifetime and interval values for routers and
prefixes?
o Issues mentioned at the end of section 2 and 3.
Chakrabarti & Nordmark Expires January 12, 2006 [Page 7]
Internet-Draft LowPan Neighbor Discovery Extensions July 2005
5. Security Considerations
TBD.
Chakrabarti & Nordmark Expires January 12, 2006 [Page 8]
Internet-Draft LowPan Neighbor Discovery Extensions July 2005
6. IANA Considerations
TBD.
Chakrabarti & Nordmark Expires January 12, 2006 [Page 9]
Internet-Draft LowPan Neighbor Discovery Extensions July 2005
7. Acknowledgements
TBD
Chakrabarti & Nordmark Expires January 12, 2006 [Page 10]
Internet-Draft LowPan Neighbor Discovery Extensions July 2005
8. References
8.1 Normative References
[1] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor
Discovery for IP version 6", draft-ietf-ipv6-2461bis-03.txt
(work in progress), May 2005.
[2] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6 Packets
over IEEE 802.15.4 networks",
draft-montenegro-lowpan-ipv6-over-802.15.4-02.txt (work in
progress), February 2005.
[3] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview,
Assumptions, Problem Statement and Goals",
draft-kushalnagar-lowpan-goals-assumptions-00.txt (work in
progress), February 2005.
8.2 Informative References
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6),
Specification", RFC 2460, December 1998.
[5] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[6] IEEE Computer Society, "IEEE Std. 802.15.4-2003", ,
October 2003.
Authors' Addresses
Samita Chakrabarti
Sun Microsystems, Inc.
16 Network Circle
Menlo Park, CA 95024
USA
Email: Samita.Chakrabarti@Sun.COM
Chakrabarti & Nordmark Expires January 12, 2006 [Page 11]
Internet-Draft LowPan Neighbor Discovery Extensions July 2005
Erik Nordmark
Sun Microsystems, Inc.
17 Network Circle
Menlo Park, CA 95024
USA
Email: Erik.Nordmark@Sun.COM
Chakrabarti & Nordmark Expires January 12, 2006 [Page 12]
Internet-Draft LowPan Neighbor Discovery Extensions July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Chakrabarti & Nordmark Expires January 12, 2006 [Page 13]
