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

Versions: 00 01

Internet-Engineering Task Force                     Kulwinder Atwal/
Draft                                               Zucotto Wireless
draft-akers-atwal-btooth-00.txt                           Ron Akers/
February 20, 2001                                      Motorola Labs
Expires: August, 2001




          Transmission of IP Packets over Bluetooth Networks

STATUS OF THIS MEMO

     This document is an Internet-Draft and is in full conformance
     with all provisions of Section 10 of RFC2026.

     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.


Abstract

     Bluetooth is a wireless standard for low cost, low power, short-
range radio communications.  This document describes some issues and
goals for IPv4/IPv6, header compression, Real-Time Streaming, IP
Multicast, IPSec, QoS, end-to-end IP network design, and Link-Layer
features that are candidates for use in an IP over Bluetooth solution,
and discusses how it differs from current approaches.








R. Akers, K. Atwal                                            [Page i]


Internet Draft                  Bluetooth IP           February 20, 2001

                           TABLE OF CONTENTS
                           -----------------

1.      INTRODUCTION............................................1
2.      ISSUES AND GOALS........................................1
2.1     IPv6....................................................1
2.2     Header Compression......................................1
2.3     Real-Time Streaming.....................................1
2.4     IP Security (IPSEC).....................................2
2.5     Quality of Service......................................2
2.6     End-to-end IP Network Design............................2
3.      REFERENCE BLUETOOTH IP ARCHITECTURES....................2
3.1     Reference Piconet IP Architecture.......................2
3.2     Reference Scatternet IP Architecture....................4
4.      SOLUTIONS FOR IP OVER BLUETOOTH.........................5
4.1     Current BT SIG Solution for IP over Bluetooth...........5
4.2     Solution for IP under development by Bluetooth SIG......7
4.3     Possible Solutions for consideration by the IETF........7
4.3.1   Solution 1..............................................7
4.3.2   Solution 2..............................................8
4.3.2   Solution 3..............................................8
5.      POSSIBLE CANDIDATES FOR USE AS A BEARER FOR IP..........9
5.1.    Bluetooth Network Layer (L2CAP).........................9
5.1.1   Connection-Oriented Data Channel........................9
5.1.2   Connectionless Data Channel.............................9
5.1.3   Signalling Channel.....................................10
5.2.    Host Controller (MAC) Layer............................10
5.2.1   Connection-Oriented Data (ACL).........................10
5.2.2   Connectionless Data (SCO)..............................11
5.2.3   Host Controller Command Packet.........................11
5.2.4   Host Controller Event Packet...........................11
6.      GLOSSARY OF TERMS......................................12
7.      Authors Addresses......................................14
8.      REFERENCES.............................................14


















R. Akers, K. Atwal                                            [Page ii]


Internet Draft                  Bluetooth IP           February 20, 2001

1. INTRODUCTION

     Bluetooth is a standard for low cost, low power, short-range radio
communications.  This RFC describes some of the issues and goals
that we feel should be considered in the design of IP networking for
Bluetooth wireless devices.

Typical IP based technology that we intend to discuss includes IPv4/IPv6,
header compression, Real-Time Streaming, IP Multicast, IPSec, QoS,
end-to-end IP network design, and Link-Layer features.

We also will discuss the current standard for IP over Bluetooth that is
described in published specifications from Bluetooth SIG, and we will
describe our understanding of future SIG designs.  Finally we propose a
set of possible designs that the IETF could pursue.


2. ISSUES AND GOALS

2.1 IPv6:

  Since Bluetooth proliferation is expected to be several hundred million
devices per year, the fast depletion of IPv4 addresses must be
considered a serious issue for the long term success of Bluetooth IP
devices and the end-to-end IP network.  Since any electrical device, or
appliance can be a Bluetooth IP device, it is expected that migration to
IPv6 will be a serious concern.  A goal will be to consider the issues,
time lines, and benefits involved in moving Bluetooth to IPv6, and how
Bluetooth will accelerate the move to IPv6 for the global IP network.


