Skip to content

Latest commit

 

History

History
236 lines (166 loc) · 22.7 KB

2.asc

File metadata and controls

236 lines (166 loc) · 22.7 KB

Introduction to 6LoWPAN

One of the drivers of the IoT, where anything can be connected, is the use of wireless technologies to create a communication channel to send and receive information. This wide adoption of wireless technologies allows increasing the number of connected devices but results in limitations in terms of cost, battery life, power consumption, and communication distance for the devices. New technologies and protocols should tackle a new environment, usually called Low power and Lossy networks (LLNs), with the following characteristics:

  1. Significantly more devices than those on current local area networks.

  2. Severely limited code and ram space in devices.

  3. Networks with limited communications distance (range), power and processing resources.

  4. All elements should work together to optimize energy consumption and bandwidth usage.

Another factor that is being widely adopted within IoT is the use of IP as the network protocol. The use of IP provides several advantages, because it is an open standard that is widely available, allowing for easy and cheap adoption, good interoperability and easy application layer development. The use of a common standard like an end-to-end IP-based solution avoids the problem of non-interoperable networks.

For wireless communication technology, the IEEE 802.15.4 standard [IEEE802.15.4] is very promising for the lower (link and physical) layers, although others are also being considered as good options like Low Power WiFi, Bluetooth ® Low Energy, DECT Ultra Low Energy, ITU-T G.9959 networks, and NFC (Near Field Communication).

One component of the IoT that has received significant support from vendors and standardization organizations is that of WSN (Wireless Sensor Networks).

The IETF has different working groups (WGs) developing standards to be used by WSN:

  1. 6lowpan: IPv6 over Low-power Wireless Personal Area Networks [sixlowpan], defines the standards for IPv6 communication over the IEEE 802.15.4 wireless communication technology. 6lowpan acts as an adaptation layer between the standard IPv6 world and the low power and lossy wireless communications medium offered by IEEE 802.15.4. Note that this standard is only defined with IPv6 in mind, no IPv4 support is available.

  2. roll: Routing Over Low power and Lossy networks [roll]. LLNs have specific routing requirements that could not be satisfied with existing routing protocols. This WG focuses on routing solutions for a subset of all possible application areas of LLNs (industrial, connected home, building and urban sensor networks), and protocols are designed to satisfy their application-specific routing requirements. Here again the WG focuses only on the IPv6 routing architectural framework.

  3. 6lo: IPv6 over Networks of Resource-constrained Nodes [sixlo]. This WG deals with IPv6 connectivity over constrained node networks. It extends the work of the 6lowpan WG, defining IPv6-over-foo adaptation layer specifications using 6LoWPAN for link layer in constrained node networks.

As seen, 6LoWPAN is the basis of the work carried out in standardization at IETF to communicate constrained resources nodes in LLNs using IPv6. The work on 6LoWPAN has been completed and is being further complemented by the roll WG to satisfy routing needs and the 6lo WG to extend the 6lowpan standards to any other link layer technology. Following are more details about 6LoWPAN, as the first step into the IPv6 based WSN/IoT. 6LoWPAN and related standards are concerned about providing IP connectivity to devices, irrelevantly of the upper layers, except for the UDP transport layer protocol that is specifically considered.

Overview of LoWPANs

Low-power and lossy networks (LLNs) is the term commonly used to refer to networks made of highly constrained nodes (limited CPU, memory, power) interconnected by a variety of "lossy" links (low-power radio links). They are characterized by low speed, low performance, low cost, and unstable connectivity.

A LoWPAN is a particular instance of an LLN, formed by devices complying with the IEEE 802.15.4 standard.

The typical characteristics of devices in a LoWPAN are:

  1. Limited Processing Capability: Different types and clock speeds processors, starting at 8-bits.

  2. Small Memory Capacity: From few kilobytes of RAM with a few dozen kilobytes of ROM/flash memory, it’s expected to grow in the future, but always trying to keep at the minimum necessary.

  3. Low Power: In the order of tens of milliamperes.

  4. Short Range: The Personal Operating Space (POS) defined by IEEE 802.15.4 implies a range of 10 meters. For real implementations it can reach over 100 meters in line-of-sight situations.

  5. Low Cost: This drives some of the other characteristics such as low processing, low memory, etc.

