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

Versions: (draft-patil-6lowpan-v6over-btle) 00 01 02 03 04 05 06 07 08 09 10 11 12 draft-ietf-6lo-btle

Individual Submission                                   J. Nieminen, Ed.
Internet-Draft                                                  B. Patil
Intended status: Standards Track                           T. Savolainen
Expires: October 22, 2011                                     M. Isomaki
                                                                   Nokia
                                                               Z. Shelby
                                                               Sensinode
                                                                C. Gomez
                                              Universitat Politecnica de
                                                         Catalunya/i2CAT
                                                          April 19, 2011


         Transmission of IPv6 Packets over Bluetooth Low Energy
                   draft-ietf-6lowpan-btle-00

Abstract

   Bluetooth Low Energy is a low power air interface technology that is
   defined by the Bluetooth SIG.  The standard Bluetooth radio has been
   widely implemented and available in mobile phones, notebook
   computers, audio headsets and many other devices.  The low power
   version of Bluetooth is a new specification and enables the use of
   this air interface with devices such as sensors, smart meters,
   appliances, etc.  There is an added value in the ability to
   communicate with sensors over IPv6.  This document describes how IPv6
   is transported over Bluetooth Low Energy 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 October 22, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the



Nieminen, et al.        Expires October 22, 2011                [Page 1]


Internet-Draft               IPv6 over BT-LE                  April 2011


   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
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Bluetooth Low Energy protocol stack  . . . . . . . . . . . . .  4
     3.1.  Support for IPv6 over BT-LE  . . . . . . . . . . . . . . .  5
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Bluetooth Low Energy roles and network topology  . . . . . . .  6
   6.  BT-LE network connectivity scenarios . . . . . . . . . . . . .  6
   7.  Addressing Model . . . . . . . . . . . . . . . . . . . . . . .  7
   8.  MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   9.  LoWPAN Adaptation for BT-LE and frame format . . . . . . . . .  8
   10. IPv6 Address configuration . . . . . . . . . . . . . . . . . .  8
   11. IPv6 LLA in BLE  . . . . . . . . . . . . . . . . . . . . . . .  8
   12. Unicast and Multicast address mapping  . . . . . . . . . . . .  9
   13. Header compression . . . . . . . . . . . . . . . . . . . . . .  9
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   15. Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   16. Additional contributors  . . . . . . . . . . . . . . . . . . . 11
   17. Normative References . . . . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Bluetooth Low Energy basics . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12















Nieminen, et al.        Expires October 22, 2011                [Page 2]


Internet-Draft               IPv6 over BT-LE                  April 2011


1.  Introduction

   Bluetooth Low Energy (BT-LE) is a radio technology targeted for
   devices that operate with coin cell batteries, which means that low
   power consumption is essential.  BT-LE can also be integrated into
   existing Bluetooth (BT) devices so that devices such as mobile phones
   and PCs can operate with existing BT accessories as well as BT-LE
   accessories.  An example of a use case for a BT-LE accessory is a
   heart rate monitor that sends data via the mobile phone to a server
   on the Internet.  BT-LE is designed for transferring small amount of
   data (in most cases less than 10 bytes) less frequently (e.g. every
   500 ms) at modest data rates (e.g. 300 kbps).  BT-LE enables low cost
   sensors to send their data over the Internet via a gateway such as a
   mobile phone.  BT-LE is an especially attractive technology for
   Internet of Things applications, such as health monitors,
   environmental sensing and proximity applications.

   Considering the expected explosion in the number of sensors, IPv6 is
   an ideal protocol due to the large address space it provides.  In
   addition, IPv6 provides tools for autoconfiguration and unattended
   operation, which are particularly suitable for sensor network
   applications.  This document describes how IPv6 is used on Bluetooth
   Low Energy links in a power efficient manner along with efficient
   application protocols that enable the integration of BT-LE devices
   into services.

   [RFC4944] specifies the transmission of IPv6 over IEEE 802.15.4.  The
   Bluetooth Low Energy link in many respects has similar
   characteristics to that of IEEE 802.15.4.  Many of the mechanisms
   defined in [RFC4944] can be applied to the transmission of IPv6 on
   Bluetooth Low Energy links.  This document specifies the details of
   IPv6 transmission over Bluetooth Low Energy links.


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 RFC 2119 [RFC2119].