2.2 Header Compression:

  Since Bluetooth is currently a bandwidth limited medium for IPv6,
header compression is an issue.  A goal will be to consider the issues,
and concerns involved in IP using IETF header compression like ROHC.


2.3 Real-Time Streaming:

  Since many real-time streaming applications require IP Multicast, IP
Multicast is an issue for the widespread acceptance of Bluetooth IP
devices.  Also, the appropriate Transport Layer protocols will be
discussed as candidates for mobile wireless Real-Time Streaming.  A
goal will be to consider the issues, and benefits involved in Bluetooth
IP Multicast, UDP, TCP, and SCTP.






R. Akers, K. Atwal                                            [Page 1]


Internet Draft                  Bluetooth IP           February 20, 2001

2.4 IP Security (IPSEC):

  Since the Bluetooth Host Controller employs SAFER+ (128-bit)
encryption,as well as providing for external encryption methods for
secure transactions, security is a serious issue.   A goal will be to
consider the issues, and concerns involved in providing IPSEC for IP
over Bluetooth.


2.5 Quality of Service:

  Since the Bluetooth Host Controller employs QoS based on IETF
RFC 1363, providing IP with QoS is an issue. A goal will be to consider
the issues, and concerns involved in providing QoS for IP over a mobile
wireless link.


2.6 End-to-end IP Network Design:

  Since the growth and use of Bluetooth IP devices is expected to place
a significant load on the global IP network, determining design
guidelines for an IP solution is an issue.  A goal will be to consider
the mobile wireless issues, and concerns involved in providing an
end-to-end IP network solution.


3. REFERENCE BLUETOOTH IP ARCHITECTURES

   Bluetooth devices communicate on a Master-Slave Frequency Hopping
Radio network operating within the 2.4-2.5 Giga-Hertz radio spectrum.

3.1 Reference Piconet IP Architecture:

  A Bluetooth Piconet can be formed between any two Bluetooth devices
engaging in a RF discovery procedure.  The discovered device becomes
a "Slave" device, while the discoverer becomes the "Master".

                          +------+
                          |      |
                          |Master|
                          |      |
                          +------+
                             |
                             |
                          +-----+
                          |     |
                          |Slave|
                          |     |
                          +-----+

     Figure 3.1.1 - A simple Master-Slave Bluetooth Piconet

R. Akers, K. Atwal                                            [Page 2]


Internet Draft                  Bluetooth IP           February 20, 2001




                   +------+
                   |      |
                   |Master|
                   |      |
                   +------+
                    | | | |
         +----------+ | | +--------------------+ - - - - - -+
         |            | +---------+            |
         |            |           |            |            |
         |            |           |            |
         V            |           |            |            |
      +-----+      +-----+     +-----+      +-----+    +--------+
      |     |      |     |     |     |      |     |    | Parked |
      |Slave|      |Slave|     |Slave| o o o|Slave|    | Slaves |
      |  1  |      |  2  |     |  3  |      |  7  |    | 8-255  |
      +-----+      +-----+     +-----+      +-----+    +--------+

     Figure 3.1.2 - Single Bluetooth Piconet with multiple Slaves

   A Master Bluetooth node can have up to seven active slaves associated
to it at any one time. There can also be a number of "parked" slaves
associated with the Master at the same time. When a slave is in the
parked state it is not participating in normal communications. A Slave
can request to be "parked", or "un-parked".  Also, a Master can "park"
any of its active nodes, and "un-park" any of it's parked nodes.
























R. Akers, K. Atwal                                            [Page 3]


Internet Draft                  Bluetooth IP           February 20, 2001

3.2 Reference Scatternet IP Architecture:

   A Bluetooth Piconet can be formed between any two devices engaging in
