Minutes for Bluetooth over IP BOF session 09:00 - 11:30, Monday, July 31 2000 48th IETF Meeting, Pittsburgh, Pennsylvania, 30th July - 4th August 2000 CHAIRS: Pravin Bhagwat Kris Fleming Minutes by Sander van Valkenburg, Nokia. Agenda: 1) BOF Objectives (chairs) 2) Bluetooth SIG overview (Kris Fleming) 3) Bluetooth technology overview (Pravin Bhagwat) 4) Bluetooth scatternets (Per Johansson) 5) TCP/IP support in Bluetooth version 1.0 (Johan Sörensen) 6) IP over Bluetooth design issues (Kris Fleming) 7) Agree on next steps 8) Questions 9) Closing -------------------- Kris Fleming (Intel) presented an introduction to Bluetooth and the Bluetooth SIG, talking about the standardization effort resulting into Bluetooth 1.0 specifications, structure of the Bluetooth Special Interest Group (SIG), different types of SIG membership, and the different working groups, that are currently involved in standardization. Pravin Bhagwat (AT&T Labs) presented an overview of the Bluetooth specifications (version 1.0b), in order to explain the different design issues with IP over Bluetooth. * Target of Bluetooth: low-cost low-power radio interface. It is not competing with WLAN. The main (initial) use is cable replacement - non-IP applications. Initially LAN Access and later ad hoc networking (and improved LAN Access)- are area's where IP can be used. * Overview of Bluetooth specifications, first the Bluetooth stack is introduced. RF, Baseband (equivalent to Physical Layer), Audio and Link Manager (equivalent to (partial) MAC Layer) reside on a single chip, making it a unique technology. The layer above that, L2CAP (equivalent to (partial) MAC layer) provides segmentation and reassembly as well as protocol multiplexing. Multiplexed protocols are SDP (Service Discovery Protocol), RFCOMM, IP, and there is also a control channel (HCI, Host Control Interface). * Radio link characteristics: fast frequency hopping, GPSK modulation, 1 Mbit symbol rate, 0dBm transmission power. Links are point-to-point, constituting a master - slave relationship, for synchronizing the hopping sequence. Every master can support up to seven active slaves. The set of one master and connected slaves is called 'piconet'. Different address types: 48-bit BD_ADDR (hardware address), 3-bit AM_ADDR (for addressing active slaves in a piconet) and 8-bit addresses (for addressing parked (sleeping) slaves in a piconet). Small Baseband packets present a difficulty for IP, but there are multi-slot packets. The physical link allows for mixing both synchronous and asynchronous links. * Link Manager protocol serves for link set-up and control, and it includes (CHAP-like) security. * L2CAP (Logical Link Control and Adaptation Protocol) serves segmentation and reassembly, protocol multiplexing and QoS setup, for asynchronous data traffic. S&R assume reliable in-order delivery by the lower layer. The master-slave abstraction does not exist anymore at L2CAP level. Different upper-layer connections between devices are represented by logical channels, identified by a Channel ID (CID). * SDP (Service Discovery Protocol) is an efficient, small, non-IP service discovery protocol. * Serial port emulation (RFCOMM) serves legacy applications. It will disappear in the long term (Pravin's opinion). Questions about reliability, transmission power, high-power mode. Question: What is the size of channel ID space? Answer: 16 bit. Q: Can you establish different CIDs for different flows within IP? A: Theoretically, yes; this is not done in Bluetooth 1.0. Q: Do channels have fixed bandwidth? A: No, a channel is just a logical L2CAP connection. Q: There is an integrity check (CRC) per fragment, how does it cope with fragment-loss? A: An ARQ scheme with window size of 1 is used. Q: L2CAP is best effort, but operates on top of a reliable Baseband, so where is the loss? A: L2CAP is best effort in the sense that it will not retransmit packets. Q: What is L2CAP MTU? A: MTU is minimum 48 bytes - 64k bytes. The current recommendation is 1500 bytes. Q: What is the cost of keeping RFCOMM? Q: Are there other competing low-cost low-power designs that allow IP straight? A: Possibly. Presentation by Per Johansson (Ericsson) about scatternets. * A scatternet is an inter-connected piconet. It adds more capacity and provides flexibility. Nodes that are present in multiple piconets require time scheduling between the frequency hopping patterns of different piconets. Q: is this in the current specs? A: Now you can be part of different piconets, but does not describe how to do it. Q: Does it compromise reliability? A: Maybe in the nodes that bridge between piconets. Q: Multiple piconets allow for higher bandwidths? A: Yes, but there will be some additional interference. Q: Do you need an inter-network protocol? A: There are no multiple technologies, so by definition not. Johan Sörensen (Ericsson) presented the Bluetooth 1.0 Dial-up networking LAN Access profile. This is a profile, which is a tool to provide interoperability. * The Dial-up Networking profile as well as the LAN Access profile serve cable replacement, using PPP over RFCOMM. * Other possibilities were IP over L2CAP, Ethernet encapsulation and PPP without HDLC framing. They could not be considered within the available timeframe. Q: LAN access includes connection establishment? A: Yes. Q: Is IP directly over Bluetooth possible? A: Yes, but it is not in a standard (yet). Q: Does each piconet operate under one profile? A: No, profiles represent different applications, and they can run over the same link. Q: Different CIDs for different profiles? A: Yes, a CID represents a logical L2CAP channel, a profile describes the interactions between nodes, using different protocols, in order to assure interoperability. Q: Does the PPP server also provide address assignment? A: Yes. This is not the best solution for ad hoc networking. Q: Having different profiles, does this produce non-interoperability? A: A user scenario has one associated profile, so interoperability for such a scenario is ensured by the corresponding profile. Q: Are there profile IDs? A: Profiles are not interesting at run-time level. Profiles are advertised in a service record. There are no profile IDs. Q: Is there a management protocol? A: No. Q: Does PPP on top of RFCOMM introduce more legacy? A: (Possibly) Yes. Kris Fleming (Intel) presented IP over Bluetooth design issues and an overview of the Bluetooth Personal Area Networking (PAN working group. * PAN goals are multi-user collaboration, ad-hoc networking and the provision of security (in a user-friendly way). * The profile must enable IP (IPv4 and IPv6). * Support (small-scale) ad hoc networking, without infrastructure. However, special purpose products can enhance ad hoc networking (such as Data Access Points, Personal Conference Hub, Bluetooth enabled Phone as Data Access Point). * The size of ad hoc networks should be somehow limited to N hops. The solution must be backward compatibility with Bluetooth version 1.0 (for future version 2.0 devices). * Ethernet emulation is one possibility. Ethernet frames are encapsulated in L2CAP, hiding the Bluetooth characteristics from the IP layer. * Another possibility is to send IP packets directly over Bluetooth, meaning that Bluetooth nodes have to route IP packets. In this case a MANET protocol could be (more or less) directly re-used. * Zeroconf issues are address assignment, name resolution, security, etc. * MANET assumes full Ethernet broadcasting mechanisms that are not present in Bluetooth. Q: Do you not want to run IP and enable everything? A: Yes. Q: What is N? A: It is unclear at the moment, but maybe something like 10-20? Q: Will it be MANET protocols that solve N-hop forwarding or hide that from IP? A: This is undecided at the moment. Q: How does this not overlap with WLAN? A: Bluetooth solves additional things, but there is indeed an overlap. Q: Does Ethernet encapsulation not replace 10BaseT Ethernet? A: No, it provides a known interface to upper protocols, hiding Bluetooth specifics. It also provides better broadcast capabilities. Q: What about a hybrid solution with Ethernet emulation per piconet? A: Yes, this is also a possibility. Q: What about use of addressing space? A: The desire is to re-use Autonet-type of things, and DHCP when available. Next steps: * A mailing list is set up, where further discussions will take place. Also further questions can be asked. General Discussion: Bluetooth-BOF@mailbag.intel.com To Subscribe: listserv@mailbag.intel.com In Body: subscribe Bluetooth-BOF first_name last_name * Take the feedback from BOF to the PAN Working Group * Establish Bluetooth liaisons to relative IETF groups * Q&A: Q: IEEE 48-bit addresses, will they not run out of that? A: Yes, there are ongoing discussions about this with IEEE. Perhaps EUI64 will be used for Bluetooth 2.0. Q: What about binding everything to Bluetooth, and avoid the technology-independent layering? A: This is a trade-off between layering and interoperability. Charles Perkins suggests active involvement in MANET to solve problems like the broadcasting problems. A: One of the reasons for chosen solutions in Bluetooth 1.0 was the timeline and push for a fast solution. Now the PAN working group wants to comply with RFCs to ensure interoperability. Q: What does PAN want from the IETF, as generally it is the task of the IETF to define mapping of IP over link-layer protocols? A: PAN working group wants to discuss with the IETF, but sees no need for a new IETF working group, as no new protocols are needed. Q: What mobility solutions are looked at? A: No details can be given, but there is a subgroup. Q: Why this BOF, since no working group will be formed? A: An Informational BOF is also possible, which this is. Q: Will there be only a one-way information flow? A: No, the PAN working group would like to interaction with IETF working groups, to make them aware of Bluetooth specific issues. Q: Why not submitting drafts to solve problems? A: That is one of the goals, to start interacting with the IETF. Question/Comment: Liaisons between standardization bodies usually include exchange of drafts. That is difficult if Bluetooth hides the drafts. A: True, but the PAN working group is limited by the Bluetooth contract. Suggestion: there are problems with L2CAP that are solved in the PILC working group. Bluetooth should look at that working group. Q: IEEE also standardizes Bluetooth (802.15), should IETF have a liaison with them? A: They stop at L2CAP, IEEE does not standardize profiles, and therefore similar problems reside. Also, 802.15 is still at concept stage. Q: There are address assignment problems, and thus PPP used, why is that? A: The LAN Access profile does not solve the addressing problems. PPP was not selected for solving IP problems, but as migration path using serial link emulation. Question/Comment: The (most) important thing for Bluetooth is to support IP. Question/Comment: The problem with next steps is that outsiders do not have access to the ongoing specification. Q: Do IEEE 802.11 and Bluetooth inter-operate? A: There is interference, reduction of range and bandwidth (for both technologies), due to operation in the same frequency band. Q: Has bridging to 802.11 looked at? A: That is where MANET is looking at. Q: On the mailing list there will be a lot of diverse discussion, which will perhaps be too diverse for one mailing list? A: Bluetooth PAN people will try to be more active on IETF mailing lists. Q: Is L2CAP changing in version 2? A: Some enhancements will probably be made. Q: Can you compare 802.11 ad hoc mode with Bluetooth? A: Not really, 802.11 ad hoc mode has a device sending out beacons and uses multiple access, while Bluetooth sets up a new connection and is connection oriented. Q: Is there a target date set for Bluetooth 2.0? A: No, that will be different per working group (a working group will specify a profile). Question/Comment: If IETF people give feedback on 1.0 specs, they may receive the answer: it is already looked at (this works discouraging for further feedback). Conclusions: * A pure layer 2 solution is the preferred way of doing things (this seems to be the feedback from the IETF to Bluetooth). * There were a lot of questions and comments about the (closed) structure of the Bluetooth SIG and its standardization process. * Both the IETF and the Bluetooth PAN working group agreed that closer interaction is necessary. To accomplish this, the PAN working group members will participate more actively in relevant IETF working groups. --------------------