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