2.1.  Terminology

   Bluetooth Low Energy

      Bluetooth low energy is a low power air interface technology
      specified by the Bluetooth Special Interest Group (SIG).





Nieminen, et al.        Expires October 22, 2011                [Page 3]


Internet-Draft               IPv6 over BT-LE                  April 2011


   Gateway

      Network element connecting the BT-LE sensors to the Internet.  Can
      be e.g a home gateway or a mobile device.




   ND-Proxy

      A gateway that operates as a proxy for IPv6 neighbor discovery


3.  Bluetooth Low Energy protocol stack

   Bluetooth Low Energy is a low power wireless technology developed by
   the BT-SIG.  The lower layer of the BT-LE stack consists of the RF
   and the Link layer which are implemented in the BT-LE controller.
   The upper layer consists of the Logical Link Control and Adaptation
   Protocol (L2CAP), Generic Attribute protocol (GATT) and Generic
   Attribute profile (GAP) as shown in Figure 1.  GATT and BT-LE
   profiles together enable the creation of applications in a
   standardized way without using IP.  L2CAP provides multiplexing
   capability by multiplexing the data channels from the above layers.
   L2CAP also provides fragmentation and reassembly for larger data
   packets.  Link Layer (LL) is responsible for managing the channels
   and Physical Layer (PHY) transmits and receives the actual packets.


                  +----------------------------------------+
                  |              Applications              |
                  +----------------------------------------+
                  |          Generic Access Profile        |
                  +----------------------------------------+
                  |        Generic Attribute Profile       |
                  +----------------------------------------+
                  | Attribute Protocol |Security Manager   |
                  +--------------------+-------------------+
                  |    Logical Link Control and Adaptation |
                  +--------------------+-------------------+
                  |        Host Controller Interface       |
                  +--------------------+-------------------+
                  |     Link Layer     | Direct Test Mode  |
                  +--------------------+-------------------+
                  |             Physical Layer             |
                  +--------------------+-------------------+





Nieminen, et al.        Expires October 22, 2011                [Page 4]


Internet-Draft               IPv6 over BT-LE                  April 2011


                      Figure 1: BT-LE Protocol Stack

3.1.  Support for IPv6 over BT-LE

   Either a connection oriented channel SHOULD be added to the current
   BT-LE specification, over which parts of 6LoWPAN, IPv6 and
   application protocols can be run or a new fixed channel ID SHOULD be
   reserved for IPv6 traffic.  Figure 2 illustrates IPv6 over BT-LE
   stack.

   CoAP is a lightweight protocol specifically designed for resource
   constrained RESTful environments.  CoAP is similar to HTTP but more
   compact and runs on UDP.  CoAP supports simple Create, Read, Write
   and Delete operations on resources (URIs).  CoAP also provides
   mapping to normal HTTP.  CoAP overhead in requests is 5 bytes, in
   responses 4 bytes.  When considering the total IPv6 + UDP +CoAP
   overhead in requests and responses it would be 10-11 Bytes with link
   local addresses and 34-35 Bytes with global addresses.  The rest is
   URL + real payload.  If HTTP/TCP was used instead of CoAP/UDP, IPv6 +
   TCP headers alone would take 22 Bytes with link local addresses and
   55 Bytes with global addresses assuming that optional timestamps in
   TCP headers are not used.  HTTP overhead, which can vary, will be
   added on top of these.  Taking into account the small size of
   physical layer BT-LE PDUs (maximum 255 Bytes in some implementations
   excluding headers), URL can not be too long considering that enough
   space has to be left for the actual payload.  URLs could be e.g. '/t'
   instead of '/temperature', and payload can be binary instead of
   ASCII.



                  +-------------------+
                  |   Applications    |
                  +-------------------+
                  |   (CoAP/HTTP)     |
                  +-------------------+
                  |    (UDP/TCP)      |
                  +-------------------+
                  |  Compressed IPv6  |
                  +-------------------+
                  |  BT-LE L2CAP      |
                  +-------------------+
                  |  BT-LE Link Layer |
                  +-------------------+
                  |  BT-LE Physical   |
                  +-------------------+





