[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-ietf-6lo-dect-ule

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 <IPEI> (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 <RFPI> (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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/