a discovery procedure.  The discovered device becomes the Slave device,
while the discoverer becomes the Master.  A Scatternet can be formed
between at least three devices, where at least one device is able to
switch between the hopping sequences of the other two devices.

                                 +------+
                                 |      |
                                 |Master|
                                 |      |
                                 +------+
                                  |    |
                       +----------+    |
                       |               |
                       |               +-----+
                       |                     |
                   +-------+               +-------+
                   |Slave 1|               |       |
                   |\Master|               |Slave 2|
                   |       |               |       |
                   +------ +               +-------+
                    | | |
         +----------+ | +---------+
         |            |           |
         |            |           |
         |            |           |
      +-----+      +-----+     +-----+
      |     |      |     |     |     |
      |Slave|      |Slave|     |Slave|
      |  1  |      |  2  |     |  3  |
      +-----+      +-----+     +-----+

    Figure 3.2.1 - A Bluetooth Scatternet made up of two Piconets
              by a "Bridging" Master/Slave node

   The Bluetooth node "Slave 1" is member of the upper Bluetooth Piconet.
The node is also a Master node in the lower Bluetooth Piconet.  In this
way a series of Bluetooth nodes can become a multiple-hop wireless network.












R. Akers, K. Atwal                                            [Page 4]


Internet Draft                  Bluetooth IP           February 20, 2001





                   +-------+               +-------+
                   |Piconet|               |Piconet|
                   |   A   |               |   B   |
                   |Master |               |Master |
                   +-------+               +-------+
                    | | |                     |
         +----------+ | +---------+  +--------+
         |            |           |  |
         |            |           |  |
      +-----+      +-----+      +-----+
      |     |      |     |      |     |
      |Slave|      |Slave|      |Slave|
      | 1A  |      | 2A  |      |3A/1B|
      +-----+      +-----+      +-----+

     Figure 3.2.2 - A Bluetooth Scatternet made up of two Piconets
                     by a "Bridging" Slave node




4. SOLUTIONS FOR IP OVER BLUETOOTH

4.1 Current Solution for IP over Bluetooth

  The current IP over Bluetooth solution known as the LAN Profile [1] is
a legacy solution designed for backward compatibility based on the
serial cable replacement protocol RFCOMM [2].  The LAN Profile is a
protocol stack composed of IP, PPP(IETF), RFCOMM, L2CAP, over the
Host Controller:

 +-------+              +----------------------------+
 |  IP   |              |   PPP Networking           |
 +------------+         |----------------------------+
 |   P P P    |         |   PPP       |      |       |
 +------------+         +-------------+      |   L   |
 |SDP |RFCOMM |         |SDP| RFCOMM  |      |       |
 +----+-------+         +-------------+      |   A   |
 |    L2CAP   |         |   L2CAP     |      |       |
 +------------+         +-------------+      |   N   |
 | Host Cont. |         | Host Cont.  |      |       |
 +------------+         +-------------+      +-------+
  Mobile Node              LAN Access Point

    Figure 4.1.1 - Bluetooth Version 1.0 Protocol Stack for
                          IP networking


R. Akers, K. Atwal                                            [Page 5]


Internet Draft                  Bluetooth IP           February 20, 2001



  Shown in Figure 4.1.2 is a typical use of the LAN Profile. In this
network, one node is directly connected to an IP-based wired network.
This node is usually named an Access Point (AP), and it is conected to
up to seven active client nodes via the wireless Bluetooth link layer:





                   INTERNET
                      |
                      |
                      |
                   +------+
                   |  AP  |
                   |      |
                   |Master|
                   +------+
                    | | | |
         +----------+ | | +--------------------+ - - - - - -+
         |            | +---------+            |
         |            |           |            |            |
        PPP          PPP         PPP          PPP
         |            |           |            |            |
      +-----+      +-----+     +-----+      +-----+    +--------+
      |     |      |     |     |     |      |     |    | Parked |
      |Slave|      |Slave|     |Slave| o o o|Slave|    | Slaves |
      |  1  |      |  2  |     |  3  |      |  7  |    | 8-255  |
      +-----+      +-----+     +-----+      +-----+    +--------+

     Figure 4.1.2 - Bluetooth Version 1.0 Protocol Stack for
                          IP networking



  The IETF PPP protocol is used exclusively to transport IP traffic
