2.2.10 IP over Bluetooth (ipobt) bof

Current Meeting Report

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 <pravinb@research.att.com>
Kris Fleming <kris.d.fleming@intel.com>

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.

Questions about reliability, transmission power, high-power mode.
---------------------------------------------
Q: What is the size of channel ID space?
A: 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.

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.

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.

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:

General Discussion: Bluetooth-BOF@mailbag.intel.com
To Subscribe: listserv@mailbag.intel.com
In Body: subscribe Bluetooth-BOF first_name last_name

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:

Slides

Agenda
Bluetooth Scatternets
TCP/IP Support in Bluetooth 1.0
Bluetooth Technology Overview