All this constraints on the nodes are expected to change as technology evolves, but compared to other fields it’s expected that the LoWPANs will always try to use very restricted devices to allow for low prices and long life which implies hard restrictions in all other features.

A LoWPAN typically includes devices that work together to connect the physical environment to real-world applications, e.g., wireless sensors, although a LoWPAN is not necessarily comprised of sensor nodes only, since it may also contain actuators.

It’s also important to identify the characteristics of LoWPANs, because they will be the constraints guiding all the technical work:

  1. Small packet size: Given that the maximum physical layer frame is 127 bytes, the resulting maximum frame size at the media access control layer is 102 octets. Link-layer security imposes further overhead, which leaves a maximum of 81 octets for data packets.

  2. IEEE 802.15.4 defines several addressing modes: It allows the use of either IEEE 64-bit extended addresses or (after an association event) 16-bit addresses unique within the PAN (Personal Area Network).

  3. Low bandwidth: Data rates of 250 kbps, 40 kbps, and 20 kbps for each of the currently defined physical layers (2.4GHz, 915MHz, and 868MHz, respectively).

  4. Topologies include star and mesh.

  5. Large number of devices expected to be deployed during the lifetime of the technology. Location of the devices is typically not predefined, as they tend to be deployed in an ad-hoc fashion. Sometimes the location of these devices may not be easily accessible or they may move to new locations.

  6. Devices within LoWPANs tend to be unreliable due to variety of reasons: uncertain radio connectivity, battery drain, device lockups, physical tampering, etc.

  7. Sleeping mode: Devices may sleep for long periods of time in order to conserve energy, and are unable to communicate during these sleep periods.

About the use of IP on LoWPANs

As said before, it seems that the use of IP, and specifically IPv6, is being widely adopted because it offers several advantages. 6LoWPANs are IPv6-based LoWPAN networks.

In this section we will see these advantages as well as some problems raised by the use of IP over LoWPANs.

The application of IP technology and, in particular, IPv6 networking is assumed to provide the following benefits to LoWPANs:

  1. The pervasive nature of IP networks allows leveraging existing infrastructure.

  2. IP-based technologies already exist, are well-known, proven to be working and widely available. This allows for an easier and cheaper adoption, good interoperability and easier application layer development.

  3. IP networking technology is specified in open and freely available specifications, which is able to be better understood by a wider audience than proprietary solutions.

  4. Tools for IP networks already exist.

  5. IP-based devices can be connected readily to other IP-based networks, without the need for intermediate entities like protocol translation gateways or proxies.

  6. The use of IPv6, specifically, allows for a huge amount of addresses and provides for easy network parameters autoconfiguration (SLAAC). This is paramount for 6LoWPANs where large number of devices should be supported.

On the counter side using IP communication in LoWPANs raise some issues that should be taken into account:

  1. IP Connectivity: One of the characteristics of 6LoWPANs is the limited packet size, which implies that headers for IPv6 and layers above must be compressed whenever possible.

  2. Topologies: LoWPANs must support various topologies including mesh and star: Mesh topologies imply multi-hop routing to a desired destination. In this case, intermediate devices act as packet forwarders at the link layer. Star topologies include provisioning a subset of devices with packet forwarding functionality. If, in addition to IEEE 802.15.4, these devices use other kinds of network interfaces such as Ethernet or IEEE 802.11, the goal is to seamlessly integrate the networks built over those different technologies. This, of course, is a primary motivation to use IP to begin with.

  3. Limited Packet Size: Applications within LoWPANs are expected to originate small packets. Adding all layers for IP connectivity should still allow transmission in one frame, without incurring excessive fragmentation and reassembly. Furthermore, protocols must be designed or chosen so that the individual "control/protocol packets" fit within a single 802.15.4 frame.

  4. Limited Configuration and Management: Devices within LoWPANs are expected to be deployed in exceedingly large numbers. Additionally, they are expected to have limited display and input capabilities. Furthermore, the location of some of these devices may be hard to reach. Accordingly, protocols used in LoWPANs should have minimal configuration, preferably work "out of the box", be easy to bootstrap, and enable the network to self heal given the inherent unreliable characteristic of these devices.

  5. Service Discovery: LoWPANs require simple service discovery network protocols to discover, control and maintain services provided by devices.

  6. Security: IEEE 802.15.4 mandates link-layer security based on AES, but it omits any details about topics like bootstrapping, key management, and security at higher layers. Of course, a complete security solution for LoWPAN devices must consider application needs very carefully.