Nieminen, et al.        Expires October 22, 2011                [Page 5]


Internet-Draft               IPv6 over BT-LE                  April 2011


                      Figure 2: IPv6 over BT-LE Stack


4.  Requirements

   BT-LE 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
   BT-LE.


5.  Bluetooth Low Energy roles and network topology

   BT-LE defines two Link Layer roles: the Master Role and the Slave
   Role.  A device in the Master Role, which is called master, can
   manage multiple simultaneous connections with a number of devices in
   the Slave Role, called slaves.  A slave can only be connected to a
   single master.  Hence, a BT-LE network (i.e. a BT-LE piconet) follows
   a star topology.

   A master is assumed to be less constrained than a slave.  Hence,
   master and slave can correlate with 6LBR and host, respectively.

   A significant difference between IEEE 802.15.4 and BT-LE is that the
   former supports the mesh topology (and requires a routing protocol),
   whereas BT-LE does not currently support the formation of multihop
   networks.  In consequence, the mesh header defined in [RFC4944] for
   mesh under routing MUST NOT be used in BT-LE networks.  On the other
   hand, a BT-LE device MUST NOT play the role of a 6LR.

   In BT-LE, communication only takes place between a master and a
   slave.  Hence, in a BT-LE network using IP, a radio hop is equivalent
   to an IP link and vice versa.


6.  BT-LE network connectivity scenarios

   In many applications, the BT-LE network will be connected to the
   Internet.  In this case, the master/6LBR has at least one non-BT-LE
   interface connected to the Internet.








Nieminen, et al.        Expires October 22, 2011                [Page 6]


Internet-Draft               IPv6 over BT-LE                  April 2011


                        h           ____________
                         \         /            \
                   h ---- 6LBR --- |  Internet  |
                         /         \____________/
                        h
                                           h:      host
                 <-- BT-LE -->             6LBR:   6LoWPAN Border Router


             Figure 3: BT-LE network connected to the Internet

   6to4 and 6RD are possibilities when the 6LBR has only IPv4 uplink
   connectivity.  The 6LBR would act as 6to4/6RD router and advertise
   6to4/6RD prefix into the BT-LE network.  The 6to4 prefix is
   constructed by combining well-known IPv6 prefix with public IPv4
   address.  The 6RD prefix is constructed by combining network specific
   IPv6 prefix with public or private IPv4 addresses.  These
   technologies require the 6LBR device to perform IPv6 into IPv4
   encapsulation, and in particular in 6RD case also require tunnel
   endpoint in the access network.

   If the 6LBR has no IPv6 uplink Internet connectivity available via
   any of the abovementioned means, the 6LBR may employ IPv6 to IPv4
   protocol translation technology.  This allows BT-LE nodes to connect
   to Internet destinations as long as the destination has globally
   reachable IPv4 address.  The BT-LE network would be numbered with ULA
   addresses, which IPv6 stacks on BT-LE nodes would consider as global
   addresses.

   In some scenarios, the BT-LE network may transiently or permanently
   be an isolated network.


                        h       h           h:     host
                         \     /            6LBR:  6LoWPAN Border Router
                    h --- 6LBR -- h
                         /    \
                        h      h


                     Figure 4: Isolated BT-LE network


7.  Addressing Model

   The link model of BT-LE needs to be considered and what kind of
   addressing is possible.




Nieminen, et al.        Expires October 22, 2011                [Page 7]


Internet-Draft               IPv6 over BT-LE                  April 2011


8.  MTU Issues

   Generally the sensors generate data that fits into one Link Layer
   packet (23 bytes) that is transferred to the collector periodically.
   IP data packets may be much larger and hence MTU size should be the
   size of the IP data packet.  Larger L2CAP packets can be transferred
   with the Segmentation And Reassembly (SAR) feature of the Link Layer.
   If an implementation cannot support the larger MTU size (due to cost)
   then SAR MUST be supported at upper layers.

   Existing SAR functionality defined in [RFC4944] MAY also be used,
   taking into account BT-LE specific features such as different MTU in
   the L2CAP layer.


