Internet DRAFT - draft-culler-6lowpan-architecture
draft-culler-6lowpan-architecture
6lowpan D. Culler
Internet-Draft Arch Rock
Intended status: Informational G. Mulligan
Expires: May 15, 2008 Proto6
JP. Vasseur
Cisco
November 12, 2007
Architecture for IPv6 Communication over IEEE 802.15.4 subnetworks using
6LoWPAN
draft-culler-6lowpan-architecture-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 May 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes the architecture incorporating IEEE 802.15.4
subnetworks utilizing the 6LoWPAN adaptation layer into the family of
Internet standards.
Culler, et al. Expires May 15, 2008 [Page 1]
Internet-Draft 6LoWPan Architecture November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terms used . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. PAN Organization . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Complete broadcast domain . . . . . . . . . . . . . . . . 6
5.2. Mesh Under . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Route Over . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. Routed Mesh . . . . . . . . . . . . . . . . . . . . . . . 9
6. IEEE 802.15.4 Architectural Issues . . . . . . . . . . . . . . 10
7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Stateless Auto-configuration . . . . . . . . . . . . . . . 12
7.2. Link Local Well Known Multicast Addresses . . . . . . . . 13
7.3. Short Addresses . . . . . . . . . . . . . . . . . . . . . 13
7.4. Link Local Multicast . . . . . . . . . . . . . . . . . . . 14
7.5. Scopes . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.6. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Normative references . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Culler, et al. Expires May 15, 2008 [Page 2]
Internet-Draft 6LoWPan Architecture November 2007
1. Introduction
The IEEE 802.15.4 standard [ieee802.15.4] specifies a wireless link
for low power personal area networks (WPAN). This link is widely
used in applications involving large numbers of embedded devices,
such as instrumentation, monitoring, automated metering, home and
building automation, security, machine monitoring, and open-loop
control. It is also utilized in human-centered applications,
including health monitoring, device interconnection, active badges,
fitness, and entertainment. It differs from wireless local area
networks (WLAN) in several regards: small MTU size (127 bytes), low
bandwidth (250 kbps in the 2.4 GHz band, less in the lower ISM
bands), short (16 bit) link addresses, in addition to the 64-bit
EUID, low radio transmit power (i.e., short range) and built-in AES-
128 encryption and authentication. These elements are present in
order to enable low cost implementations with reasonable packet loss
rates and long-lived operation on modest power sources, especially
battery powered devices. However, they present challenges for
utilizing the link to carry IP packets. At the same time, the short
range of IEEE 802.15.4 wireless links and the common embedding of
nodes in a specific physical environment and interconnected via IEEE
802.15.4 link leads to networks where many nodes share a great deal
of context. For example, often they form, collectively, a single
monitoring application under a common administrative domain. In
addition to being part of a common network infrastructure, with the
associated address assignments, management, etc., they may be parts
of a common physical infrastructure, such as a building HVAC or
lighting facility. This shared context is leveraged to overcome the
challenges of efficiently supporting IP on constrained devices.
RFC4944 [2] defines how IPv6 [3] communication is carried efficiently
in 802.15.4 frames and specifies key elements of an adaptation layer.
6LoWPAN has three primary elements:
o Header Compression: RFC4944 [2] provides extensive compression of
IPv6 headers by eliding fields that can be derived from the link-
level information carried in the IEEE 802.15.4 frame based on
simple assumptions of shared context. IPv6 link-local and
statelessly auto-configured addresses can be elided for intra-PAN
communication, since they can be derived from either the short (2
octet) or long (8 octet) link level source and destination
addresses. Global addresses that utilize a PAN-wide prefix could
similarly be compressed. UDP transport headers are compressed for
a limited set of ports.
o Fragmentation: Because IPv6 mandates that the link layer be
capable of supporting minimum MTU of 1280 bytes, RFC4944 [2]
provides fragmentation of IPv6 packets into multiple link-level
frames to accommodate the minimum MTU requirement of IPv6.
Culler, et al. Expires May 15, 2008 [Page 3]
Internet-Draft 6LoWPan Architecture November 2007
o Intra-PAN forwarding: 6LoWPAN accommodates subnetworks of physical
extent that exceeds the radio range or for other reasons do not
form a single broadcast domain. Often the physical deployment of
a LoWPAN network comprises a number of nodes at points of interest
in a physical space (e.g., thermal or air quality monitor points
throughout a building) or attached to particular objects of
interest (e.g., motor bearings, electric meters, or flow gauges).
Such points do not necessarily form a fully connected broadcast
domain at the link level, but do form a contiguous mesh of such
links. To support a network organization in which such a mesh of
devices, interconnected by means of IEEE 802.15.4 links, appears
as a single IP link, the adaptation layer can carry link-level
addresses for the ends of an IP hop, in addition to the link-level
source and destination fields in the 802.15.4 frame used for each
link hop that forms the Layer 2 path. Alternatively, following
the IPv6 generalizations of the subnet concept, such a mesh can
also be viewed as a multicast domain with a common prefix, in
which case intra-pan routing may be accomplished by multiple IP
hops, each of which may potentially be one or more Layer 2 hops.
RFC4944 [2] defines how these capabilities are represented in terms
of the IEEE 802.15.4 frame format. However, the implementation of
those capabilities is out of the scope of that document. The
dependences of adaptation layer on the specific operations defined in
the IEEE 802.15.4 MAC protocol are minimal. It could potentially be
implemented on essentially any MAC protocol that provided the IEEE
802.15.4 frame format. Similarly, the format does not specify how
IPv6 capabilities, such as neighbor discovery, are orchestrated in
order to configure the PAN to be consistent with the 6LoWPAN
adaptation layer. This document provides such an operational
framework. It outlines the key components of an IPv6 6LoWPAN network
and how those components are composed.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [1].
3. Terms used
PAN: Personal Area Network. A collection of contiguously connected
IEEE 802.15.4 devices sharing a common PAN-ID and compatible MAC
protocol such that any constituent device can potentially
communicate with any other through a series of consecutive packet
exchanges.
Culler, et al. Expires May 15, 2008 [Page 4]
Internet-Draft 6LoWPan Architecture November 2007
FFD: Full Function Device. IEEE 802.15.4 term identifying a class
of device that can forward link-level packets. It also has
specific role in 802.15.4 protocols that utilize superframes
comprising guaranteed time slots and collision slots, including
the regular transmission of beacon packets that define the
temporal structure and allocation of the superframe.
RFD: Reduced Function Device. IEEE 802.15.4 term identifying a
class of device that cannot forward packets and can only
communicate with FFDs. It has specific responsibilities in
802.15.4 protocols that utilize superframes, including powering
its radio in receive mode to receive beacons and transmitting only
in allocated slots.
PAN-ID: IEEE 802.15.4 term defining a 8-bit field that partitions
potential communication. Communication between two 802.15.4
device can occur only if they utilize a common PAN-ID.
MTU: Maximum Transmission Unit
MAC: Media Access Control
CSMA/CA: Carrier Sense Multiple Access / Collision Avoidance
ISM: The industrial, scientific and medical (ISM) radio bands were
originally reserved for industrial, scientific and medical
purposes other than communications.
Mesh Under:
Route Over:
4. Background
IEEE 802.15.4 2003 radios units are typically connected to or
integrated in microcontroller devices, which have limited memory
capacity and processing bandwidth, although they may be connected to
more capable microprocessors. The IEEE specification defines sixteen
(16) communication channels in the 2.4 GHz band at a bandwidth of 250
kbps and 10 channels in 915 MHz band at 40 kpbs and one channel in
the 868 MHz band. (IEEE802.15.4-2006 increases the bandwidth of sub
1GHz bands by optionally allowing alternative modulation mechanisms.)
The frame consists of a preamble plus a length octet, frame header,
payload and check code. The maximum packet length from the length
octet to check code is 128 octets, inclusive. The MTU is limited to
ensure that reasonable packet receive rates (PRR) can be obtained on
cost-effective implementations that have non-negligible bit-error
rates (BER). It also reflects the limited memory for buffering and
routing structures that are expected to be present on microcontroller
class devices. 6LoWPAN specifically addresses the small MTU and
avoids placing any potentially heavy memory requirements on the
nodes.
IEEE 802.15.4 provides a rich set of mechanisms for various aspects
of media arbitration, packet forwarding, addressing, and power
Culler, et al. Expires May 15, 2008 [Page 5]
Internet-Draft 6LoWPan Architecture November 2007
management. Mechanisms are defined for both CSMA and TDMA media
access protocols, as well as hybrids that utilize a superframe
structure. These are intended to mediate potential collisions due to
multiple overlapping transmissions in a localized geographic area.
However, low-power operation requires additional mechanisms to place
the radio into sleep or idle modes when no receptions are to occur.
Many such schemes can be supported by the MAC, including beacon-based
coordination among FFDs and RFDs. In practice, most PANs utilize
simpler mechanisms that provide media arbitration and power
management but do not use the specific capabilities of FFDs or the
superframe structure defined in the IEEE 802.15.4 specification
[IEEE802.15.4]. Many utilize a backbone of line powered forwarding
devices (FFDs) supporting leaf nodes (RFDs) that turn off their
radios much of the time. Others utilize centralized or localized
formation of communication schedules, orchestrated using standard
data frames, to duty-cycle low power forwarding nodes. Still others
utilize transmission of wakeup packets in advance of payload
exchanges and sampled listening to detect an impending transmission.
Some MAC protocols use a single channel throughout the PAN, while
others alternate among multiple channels for greater frequency
diversity than is provided by the DSSS coding. Some utilize the link
level acknowledgment support specified by IEEE 802.15.4, others
disable acknowledgments, while others generate customized
acknowledgments as data frames.
RFC 4944 [2] defines how IPv6 communication is carried in IEEE
802.15.4 frames and assumes mutually compatible link protocols to
transport those frames. However, it does not stipulate which such
link protocol is utilized. It is potentially usable across a wide
range of such protocols. Obviously, interoperability is limited by
the compatibility of the underlying link protocols, even when
identical frame formats are utilized.
5. PAN Organization
A spectrum of topologies are in existence for the PAN, ranging from a
conventional link that comprises a single complete broadcast domain
to ones that require multihop communication within the PAN. Here we
outline the range of topologies to establish a basis for how the
broader aspects of the IP architecture are supported within the
6LoWPAN setting.
5.1. Complete broadcast domain
The simplest organizational of a LoWPAN is one that forms a single
complete broadcast domain. This case is particularly useful for
establishing how IPv6 concepts are represented in a 802.15.4 setting,
Culler, et al. Expires May 15, 2008 [Page 6]
Internet-Draft 6LoWPan Architecture November 2007
while the PAN behaves most like a conventional IP link. The link
local scope is identical to the Layer 2 PAN.
To function as a single broadcast domain all the hosts in the PAN
must be in sufficiently close physical proximity that each is in
range of the others, and they share a common IEEE 802.15.4 PAN ID.
Furthermore, the underlying data link layer must utilize IEEE
802.15.4 channels so that a transmission by any one may be received
by all others, the power management protocol must allows such
reception to occur, and the MAC protocol must be compatible. Such is
the case, for example, if all the hosts are on a single channel,
continuously powered, and utilizing a simple CSMA MAC. Note that a
large physical extent is not the only factor that undermines the
single broadcast domain behavior, other aspects of the link
management protocol may as well.
6LoWPAN does not dictate a particular link management protocol.
Regardless of the link management protocol, it defines how the link
frame format is used to carry compressed and conventional IPv6
packets.
5.2. Mesh Under
Where the LoWPAN forms only a partial broadcast domain, some measures
must be taken to allow it to function as an IP link. A Mesh Under
organization seeks to mask the lack of full broadcast by
transparently forwarding packets within the PAN. The most common
case is where the physical extent is such that not all nodes are
within radio range of all others. Assuming compatible link
protocols, a transmission by a node is received by the subset of
nodes that are in physical proximity. Power management or frequency
hopping strategies may further restrict this link level single hop
neighborhood. Nodes that are in very close physical proximity may
fail to receive a transmission if their radio is not powered on when
the transmission occurs of if a different channel is selected at that
time. For communication directed to a particular link address,
either EUID64 or SA16, a neighboring node must retransmit the packet
to move it closer to the destination. As multiple layer 2 hops are
required to accomplish a single IP hop, this organization is termed
Mesh Under.
If the destination is the link broadcast address, neighboring nodes
must retransmit the packet until it is disseminated to all nodes in
the PAN. Such PAN-wide broadcasts are logically a flood, although
sophisticated retransmission scheduling or selective retransmission
may be used to implement it effectively. As such, each node will
typically receive multiple packets for the same logical broadcast and
must suppress repeated retransmissions for the flood to terminate.
Culler, et al. Expires May 15, 2008 [Page 7]
Internet-Draft 6LoWPan Architecture November 2007
6LoWPAN introduces the concept of Originator and Final Address to
describe the source and destination nodes of a single IP hop within
the PAN. These addresses are carried in the mesh subheader. If the
IP hop is accomplished by a single link layer transmission, the link
source address is the same as Originator Address and the link
destination address is the same as Final Address. Where multiple
link hops are required, Originator Address is the link source address
of the first and Final Address is the link destination address of the
last. The 802.15.4 frame carries the link hop Source and Destination
addresses.
Logically, an IP hop in 6LoWPAN always traverses from the link
Originator address to the link Final address, and in the case that
this is accomplished in a single link layer transmission the
Originator is identical to the Source and the Final is identical to
the Destination, thus the mesh header is elided.
To support dissemination to all nodes in the PAN, the LOWPAN_BC0
subheader carries a sequence number which facilitates duplicate
detection and termination of the flood. RFC4944 defines the field in
the frame used for detecting the duplicates that are potentially
received as a result of multiple predecessors in the flood, multiple
siblings, or multiple decendents. However, it does not define the
particular retransmission policy, scheduling, or suppression.
Where the LoWPAN is a stub network, and not a transit network, in a
Mesh Under organization, IP routing is not required within the
LoWPAN. It behaves likes a conventional subnet with all nodes
appearing to be a single IP hope from the entry or exit device(s).
Routing is involved in entering or exiting the PAN through devices
with multiple interfaces.
The 6LoWPAN mesh header assumes that carrying the Originator and
Final link addresses is sufficient to determine the forwarding action
at each layer two hop. In can be assumed that mesh tables are
configured and maintained much like routing tables, but all actions
are carried out using link layer packet exchanges.
The protocols to enable mesh under forwarding are not defined in
6LoWPAN, but are implementable within 6LoWPAN and several have been
proposed [Dymo, Load, DymoLo, Tymo]. It is expected that many of the
capabilities utilized for IP routing, such as topology determination,
probing, echo, neighbor discovery, unreachability detection, route
repair, and path optimization will need to be established and
standardized for use within the 6LoWPAN link for independently
implemented interoperable Mesh Under forwarding to be demonstrated.
Culler, et al. Expires May 15, 2008 [Page 8]
Internet-Draft 6LoWPan Architecture November 2007
5.3. Route Over
Alternatively, a LoWPAN may be organized in a manner that allows
multiple broadcast domains in the logical IP subnet. The simplest
case is the extreme point where each individual node defines a
broadcast domain and thereby an IP link. In this case, no link layer
measures are taken to mask the partial broadcast nature of the LoPAN.
Instead the LoWPAN forms a collection of overlapping link local
scopes, each of which are 1-1 with a link layer broadcast domain.
Each link layer hop is an IP hop. IP routing supports the forwarding
of packets between such links.
Such forwarding utilizes IP routing tables and IPv6 hop-by-hop
options. This organization relies heavily on the IPv6 generalization
of subnet to multicast group(s). Typically, the PAN will be
contained in one or more common prefix and will behave as a subnet.
The same series of retransmissions from the same physical nodes are
required to communicate information from a given source to a given
set of destinations. The distinction lies in how those forwarding
actions are determined and how routing is established. In Mesh
Under, inter-PAN routing and forwarding is performed at the link
layer using information in the 802.15.4 frame or the 6LoWPAN header.
In Route Over, it is performed at the IP layer using the additional,
encapsulated IP header. The 6LoWPAN adaptation layer establishes a
direct mapping between the frame header and the IP header, so Router
Over can utilize the link Source and Destination addresses as a
compact form of the IP address, but also has access to routing
options, ICMP actions, and so on, which are logically at the next
layer.
IP routing within the LoWPAN may be used to cross link-defined
broadcast domains, such as distinct PAN-IDs or incompatible channel
allocation, channel scheduling, or MAC protocols. The router node
has an interface in each domain, even though they utilize the same
physical medium, the stacks are distinct.
Although 6LoWPAN only deals with the transmission of IPv6 packets
over IEEE 802.15.4. links, IP routing can be used to interconnect
devices by means of a variety of Layer 1/2 protocols.
5.4. Routed Mesh
In general, Mesh Under and Route Over can be combined in a hybrid
organization. IP routing occurs between meshed links, such as in
single hop broadcast domains whereas the mesh under function is
responsible for relaying packets within portions of the LoPAN
emulating the IP link as a single broadcast domain. Note that such a
Culler, et al. Expires May 15, 2008 [Page 9]
Internet-Draft 6LoWPan Architecture November 2007
hybrid approach involving packet routing and forwarding at layer 2
and layer 3 is likely to lead to routing inconsistency because, the
layer 2 path selection process is opaque to the layer 3 routing
component, thus not allowing for optimal end to end path selection,
and layer 2 is oblivious to routing associated with ingress and
egress to the LoPAN. At the same time, Layer 3 routing within the
LoPAN is likely to need to be more cognizant of link layer phenomena,
such as transient link fading due to environmental factors that are
independent of contention, than is typical.
Multi-layer recovery presents additional concerns because a network
element failure may be handled at multiple layers. In some cases the
layer 2 path may be recomputed by the Mesh Under component whereas in
other cases such path recovery may only be performed by the Router
Over component. In situations where fast recovery is needed (e.g.
Industrial process application such "Safety: Class 0: Emergency
action") the adoption of a multi-layer recovery technique is very
challenging. Indeed, the most common approach consisting of adopting
a timer-based approach is cumbersome and implies unnecessary delays
when the failure cannot be restored by the upper layer.
6. IEEE 802.15.4 Architectural Issues
IEEE 802.15.4 links present a number of pragmatic issues that have
significant architectural impact, beyond the small MTU, dual
addressing, and short communication range addressed directly in the
6LoWPAN format. Some of these were touched on briefly in the
discussion above.
Collections of nodes that communicate must share a common 16-bit
PAN_ID. Packets arriving at a node that do not match the PAN_ID are
discarded. The logical links associated with distinct PAN_ID are not
entirely isolated as they all participate in broadcast PAN ID.
Generally, nodes with distinct PAN_IDs will not be in a common
broadcast domain at the link level, regardless of physical proximity.
The 6LoWPAN format does not explicitly define a position on the use
of PAN_ID; it is expected that a single 6LoWPAN IP link will share a
common PAN_ID. If this were not the case, retransmissions would be
required to cross PAN_IDs in addition to those required to reach
nodes beyond the local link physical connectivity. The PAN_ID limits
the scope of the link. Whether organized as a single physical
broadcast domain, mesh under, or route over, crossing PAN_IDs can be
accomplished as an IP hop, much as routing might be performed among
distinct SSIDs in 802.11 or some bridging option must be employed.
Explicitly, the PAN_ID appears in the formation of an Autoconf IP
Culler, et al. Expires May 15, 2008 [Page 10]
Internet-Draft 6LoWPan Architecture November 2007
address from the IEEE 802.1.4 16-bit short address in order to make
IP addresses for a given short address on different PAN-IDs distinct.
Since the PAN_IDs must match for communication to occur over
802.15.4, any completion of the IP address that is unique to the link
would be sufficient.
The IEEE 802.15.4-2003 specification defines 16 communication
channels in the 2.4 GHz region at a bandwidth of 250 kbps, 10
channels in 915 MHz band at 40 kpbs and one channel in the 868 MHz
band. Typically a node is configured to transmit or receive on a
single channel at a time, and nodes on distinct channels cannot
communicate regardless of physical proximity. 802.15.4 channels are
relatively narrow, considerably narrower than 802.11 channels, for
example, so some link management protocols utilize a channel hopping
schedule over multiple channels to increase the frequency diversity.
The IEEE 802.15.4 specification does not standardize the use of such
multiple channels or define management protocols to establish and
maintain such hopping schedules.
The IEEE specification defines a MAC protocol for use in star and
mesh configurations. It identifies two classes of devices, FFDs and
RFDs and associated power management mechanisms. RFDs can only
communicate with FFDs, so PANs are expected to form clusters with
FFDs as the cluster heads and to coordinate their associated RFDs. A
superframe protocol is defined contention slots. With short range
(low transmit power) radios, power consumption is dominated by the
controller and back end, rather than the amplifier, so the power
consumption is roughly the same whether the device is transmitting,
receiving, or just powered on ready to receive. RFDs are intended to
power their radios in receive mode during beacon slots to maintain
time synchronization with their FFD and to be allocated communication
slots. No power management is defined for FFD to FFD communication.
Many commercial implementations and industrial standards built on
802.15.4 forego the power management mechanisms defined in the
specification and utilize only a small subset of the MAC features.
Many utilize a powered backbone with unscheduled duty cycling of leaf
nodes. Others use sampled listening techniques to wake up for
eminent transmissions, while still others use network wide time
slotting. Thus, while 6LoWPAN is defined in terms of the 802.15.4
frame format, it avoids requiring particular features of the MAC.
The quality of the wireless link between any pair of nodes is a
complicated, time varying function of the transmission signal
strength, the receive sensitivity, path loss due to distance and
environmental factors, multipath effects, interference, collisions,
and other sources of noise. Even nodes in very close proximity may
experience several percent packet loss rates. Packet receive rates
of 70-90% are not uncommon - significantly less than in most current
Culler, et al. Expires May 15, 2008 [Page 11]
Internet-Draft 6LoWPan Architecture November 2007
Internet link. Thus, link level error detection and retransmission
schemes are typically needed to make the 15.4 link suitable for best
effort delivery [cite 99% RFC], especially if multiple IEEE 802.15.4
hops are involved. In addition, the ability to select among multiple
candidate receivers at intermediate hops is very beneficial to
improve reliability and efficiency. Therefore, visibility into
detailed link behavior is typically required by the routing component
(mesh under or route over).
In many PAN applications, there is significant mobility of devices
within the PAN, giving rise to additional time varying connectivity
relationships, in addition to the variation induced by changing
environmental factors. This is not IP mobility in the traditional
sense, as node may remain in close physical proximity and be
connected within the PAN. However, if IP routing is utilized, such
variations require the routing components to adapt to underlying
changes in the connectivity topology. Similar adaptation is required
of the meshing components to adapt to changes in the topology of
connectivity.
Finally, 6LoWPAN stacks will, in many cases, be implemented on
microcontrollers with very modest RAM capacity. Thus, in addition to
an explicitly small MTU, it is advantageous to be able to utilize
small packet buffers, reassembly buffers, and tables. Measures to
compress headers also reduce the memory requirements imposed by the
associated packets in the node.
Given this background of issues, the remainder of this document
outlines how the components of an IPv6 subnet are realized within the
6LoWPAN Architecture.
7. Addressing
RFC 4944 defines packet formats that support a mapping between the
two forms of link layer addresses and certain IP addresses for the
node.
7.1. Stateless Auto-configuration
Each host generates a Link Local IPv6 Unicast Address from its IEEE
802.15.4 EUID64 of the form FE80::EUID64/10. The host is not
required to run a Duplicate Address Detection (DAD) RFC 2462 [4]
process for this to be a validated address. When this address is
utilized as an IP source or destination address it will be elided via
HC1 [2].
Stateless auto-configuration using a randomly generated Interface
Culler, et al. Expires May 15, 2008 [Page 12]
Internet-Draft 6LoWPan Architecture November 2007
Identifier requires some additional care to manage the complexity of
the neighbor cache and/or destination cache, and is discussed below.
7.2. Link Local Well Known Multicast Addresses
The host, or more specifically its LoWPAN interface, implicitly joins
the following multicast groups: Link Local All Nodes (FF02::1), Link
Local All Routers (FF02::2), and Link Local All DHCP Agents
(FF02::1:2). Starting from these basic multicast groups, each host
can establish its role in the network, as described below.
7.3. Short Addresses
The IEEE 802.15.4 link permits the use of 16-bit short addresses for
the source or destination of a packet. These short addresses SHOULD
be unique throughout the PAN. A 6LoWPAN network SHOULD provide a
mechanism for establishing an IP address for each interface, in
addition to the auto-configured address, that is easily translated to
the short address for the host of the interface. The Format Document
RFC4944 specifies that the mapping between the alternative autoconf
interface identifier and the 16-bit short address as given by:
16_bit_PAN:8_zero_bits:FF:FE:8_zero_bits:16_bit_short_address.
This use of the specific 48-bit pseudo-MAC and extension to 64 bits
according to RFC2464 somewhat over constrains the mapping, as the
PAN_ID must match in order for packets to be delivered by the link
and the necessary condition is that there is a consistent mapping to
and from the 16-bit short address. A more general formulation would
have been to allow a random 48 bits to be utilized for the autoconf
address, or even a random 64 bits, the lower 16 of which is xor'd
with the short address. The mapping in RFC4944 is sufficient to
accomplish this.
A 6LoWPAN network should provide a means of generating unique 16 bit
short addresses. Of course, this could be done manually. If the
network utilizes stateful DHCPv6, the DHCP server can provide a
unique short address. Stateless DHCPv6 can be used to assign short
addresses, if the hostnames for the nodes in the PAN are constructed
such that there is a simple mapping to unique short addresses, say by
extracting the last two characters.
Alternatively, if a router is present and a DHCP agent is present,
the short address assignment can be performed by a remote DHCP server
acting through the DHCP agent.
Alternative to IP mechanisms for assigning short addresses, the IEEE
802.15.4 specification introduces the concept of a PAN coordinator
that is responsible for assigning unique short addresses. If such a
Culler, et al. Expires May 15, 2008 [Page 13]
Internet-Draft 6LoWPan Architecture November 2007
capability is present from the link management protocol, the IPv6
autoconf address can be retrieved from the link level PAN
coordinator. Such a PAN coordinator would need to be accessible over
potentially multiple hops, so in the bootstrapping process most of
the multihop communications capability, either mesh under or route
must be operational before short addresses can be obtained. v Unique
short addresses can be assigned without the use of DHCP or PAN
cordinators if Duplicate Address Detection (RFC4429) is supported. A
host may generate a tentative IP address associated with an arbitrary
short address. It joins the Link Local Solicited Node multicast
group (FF02::1:XXXX:XXXX), where XXXX:XXXX is interface ID associated
with the proposed short address, and issues a Neighbor Solicitation
message with an all-zero source address. Conventional DAD serves to
establish the uniqueness of the short address ID.
When IP communication occurs using such a canonical interface
identifier associated with the unique link short address, the address
can be elided using HC1 RFC4944 for the link local prefix or HC1g
[HC1G-ID] for the commom global prefix. Additional IP address can be
assigned to the interface as well, however, 6LoWPAN will not elide
those source or destination addresses. The IEEE 802.15.4
specification allows only one 16-bit short address to be associated
with given radio and current implementations only support one such
identifier.
7.4. Link Local Multicast
Whereas there is a natural mapping between layer 3 communication
using link local IPv6 unicast addresses and the corresponding layer 2
operations on link addresses (the EUID64 or SA16 of the host
providing the interface), the implementation mapping from
communication on IPv6 multicast addresses to layer 2 operations is
less clear.
o In the case of a single broadcast domain, communication to any
link local multicast address is implemented directly by
transmitting with the link short broadcast address, FFFF, as the
destination field.
o The same action is taken in the Route Over design, although the
link local scope may include only a portion of the PAN.
o In a Mesh Under design communication to any link local multicast
address requires dissemination to all nodes in the PAN. If the
the LOWPAN_BC0 in RFC4944 is used to reference the multicast
group, every host in the PAN will receive the packet and those not
within the group will need to discard it. If this mechanism is
not used, some other means of dissemination and duplication
suppression is needed.
In all cases, HC1 compression is able to elide the link local IP
Culler, et al. Expires May 15, 2008 [Page 14]
Internet-Draft 6LoWPan Architecture November 2007
source address, but the link local multicast address must be carried
in line in order to represent the scope in the prefix (FF01) and the
group in the interface identifier (e.g., 1 for all nodes).
HC1g defines a 16-bit short address form (section 4) for common
multicast group addresses containing a 3-bit range identifier, 4-bit
scope, and 9-bit mapped group identifier, so most of the 128-bit
multicast address can be elided. However, HC1g does not permit the
IP source address to be elided if it utilizes the link local prefix.
(This could be fixed by providing the link local variant of the HC1g
prefix, say HC1l, but none has yet been proposed.]
7.5. Scopes
The primary difference in the three basic LoWPAN topologies is the
scope of link local communication. In the single broadcast domain,
it has the conventional meaning &mdash the entire PAN which is
identical to the set of nodes that are reached by a transmission from
any node. If the PAN is not a single broadcast domain and Route Over
is employed, a similar link local scope is defined for each node, but
they are not identical. If the PAN is not a single broadcast domain
and Mesh Under is employed, the link local scope is defined to be the
entire PAN and multiple mesh hops are required to implement operation
of this scope.
7.6. Routing
In order to communicate with hosts external to the PAN, a router must
be present in the PAN and hosts within the PAN must be assigned a
routable prefix, i.e., a prefix of global scope. Such routing
ability does not imply that the PAN is connected to the Internet, it
may be an isolated network, on an intra-net or inter-network within
administrative boundaries. IPv6 defines two scopes &mdash link local
for use when no router is present or known to be present and global.
Conventional ICMPv6 mechanism (or manual actions) are utilized to
perform the assignment. Routers announce their presence with Router
Advertisements. Hosts discover routers by issuing Router
Solicitations to the Link Local All Routers multicast address. The
Interface Identifier produced by stateless autoconf can be utilized
to provide a globally routable address. Stateless DHCPv6 can
associate a convenient hostname with the IPv6 address and stateful
DHCPv6 can be used to assign global IPv6 addresses as desired. In
either case, DNS can be used to register the hostname to IP address
mapping. With HC1 header compression, such global IPv6 addresses for
interfaces within the PAN will be carried in line, even if they
utilize the cannonical interface identifiers, because they do not
carry the link local prefix.
Culler, et al. Expires May 15, 2008 [Page 15]
Internet-Draft 6LoWPan Architecture November 2007
Common global prefix. IPv6 addresses contain a global routing
prefix, subnet ID, and Interface ID. A 6LoWPAN network is typically
contained within a subnet. Where a router is present in the 6LoWPAN
network, it is natural to elide the global routing prefix and subnet
ID, i.e., the prefix, that is used throughout the PAN. Although an
interface can have multiple IP addresses, either due to multiple
interface identifiers or multiple prefixes, by establishing a
canonical prefix, in addition to the two canonical interface
indentifiers, the prefix portions of IP source and destination
addresses can be elided using HC1g. Such addresses can be utilized
for intra-PAN communication as well, even though such communication
may not traverse any router, as long as there is some means, manual
or automated, for establishing the prefix. Typically, such a prefix
is established by the Router Advertisement. Stateful configuration
allows DHCPv6 to provide such a prefix with the IP addresses it
assigns. If no router is present, the prefix is essentially
arbitrary. Communication to the common multicast group address using
the common global prefix for the source address using HC1g per
destination multicast address to be elided.
For example, a Neighbor Solicitation sent to the Link Local All Nodes
address is expected to result in a solicited Neighbor Advertisement
from each of the hosts on the PAN destined for the interface that
sent the solicitation. Unsolicited Neighbor Advertisements are
typically sent to the Link Local All Nodes address, as are Router
Advertisements. A Router Solicitation is typically sent to the Link
Local All Routers address. If no routers are present there will be
no response. If stateless or stateful DHCP is used to establish
hostnames, IP addresses, or other configuration parameters, the Link
Local ALL DHCP Agents is utilized.
In practice, where LoWPAN networks consist of many hosts with limited
network bandwidth and even more limited energy resources, such PAN-
wide solicitations should be kept to a minimum.
8. Normative references
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks",
RFC 4944, September 2007.
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
Culler, et al. Expires May 15, 2008 [Page 16]
Internet-Draft 6LoWPan Architecture November 2007
[4] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
Authors' Addresses
David Culler
Arch Rock
San Francisco, CA
USA
Phone:
Email: dculler@archrock.com
Geoff Mulligan
Proto6
Colorado Springs, CO 80920
USA
Phone: 719.593.2992
Email: geoff@proto6.com
JP Vasseur
Cisco
USA
Phone:
Email:
Culler, et al. Expires May 15, 2008 [Page 17]
Internet-Draft 6LoWPan Architecture November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Culler, et al. Expires May 15, 2008 [Page 18]