6LoWPAN

We have seen that there is a lower layer (physical and link layers on TCP/IP stack model) that provide connectivity to devices in what is called a LoWPAN. Also that using IPv6 over this layer would bring several benefits. The main reason for developing the IETF standards mentioned in the introduction is that between the IP (network layer) and the lower layer there are some important issues that need to be solved by means of an adaptation layer, the 6lowpan.

image001
Figure 1. 6LoWPAN in the protocol stack

The main goals of 6lowpan are:

  1. Fragmentation and Reassembly layer: IPv6 specification [RFC2460] establishes that the minimum MTU that a link layer should offer to the IPv6 layer is 1280 bytes. The protocol data units may be as small as 81 bytes in IEEE 802.15.4. To solve this difference a fragmentation and reassembly adaptation layer must be provided at the layer below IP.

  2. Header Compression: Given that in the worst case the maximum size available for transmitting IP packets over an IEEE 802.15.4 frame is 81 octets, and that the IPv6 header is 40 octets long, (without optional extension headers), this leaves only 41 octets for upper-layer protocols, like UDP and TCP. UDP uses 8 octets in the header and TCP uses 20 octets. This leaves 33 octets for data over UDP and 21 octets for data over TCP. Additionally, as pointed above, there is also a need for a fragmentation and reassembly layer, which will use even more octets leaving very few octets for data. Thus, if one were to use the protocols as is, it would lead to excessive fragmentation and reassembly, even when data packets are just 10s of octets long. This points to the need for header compression.

  3. Address Autoconfiguration: specifies methods for creating IPv6 stateless address auto configuration (in contrast to stateful) that is attractive for 6LoWPANs, because it reduces the configuration overhead on the hosts. There is a need for a method to generate the IPv6 IID (Interface Identifier) from the EUI-64 assigned to the IEEE 802.15.4 device.

  4. Mesh Routing Protocol: A routing protocol to support a multi-hop mesh network is necessary. Care should be taken when using existing routing protocols (or designing new ones) so that the routing packets fit within a single IEEE 802.15.4 frame. The mechanisms defined by 6lowpan IETF WG are based on some requirements for the IEEE 802.15.4 layer:

  5. IEEE 802.15.4 defines four types of frames: beacon frames, MAC command frames, acknowledgement frames and data frames. IPv6 packets must be carried on data frames.

  6. Data frames may optionally request that they be acknowledged. It is recommended that IPv6 packets be carried in frames for which acknowledgements are requested so as to aid link-layer recovery.

  7. The specification allows for frames in which either the source or destination addresses (or both) are elided. Both source and destination addresses are required to be included in the IEEE 802.15.4 frame header.

  8. The source or destination PAN ID fields may also be included. 6LoWPAN standard assumes that a PAN maps to a specific IPv6 link.

  9. Both 64-bit extended addresses and 16-bit short addresses are supported, although additional constraints are imposed on the format of the 16-bit short addresses.

  10. Multicast is not supported natively in IEEE 802.15.4. Hence, IPv6 level multicast packets must be carried as link-layer broadcast frames in IEEE 802.15.4 networks. This must be done such that the broadcast frames are only heeded by devices within the specific PAN of the link in question.