9.  LoWPAN Adaptation for BT-LE and frame format

   Transmission of IPv6 Packets over IEEE 802.15.4 Networks [RFC4944]
   defines an adaptation layer between IP and 802.15.4 radio networks.
   In these networks link layer does not support SAR functionality and
   thus IP packets must fit into the payload that is available in the
   127 octect long physical frame after variable size frame overhead has
   been added.  In BT-LE networks this kind of adaptation is not
   required if SAR is supported in the Link Layer.


10.  IPv6 Address configuration

   The Interface Identifier for a BT-LE interface MAY be formed from the
   48-bit public device Bluetooth address as per the "IPv6 over
   Ethernet" specification [RFC2464].

   An IPv6 prefix used for stateless autoconfiguration [RFC4862] of a
   BT-LE interface MUST have a length of 64 bits.

   SLAAC and other means to configure an address on a BT-LE device.
   Neighbor Discovery Optimization for Low-power and Lossy Networks
   [I-D.ietf-6lowpan-nd].  Well-known gateway or server addresses can be
   hard-coded in the sensors.


11.  IPv6 LLA in BLE

   The IPv6 link-local address [RFC4291] for a BT-LE interface is formed
   by appending the Interface Identifier, as defined above, to the
   prefix FE80::/64.





Nieminen, et al.        Expires October 22, 2011                [Page 8]


Internet-Draft               IPv6 over BT-LE                  April 2011


                  10 bits        54 bits             64 bits
                +----------+-----------------+----------------------+
                |1111111010|       zeros     | Interface Identifier |
                +----------+-----------------+----------------------+



                Figure 5: IPv6 link-local address in BT-LE


12.  Unicast and Multicast address mapping

   Reuse the same format specified for 802.15.4?


13.  Header compression

   Compression Format for IPv6 Datagrams in Low Power and Lossy Networks
   (6LoWPAN) [I-D.ietf-6lowpan-hc] is the basis of the IPv6 header
   compression mechanism defined in this specification.  Whereas
   [I-D.ietf-6lowpan-hc] exploits intra-packet redundancies due to the
   formation of Interface Identifiers from MAC addresses, BT-LE data
   channel PDUs include neither source nor destination MAC addresses.
   Instead, BT-LE Link Layer packets include the Access Address, a 32-
   bit value that identifies a Link Layer connection between a master
   and a slave.  In consequence, the Interface Identifier compression
   mechanisms used in this specification are different from those used
   in [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
   BT-LE context latest version of LoWPAN compressed IPv6 header SHOULD
   be used by default.  Support for fragmentation and mesh headers MAY
   be added.  However, since BT-LE operates on a star topology, mesh
   headers SHOULD not be required.  In BT-LE link with header
   compression IPv6 header (originally 40 Bytes) can be compressed to
   only 2 Bytes with link-local addresses and 26 Bytes with Global
   addresses.  UDP header (originally 8 Bytes) can be compressed to 4
   Bytes.

   This specification assumes that the following will be the common case
   when using IPv6 on top of BT-LE networks: Version is 6; Traffic Class
   and Flow Label are both zero; Payload Length can be inferred from
   lower layers from either the 6LoWPAN Fragmentation header or the
   BT-LE Link Layer header; Hop Limit will be set to a well-known value
   by the source; IPv6 addresses assigned to BT-LE interfaces will be
   formed using the link-local prefix or a small set of routable
   prefixes assigned to the entire BT-LE network.



Nieminen, et al.        Expires October 22, 2011                [Page 9]


Internet-Draft               IPv6 over BT-LE                  April 2011


   In a link-local communication, the IPv6 destination address can be
   elided.  In fact, the node that receives a data channel PDU through a
   Link Layer connection can infer that the IPv6 destination address of
   the packet is its own IPv6 address.  If a node knows the IPv6 address
   of the other endpoint of the Link Layer connection, the IPv6 source
   address can also be elided.  The mechanism by which a node learns the
   IPv6 link-local address (or the Interface Identifier) of the other
   endpoint of the connection is TBD.

   When a BT-LE slave transmits an IPv6 packet to a remote destination
   using global IPv6 addresses, the slave can elide the IPv6 source
   address.  This is possible if the following two conditions are met:
   1) the master/6LBR can derive the prefix of the source IPv6 address
   from a context shared with the slaves; and 2) the master/6LBR
   maintains a table that relates the Access Address of each Link Layer
   connection and the Interface Identifier of the corresponding slave.
   The mechanism by which the master/6LBR maintains the above mentioned
   table is TBD.  The slave can also elide the prefix of the destination
   IPv6 address if a context is defined for the IPv6 destination
   address.

   When a master/6LBR receives an IPv6 packet sent by a remote node
   outside the BT-LE network, and the destination of the packet is a
   slave, the master/6LBR can elide the Interface Identifier of the IPv6
   destination address by exploiting the information contained in the
   table mentioned above.  The prefixes of the IPv6 destination and
   source addresses can also be elided if a context is defined for them.

   Some parts of the base HC encoding may need to be modified/redefined
   in order to enable the new functionality described herein.  TBD in
   future versions.

   In a link-local communication, the IPv6 header can be compressed down
   to 2 bytes in the best case.


