6LoWPAN Peter B. Mariager, Ed. Internet-Draft Jens T. Petersen Intended status: Informational RTX A/S Expires: May 3, 2012 October 31, 2011 Transmission of IPv6 Packets over DECT Ultra Low Energy draft-mariager-6lowpan-v6over-dect-ule-01 Abstract DECT Ultra Low Energy is a low power air interface technology that is defined by the DECT Forum and specified by ETSI. The DECT air interface technology has been used world-wide in communication devices for more than 15 years, primarily carrying voice for cordless telephony but has also been deployed for data centric services. The DECT Ultra Low Energy is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation etc. As the DECT Ultra Low Energy interface inherits many of the capabilities from DECT, it benefits from long range, interference free operation, world wide reserved frequency band, low silicon prices and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE. This document describes how IPv6 is transported over DECT ULE using 6LoWPAN techniques. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 3, 2012. Copyright Notice Mariager & Petersen Expires May 3, 2012 [Page 1] Internet-Draft IPv6 over DECT ULE October 2011 Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . . 3 1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The DECT ULE Protocol Stack . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Addressing Model . . . . . . . . . . . . . . . . . . . . . . . 6 5. MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. IPv6 Address Configuration . . . . . . . . . . . . . . . . . . 7 7. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . . 7 8. Unicast and Multicast address mapping . . . . . . . . . . . . . 8 9. Header Compression . . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 11. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 9 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 14. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 15. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Mariager & Petersen Expires May 3, 2012 [Page 2] Internet-Draft IPv6 over DECT ULE October 2011 1. Introduction DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface technology building on the key fundamentals of traditional DECT / CAT-iq but with specific changes to significantly reduce the power consumption on the expense of data throughput. DECT ULE devices with requirements to power consumption will operate on special power optimized silicon, but can connect to a DECT Gateway supporting traditional DECT / CAT-iq for cordless telephony and data as well as the ULE extensions. DECT terminology operates with two major role definitions: The Portable Part (PP) is the power constrained device, while the Fixed Part (FP) is the Gateway or base station. This FP may be connected to the internet. An example of a use case for DECT ULE is a home security sensor transmitting small amounts of data (few bytes) at periodic intervals through the FP, but is able to wake up upon an external event (burglar) and communicate with the FP. Another example incorporating both DECT ULE as well as traditional CAT-iq telephony is an elderly pendant (broche) which can transmit periodic status messages to a care provider using very little battery, but in the event of urgency, the elderly person can establish a voice connection through the pendant to an alarm service. It is expected that DECT ULE will be integrated into many residential gateways, as many of these already implements DECT CAT-iq for cordless telephony. DECT ULE can be added as a software option for the FP. It is desirable to consider IPv6 for DECT ULE devices due to the large address space and well-known infrastructure. This document describes how IPv6 is used on DECT ULE links to optimize power while maintaining the many benefits of IPv6 transmission. [RFC4944] specifies the transmission of IPv6 over IEEE 802.15.4. DECT ULE has in many ways similar characteristics of IEEE 802.15.4, but also differences. Many of the mechanisms defined in [RFC4944] can be applied to the transmission of IPv6 on DECT ULE links. This document specifies how to map IPv6 over DECT ULE inspired by RFC4944 1.1. Requirements Notation 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.2. Terms Used PP: DECT Portable Part, typically the sensor node FP: DECT Fixed Part, the gateway Mariager & Petersen Expires May 3, 2012 [Page 3] Internet-Draft IPv6 over DECT ULE October 2011 LLME: Lower Layer Management Entity NWK: Network 2. The DECT ULE Protocol Stack The DECT ULE protocol stack consists of the PHY layer operating at frequencies in the 1800 - 1920 MHz frequency band depending on the region and uses a symbol rate of 1.152 Mbps. In its generic network topology, DECT is defined as a cellular network technology. However, the most common configuration is a star network with a single FP defining the network with a number of PP attached. The MAC layer must support both traditional DECT as this is used for services like discovery, pairing, security features etc. All these features have been reused from DECT. The DECT ULE device can then switch to the ULE mode of operation, utilizing the new ULE MAC layer features. The DECT ULE Data Link Control (DLC) provides multiplexing as well as segmentation and re- assembly for larger packets from layers above. The DECT ULE layer should also implement per-message authentication and encryption. In general, communication sessions can be initiated from both FP and PP side. Depending of power down modes employed in the PP, latency may occur when initiating sessions from FP side. MAC layer communication can either take place using connection less packet transfer with low overhead for short sessions or take place using connection oriented bearers including media reservation. The MAC layer autonomously selects the radio spectrum positions that are available within the band and can rearrange these to avoid interference. The DECT ULE device will incorporate an Application Programmers Interface (API) as well as common elements known as Generic Access Profile (GAP) for enrolling into the network. Mariager & Petersen Expires May 3, 2012 [Page 4] Internet-Draft IPv6 over DECT ULE October 2011 +----------------------------------------+ | Applications | +----------------------------------------+ | Generic Access Profile | ULE Profile | +----------------------------------------+ | DECT/Service API | ULE Data API | +--------------------+-------------------+ | LLME | NWK | | +--------------------+-------------------+ | DECT DLC | DECT ULE DLC | +--------------------+-------------------+ | MAC Layer | +--------------------+-------------------+ | Physical Layer | +--------------------+-------------------+ Figure 1: DECT ULE Protocol Stack The DLC layer layer has to provide a reliable channel, either directly or through MAC layer service to the higher layers. It is expected that the ULE 6LoWPAN adaptation layer can run directly on this DLC layer. Figure 2 illustrates IPv6 over DECT ULE stack. Constrained Application Protocol (CoAP) is an application protocol specifically designed for resource constrained environments. CoAP could be run on top of IPv6 supporting requests from the server and requests of cached replies from a CoAP/HTTP proxy in the DECT Fixed Part. Alternatively, the use of HTTP light, as defined for CAT-iq v3 can be considered. Mariager & Petersen Expires May 3, 2012 [Page 5] Internet-Draft IPv6 over DECT ULE October 2011 +-------------------+ | Applications | +-------------------+ | CoAP/HTTP | +-------------------+ |IPv6 adaption layer| +-------------------+ | DECT ULE DLC | +-------------------+ | DECT ULE MAC | +-------------------+ | DECT ULE PHY | +-------------------+ Figure 2: IPv6 over DECT ULE Stack 3. Requirements DECT ULE technology sets strict requirements for low power consumption and thus limits the allowed protocol overhead. 6LoWPAN standard [RFC4944] provides useful generic functionality like header compression, link-local IPv6 addresses, Neighbor Discovery and stateless IP-address autoconfiguration for reducing the overhead in 802.15.4 networks. This functionality can be partly applied to DECT ULE. 4. Addressing Model Each DECT PP is assigned an (International Portable Equipment Identity) during manufacturing. This identity has the size of 40 bits and is unique for the PP and will be used to constitute the MAC address. When bound to the FP, a PP is assigned a 20 bit TPUI (Temporary Portable User Identity) which is unique within the FP. This TPUI is used for addressing in messages between FP and PP. Each DECT FP is assigned a (Radio Fixed Part Identity) during manufacturing. This identity has the size of 40 bits and is unique for a FP and will be used to constitute the PAN identity. Mariager & Petersen Expires May 3, 2012 [Page 6] Internet-Draft IPv6 over DECT ULE October 2011 5. MTU Considerations Generally the DECT ULE PP generate data that fits into one MAC Layer packet (40 bytes or optionally 80 bytes) that is transferred to the FP periodically, depending on application. IP data packets may be much larger and hence MTU size should be the size of the IP data packet. Larger IP packets can be transferred with the Segmentation and reassembly (SAR) feature of the DLC Layer. If an implementation cannot support the larger MTU size (due to cost) then SAR needs to be supported at upper layers. The SAR feature of [RFC4944] section 5 could also be considered. It is expected that the LOWPAN_IPHC packet will fulfill all the requirements for header compression without spending unnecessary overhead for mesh addressing. It is important to realize that the support of larger packets will be on the expense of battery life, as a large packet will be fragmented into several or many MAC layer packets, each consuming power to transmit / receive. 6. IPv6 Address Configuration StateLess AutoConfiguration (SLAC) and other means to configure an address on a ULE device. Neighbor Discovery Optimization for Low-power and Lossy Networks [I-D.ietf-6lowpan-hc]. Resulting addressing can be achieved by combining the 40bit RFPI of the FP and the 20bit TPUI of the PP. A mapping scheme to compute the IID must be developed. 7. IPv6 Link Local Address How do we form the IPv6 Link Local Address, or can this be obtained from the IID using SLAC ? The IPv6 LLA [RFC4291] for a DECT ULE device is formed by appending the XXXX to form the 128 bit LLA. this is done by appending the prefix FE80::/64 to the IPv6 address found through SLAAC. All packets transferred between the ULE FP and PP are addressed on Mariager & Petersen Expires May 3, 2012 [Page 7] Internet-Draft IPv6 over DECT ULE October 2011 MAC layer by the 20bit TPUI. 8. Unicast and Multicast address mapping It should be investigated how to support the LOWPAN_BC0 packets for broadcast How do we utilize the DECT Broadcast features for multicast ? DECT FP has MAC features to allow broadcast or multicast small amount of data (max 27 bytes). However ULE PP entering into long sleep period cannot receive these packets reliably. Other methods for emulating broadcast/multicast could be considered, such as queuing these packets until a ULE PP wakes up. 9. Header Compression Compression Format for IPv6 Datagrams in Low Power and Lossy Networks (6LoWPAN) [I-D.ietf-6lowpan-hc]. In [RFC4944] different types of frame formats and related headers have been defined to support fragmentation and mesh addressing. In ULE context LoWPAN_IPHC compressed IPv6 header would be used by default. Support for fragmentation and mesh headers can be added if required (if not provided by the ULE DLC layer). 10. Security Considerations The transmission of speech over DECT will be based on the DSAA2 and DSC2 work being developed by the DF Security group / ETSI TC DECT and the ETSI SAGE Security expert group. However, these security mechanisms may not be fully compatible to the connection-less nature of DECT ULE, hence new mechanisms must be investigated. Additional security such as per-message authentication through CBC- MAC are currently being defined in the ETSI TC-DECT ULE group. It is expected that the DECT ULE DLC layer will implement per-message authentication and encryption to optionally provide security on top of the mandatory and additional security mechanicms defined in ETSI TC-DECT. The underlying algorithm for providing authentication and encryption is based on AES128. Individual key for each ULE PP are generated during the binding procedure. Encryption keys are renewed regularly. DECT ULE does not use any shared encryption key. Mariager & Petersen Expires May 3, 2012 [Page 8] Internet-Draft IPv6 over DECT ULE October 2011 11. Considerations PP roaming between FP is not considered in this draft. The use of repeater functionality is not considered in this draft 12. Acknowledgements 13. IANA Considerations 14. Security Considerations 15. Normative References [ETSI EN300 175 (1-7)] "". [ETSI TS102 827] "". [I-D.ietf-6lowpan-hc] "". [I-D.ietf-6lowpan-nd] "". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4291] "". [RFC4944] "". Authors' Addresses Peter B. Mariager (editor) RTX A/S Email: pm@rtx.dk Mariager & Petersen Expires May 3, 2012 [Page 9] Internet-Draft IPv6 over DECT ULE October 2011 Jens T. Petersen RTX A/S Email: jtp@rtx.dk Mariager & Petersen Expires May 3, 2012 [Page 10]