to and from the clients to the AP and out to the wired network. While
this design is basically effective, all the limiting problems of running
a network over serial PPP link are evident.  Moreover PPP is not
sufficient for ad-hoc networks that contain multiple wireless hops.










R. Akers, K. Atwal                                            [Page 6]


Internet Draft                  Bluetooth IP           February 20, 2001

4.2 Solution for IP under development by Bluetooth SIG:

  The solution under development by the Bluetooth SIG is known as the
PAN profile [3], but little has been published other than it will run
Ethernet over the Bluetooth Network Layer (L2CAP) with some compression:


                           +----+-------+
                           |    |  IP   |
                           +SDP |-------+
                           |    | BNEP  |
                           +----+-------+
                           |    L2CAP   |
                           +------------+
                           | Host Cont. |
                           +------------+


    Figure 4.2.1 - Proposed Bluetooth Protocol Stack for
                            IP networking


4.3 Possible Solutions for consideration by the IETF:

4.3.1 Solution 1

  The IETF may consider to run IP over modified L2CAP with, or without
compression:

                           +-----+------+
                           | SLP |      |
                           +-----+      +
                           |     IP     |
                           +------------+
                           |    ROHC(?) |
                           +------------+
                           |   L2CAP(M) |
                           +------------+
                           | Host Cont. |
                           +------------+

    Figure 4.3.1.1 - 1st. Possible Bluetooth Protocol Stack for
                            IP networking

   In the above stack notice that we are proposing that the IETF
Service Location Protocol (SLP)- or a modified version of it-  be used
as a replacement for the SDP protocol.





R. Akers, K. Atwal                                            [Page 7]


Internet Draft                  Bluetooth IP           February 20, 2001



4.3.2 Solution 2


   The IETF may consider to run IP and L2CAP over the Host Controller
with a new protocol:

                           +------------+
                           |  IP | L2CAP|
                           +------------+
                           |Foo Protocol|
                           +------------+
                           | Host Cont. |
                           +------------+

    Figure 4.3.2.1 - 2nd Possible Bluetooth Protocol Stack for
                            IP networking



4.3.2 Solution 3

  The IETF may consider to run L2CAP over IP over the Host Controller
with a new protocol:




                           +------------+
                           |    L2CAP   |
                           +------------+
                           |     IP     |
                           +------------+
                           | Foo2 Proto.|
                           +------------+
                           | Host Cont. |
                           +------------+


    Figure 4.3.3 - 3rd. Possible Bluetooth Protocol Stack for
                            IP networking



  These are some possible solutions, however there probably are many
others that should be considered and compared to the solutions that have
been presented in this document.




R. Akers, K. Atwal                                            [Page 8]


Internet Draft                  Bluetooth IP           February 20, 2001


5. POSSIBLE CANDIDATES FOR USE AS A BEARER FOR IP


5.1. Bluetooth Network Layer (L2CAP)


5.1.1 Connection-Oriented Data Channel:

+---------------------------------------------------------------+
|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|
+---------------------------------------------------------------+
| Length                        |  Channel ID                   |                                                               |
+---------------------------------------------------------------+
|                                                               |
|                          Payload                              |
|                                                               |
+---------------------------------------------------------------+
LSB                                                          MSB

        Length (16 bits): Length of Payload in Bytes.

        Channel ID (16 bits): Logical Device Address

        Payload (1 to 65535 bytes): Packet Data.



5.1.2  Connectionless Data Channel:

+---------------------------------------------------------------+
|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|
+---------------------------------------------------------------+
| Length                        | Channel ID (0x0002)           |
|---------------------------------------------------------------|
| Protocol/Service Multiplexer  | Payload                       |
+---------------------------------------------------------------+
LSB                                                          MSB

    Length (16 bits): Length of Payload in Bytes.

    Channel ID (0x0002): Logical Device Address 0x0002 is
                         reserved for Connectionless data.

    Protocol/Service Multiplexer(PSM): Similiar to the Protocol field
                                       in IP protocol headers.

    Payload (1 to 65535 bytes): Packet Data.




R. Akers, K. Atwal                                            [Page 9]


Internet Draft                  Bluetooth IP           February 20, 2001


5.1.3 Signalling Channel:

+---------------------------------------------------------------+
|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|
|---------------------------------------------------------------|
|       Length                  |    Channel ID (0x0001)        |
|---------------------------------------------------------------|
|                             Commands                          |
|                                                               |
+---------------------------------------------------------------+
LSB                                                           MSB

     Length (16 bits): Length of Payload in Bytes.

     Channel ID (0x0001): Logical Device Address 0x0001 is
                          reserved for Signalling.

     Commands (1 to 65535 bytes): One, or more commands.


5.2. Host Controller (MAC) Layer

5.2.1  Asynchronous Connection Link  (ACL):

+---------------------------------------------------------------+
|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|
|---------------------------------------------------------------|
|   Connnection Handle  |PB |BC |          Length               |
|---------------------------------------------------------------|
|                                                               |
|                                                               |
|                           Payload                             |
|                                                               |
+---------------------------------------------------------------+
LSB                                                           MSB

    Connection Handle (12 bits): Logical Device Address.

    PB (2 bits): Packet Boundary Flag.

    BC (2 bits): BroadCast Flag.

    Length (16 bits): Length of Payload in Bytes.

    Payload (1 to 65535 bytes): Packet Data.






R. Akers, K. Atwal                                            [Page 10]


Internet Draft                  Bluetooth IP           February 20, 2001


5.2.2 Synchronous Connection-Oriented Link (SCO):

+---------------------------------------------------------------+
|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|
|---------------------------------------------------------------|
|Connnection Handle     | Rsvd  |      Length    |  Payload     |
|---------------------------------------------------------------|
|                        Payload (cont)                         |
+---------------------------------------------------------------+
LSB                                                           MSB

    Connection Handle (12 bits): Logical Device Address.

    Rsvd (4 bits): Reserved.

    Length (8 bits): Length of Payload in Bytes.

    Payload (1 to 65535 bytes): Packet Data.


5.2.3 Host Controller Command Packet:

|---------------------------------------------------------------|
|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|
|---------------------------------------------------------------|
| Opcode              | Length |       Parameter(s)             |
|---------------------------------------------------------------|
LSB                                                           MSB

    Opcode (16 bits): Host Controller Command code.

    Length (8 bits): Length of Payload in Bytes.

    Parameters (0 to 65535 bytes): Zero, or more command parameters.


5.2.4 Host Controller Event Packet:

|---------------------------------------------------------------|
|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|
|---------------------------------------------------------------|
|  Event Code   | Length   |          Parameter(s)              |
|---------------------------------------------------------------|
LSB                                                           MSB

   Event Code (8 bits): Host Controller Event code.

   Length (8 bits): Length of Payload in Bytes.

   Parameters (1 to 65535 bytes): One or more Event Parameters.

R. Akers, K. Atwal                                            [Page 11]


Internet Draft                  Bluetooth IP           February 20, 2001


6. GLOSSARY OF TERMS

Active Member(AM):
A device with a valid active Link.

AM_ADDR:
A 3-bit physical address assigned by the Master to a Slave device during
connection setup.

Access Point(AP):
A wireless node that directly connects to a wireline network, and
provides network access to other wireless nodes that are associated
to the AP. Typically, the wireline network is the INTERNET or an IP
based Intranet.