The 6LoWPAN adaptation format was specified to carry IPv6 datagrams over constrained links, taking into account limited bandwidth, memory, or energy resources that are expected in applications such as wireless sensor networks. For each of these goals and requirements there is a solution provided by the 6lowpan specification:

  1. A Mesh Addressing header to support sub-IP forwarding.

  2. A Fragmentation header to support the IPv6 minimum MTU requirement.

  3. A Broadcast Header to be used when IPv6 multicast packets must be sent over the IEEE 802.15.4 network.

  4. Stateless header compression for IPv6 datagrams to reduce the relatively large IPv6 and UDP headers down to (in the best case) several bytes. These header are used as the LoWPAN encapsulation, and could be used at the same time forming what is called the header stack. Each header in the header stack contains a header type followed by zero or more header fields. When more than one LoWPAN header is used in the same packet, they must appear in the following order: Mesh Addressing Header, Broadcast Header, and Fragmentation Header.

image002
Figure 2. 6LoWPAN headers

IPv6 Interface Identifier (IID)

As already said an IEEE 802.15.4 device could have two types of addresses. For each one there is a different way of generating the IPv6 IID.

  1. IEEE EUI-64 address: All devices have this one. In this case, the Interface Identifier is formed from the EUI-64, complementing the "Universal/Local" (U/L) bit, which is the next-to-lowest order bit of the first octet of the EUI-64. Complementing this bit will generally change a 0 value to a 1.

image003
Figure 3. EUI-64 derived IID

  1. 16-bit short addresses: Possible but not always used. The IPv6 IID is formed using the PAN (or zeroes in case of not knowing the PAN) and the 16 bit short address as in the figure below.

image004
Figure 4. IPv6IID

Header Compression

Two encoding formats are defined for compression of IPv6 packets: LOWPAN_IPHC and LOWPAN_NHC, an encoding format for arbitrary next headers.

To enable effective compression, LOWPAN_IPHC relies on information pertaining to the entire 6LoWPAN. LOWPAN_IPHC assumes the following will be the common case for 6LoWPAN communication:

  1. Version is 6.

  2. Traffic Class and Flow Label are both zero.

  3. Payload Length can be inferred from lower layers from either the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header.

  4. Hop Limit will be set to a well-known value by the source.

  5. Addresses assigned to 6LoWPAN interfaces will be formed using the link-local prefix or a small set of routable prefixes assigned to the entire 6LoWPAN.

  6. Addresses assigned to 6LoWPAN interfaces are formed with an IID derived directly from either the 64-bit extended or the 16-bit short IEEE 802.15.4 addresses. Depending on how closely the packet matches this common case, different fields may not be compressible thus needing to be carried "in-line" as well. The base format used in LOWPAN_IPHC encoding is shown in the figure below.

image005
Figure 5. Header compression

Where:

  • TF: Traffic Class, Flow Label.

  • NH: Next Header.

  • HLIM: Hop Limit.

  • CID: Context Identifier Extension.

  • SAC: Source Address Compression.

  • SAM: Source Address Mode.

  • M: Multicast Compression.

  • DAC: Destination Address Compression.

  • DAM: Destination Address Mode.

Not going into details, it’s important to understand how 6LoWPAN compression works. To this end, let’s see two examples:

  1. HLIM (Hop Limit): Is a two bits field that can have four values, three of them make the hop limit field to be compressed from 8 to 2 bits:

    1. 00: Hop Limit field carried in-line. There is no compression and the whole field is carried in-line after the LOWPAN_IPHC.

    2. 01: Hop Limit field compressed and the hop limit is 1.

    3. 10: Hop Limit field compressed and the hop limit is 64.

    4. 11: Hop Limit field compressed and the hop limit is 255.

  2. SAC/DAC used for the source IPv6 address compression. SAC indicates which address compression is used, stateless (SAC=0) or stateful context-based (SAC=1). Depending on SAC, DAC is used in the following way:

    1. If SAC=0, then SAM:

      • 00: 128 bits. Full address is carried in-line. No compression.

      • 01: 64 bits. First 64-bits of the address are elided, the link-local prefix. The remaining 64 bits are carried in-line.

      • 10: 16 bits. First 112 bits of the address are elided. First 64 bits is the link-local prefix. The following 64 bits are 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in-line.

      • 11: 0 bits. Address is fully elided. First 64 bits of the address are the link-local prefix. The remaining 64 bits are computed from the encapsulating header (e.g., 802.15.4 or IPv6 source address).

    2. If SAC=1, then SAM:

      • 00: 0 bits. The unspecified address (::).

      • 01: 64 bits. The address is derived using context information and the 64 bits carried in-line. Bits covered by context information are always used. Any IID bits not covered by context information are taken directly from the corresponding bits carried in-line.

      • 10: 16 bits. The address is derived using context information and the 16 bits carried in-line. Bits covered by context information are always used. Any IID bits not covered by context information are taken directly from their corresponding bits in the 16-bit to IID mapping given by 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in-line.

      • 11: 0 bits. The address is fully elided and it is derived using context information and the encapsulating header (e.g., 802.15.4 or IPv6 source address). Bits covered by context information are always used. Any IID bits not covered by context information are computed from the encapsulating header.