14.  IANA Considerations

   This document does not have any IANA requests at this time.  This may
   change with further development of the specification.


15.  Security Considerations

   The transmission of IPv6 over bluetooth low energy links has similar
   requirements and concerns for security as ZigBee.  Security at the IP
   layer needs to be reviewed as part of the development of the IPv6
   over Bluetooth Low Energy specification.



Nieminen, et al.        Expires October 22, 2011               [Page 10]


Internet-Draft               IPv6 over BT-LE                  April 2011


   BT-LE Link Layer supports encryption and authentication by using the
   CCM mechanism and a 128-bit AES block cipher.  Upper layer security
   mechanisms may exploit this functionality when it is available.
   (Note: CCM does not consume bytes from the maximum per-packet L2CAP
   data size, since the link layer data unit has a specific field for
   them when they are used.)

   Key management in BT-LE is provided by the Security Manager Protocol
   (SMP).


16.  Additional contributors

   Kanji Kerai and Jari Mutikainen from Nokia have contributed
   significantly to this document.


17.  Normative References

   [I-D.ietf-6lowpan-hc]
              Hui, J. and P. Thubert, "Compression Format for IPv6
              Datagrams in Low Power and Lossy Networks (6LoWPAN)",
              draft-ietf-6lowpan-hc-15 (work in progress),
              February 2011.

   [I-D.ietf-6lowpan-nd]
              Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
              Discovery Optimization for Low-power and Lossy Networks",
              draft-ietf-6lowpan-nd-15 (work in progress),
              December 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, December 1998.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

   [RFC4994]  Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski,



Nieminen, et al.        Expires October 22, 2011               [Page 11]


Internet-Draft               IPv6 over BT-LE                  April 2011


              "DHCPv6 Relay Agent Echo Request Option", RFC 4994,
              September 2007.


Appendix A.  Bluetooth Low Energy basics

   This section will provide background material on the basics of
   bluetooth low energy.


Authors' Addresses

   Johanna Nieminen (editor)
   Nokia
   Itaemerenkatu 11-13
   FI-00180 Helsinki
   Finland

   Email: johanna.1.nieminen@nokia.com


   Basavaraj Patil
   Nokia
   6021 Connection drive
   Irving, TX  75039
   USA

   Email: basavaraj.patil@nokia.com


   Teemu Savolainen
   Nokia
   Hermiankatu 12 D
   FI-33720 Tampere
   Finland

   Email: teemu.savolainen@nokia.com


   Markus Isomaki
   Nokia
   Keilalahdentie 2-4
   FI-02150 Espoo
   Finland

   Email: markus.isomaki@nokia.com





Nieminen, et al.        Expires October 22, 2011               [Page 12]


Internet-Draft               IPv6 over BT-LE                  April 2011


   Zach Shelby
   Sensinode
   Hallituskatu 13-17D
   FI-90100 Oulu
   Finland

   Email: zach.shelby@sensinode.com


   Carles Gomez
   Universitat Politecnica de Catalunya/i2CAT
   C/Esteve Terradas, 7
   Castelldefels  08860
   Spain

   Email: carlesgo@entel.upc.edu



































Nieminen, et al.        Expires October 22, 2011               [Page 13]


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