Baseband:
A Physical Layer Device (PHY2).

BD_ADDR:
A 48-bit physical address used by a Bluetooth device for discovery
and connection setup.

Bluetooth Radio:
A Radio Interface (PHY1).

Connection Handle:
A 12-bit logical address assigned to a physical link by the Host
Controller.

Frequency-Hopping Radio:
A radio that uses a Frequency Hopping Sequence for communications.

Frequency-Hopping Sequence:
A set of radio frequencies that are selected in pseudo-random order to
tune a radio to a new frequency once per Slot-Time.

Host Controller:
A controller consisting of the MAC(MAC1 + MAC2) and PHY(PHY1 + PHY2).

Host Controller Interface:
An API provided by the Host Controller Driver.

IP:
Internet Protocol

L2CAP:
Logical Link Control and Adaptation Protocol



R. Akers, K. Atwal                                            [Page 12]


Internet Draft                  Bluetooth IP           February 20, 2001

Link Controller:
A lower Link Layer Controller (MAC1)

Link Manager:
A upper Link Layer Controller (MAC2).

Master Device(MD):
The device delegated as the router on a Piconet.

Master-Slave Network:
A network where a single device is delegated the Master, and all other
devices assume the role of Slave devices.  A Master must poll a Slave
device by addressing a packet to a Slave device, before a Slave device
can transmit.  All communications are either Master to Slave,or Slave to
Master.  Since all communications in a Master-Slave Network are between
the Master and a Slave, the Master is effectively the router.  A Master-
Slave Network must have one and only one Master device.  A Master-Slave
network may have broadcast capabilities.

Master/Slave Slot-Pair:
The smallest integral unit of transmission composed of a Master device
Slot-Time followed immediately by a Slave device Slot-Time

Parked Member(PM):
A device with a valid dormant link.

Piconet:
Two or more Bluetooth devices linked on the same Frequency-Hopping
Sequence.

Piconet Active Member Broadcast:
A packet addressed to be received by all Active Members.

Piconet Broadcast:
A packet addressed to be received by all Active and Parked Members.

PM_ADDR:
A 8-bit physical address assigned by the Master to a Parked Slave
device.

PPP:
IETF Point to Point Protocol

RFCOMM:
Serial port emulation protocol

Scatternet:
Three or more Bluetooth devices linked on at least two Frequency-Hopping
Sequences.  A device may be a slave on all sequences, or a master on one
and a slave on the other.


R. Akers, K. Atwal                                            [Page 13]


Internet Draft                  Bluetooth IP           February 20, 2001

SDP:
Bluetooth Service Discovery Protocol

Slave Device(SD):
A device not acting as a router on a Piconet.

Slot-Time:
A fixed interval of time specifying the duration that a radio will spend
tuned to one frequency before tuning to a new frequency. For Bluetooth
this is 625 microseconds with a clock jitter of -/+ of 10 microseconds
and a clock drift rate of 20 parts per million.

Un-discovered Device(UD):
A device that has not been discovered.


7. Authors Addresses


Ronald G. Akers
Motorola Laboratories
1301 Algonquin Rd.
Schaumburg IL. 60196
ron.akers@motorola.com

Kulwinder S. Atwal
Zucotto Wireless
130 Slater St.
Ottawa, Ontario, Canada
kulwinder.atwal@zucotto.com



8. REFERENCES

    [1] Specification of the Bluetooth System Profiles Verbsion 1.0.
(http://www.bluetooth.com/developer/specification/specification.asp)

    [2] Specification of the Bluetooth System Core Version 1.0.
(http://www.bluetooth.com/developer/specification/specification.asp)

    [3] Bluetooth SIG Working Group Charters
(http://www.bluetooth.com/sig/sig/sig.asp)









R. Akers, K. Atwal                                            [Page 14]

Internet Draft                  Bluetooth IP           February 20, 2001


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