The base format is two bytes (16 bits) long. If the CID (Context Identifier Extension) field has a value of 1, it means that an additional 8-bit Context Identifier Extension field immediately follows the Destination Address Mode (DAM) field. This would make the length be 24 bits or three bytes.

This additional octet identifies the pair of contexts to be used when the IPv6 source and/or destination address is compressed. The context identifier is 4 bits for each address, supporting up to 16 contexts. Context 0 is the default context. The two fields on the Context Identifier Extension are:

  • SCI: Source Context Identifier. Identifies the prefix that is used when the IPv6 source address is statefully compressed.

  • DCI: Destination Context Identifier. Identifies the prefix that is used when the IPv6 destination address is statefully compressed.

The Next Header field in the IPv6 header is treated in two different ways, depending on the values indicated in the NH (Next Header) field of the LOWPAN_IPHC enconding shown above.

If NH = 0, then this field is not compressed and all the 8 bits are carried in-line after the LOWPAN_IPHC.

If NH = 1, then the Next Header field is compressed and the next header is encoded using LOWPAN_NHC encoding. This results in the structure shown in the figure below.

image006
Figure 6. LoWPAN header

For IPv6 Extension headers the LOWPAN_NHC has the format shown in the figure, where:

  • EID: IPv6 Extension Header ID:

    • 0: IPv6 Hop-by-Hop Options Header.

    • 1: IPv6 Routing Header.

    • 2: IPv6 Fragment Header.

    • 3: IPv6 Destination Options Header.

    • 4: IPv6 Mobility Header.

    • 5: Reserved.

    • 6: Reserved.

    • 7: IPv6 Header.

  • NH: Next Header

    • 0: Full 8 bits for Next Header are carried in-line.

    • 1: Next Header field is elided and is encoded using LOWPAN_NHC. For the most part, the IPv6 Extension Header is carried unmodified in the bytes immediately following the LOWPAN_NHC octet.

NDP optimization

IEEE 802.15.4 and other similar link technologies have limited or no usage of multicast signalling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non-transitive wireless links, since its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network.

For this reasons, some simple optimizations have been defined for IPv6 Neighbor Discovery, its addressing mechanisms and duplicate address detection for LoWPANs [RFC6775]:

  1. Host-initiated interactions to allow for sleeping hosts.

  2. Elimination of multicast-based address resolution for hosts.

  3. A host address registration feature using a new option in unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages.

  4. A new Neighbor Discovery option to distribute 6LoWPAN header compression context to hosts.

  5. Multihop distribution of prefix and 6LoWPAN header compression context.

  6. Multihop Duplicate Address Detection (DAD), which uses two new ICMPv6 message types.

The two multihop items can be substituted by a routing protocol mechanism if that is desired.

Three new ICMPv6 message options are defined:

  1. The Address Registration Option (ARO).

  2. The Authoritative Border Router Option (ABRO).

  3. The 6LoWPAN Context Option (6CO)

Also two new ICMPv6 message types are defined:

  1. The Duplicate Address Request (DAR).

  2. The Duplicate Address Confirmation (DAC)