Carles, Rev 1 of the I-D is just a skeleton that I needed to submit to meet the Rev 0 deadline. Please wait for Rev 1 of the I-D by end of tomorrow for a better structure to the document.
Rgds, -Raj -----Original Message----- From: ext Carles Gomez Montenegro [mailto:[email protected]] Sent: Thursday, March 10, 2011 11:03 AM To: 6lowpan Cc: Patil Basavaraj (Nokia-MS/Dallas); Savolainen Teemu (Nokia-MS/Tampere); Nieminen Johanna.1 (Nokia-NRC/Helsinki); Isomaki Markus (Nokia-CIC/Espoo); [email protected] Subject: IPv6 over BT-LE Dear folks, I have been very pleased to see that there is a new 6LoWPAN work item which deals about transmission of IPv6 packets over Bluetooth Low Energy (BT-LE). I would like to contribute to this topic. I will next give some comments on draft-patil-6lowpan-v6over-btle-00: - The introduction mentions some typical performance values of BT-LE. It might be interesting to add more detail in a new (informative) section, which might include text about the following: o The maximum rate of L2CAP payload per time unit is roughly 271 kbps under ideal conditions. This performance parameter decreases strongly with BER (and depends also on BT-LE parameters). o Data transfer can happen from once every 7.5 ms up to once every 32 seconds, depending on BT-LE parameter settings. o Data delivery latency once a BT-LE Link Layer connection is created is roughly equal to 1 ms. - BT-LE defines two Link Layer roles: the master and the slave. A device in the master role is assumed to be less constrained than a device in the slave role. The master can manage multiple simultaneous connections with a number of slaves, whereas a slave is connected to a single master. Hence, a BT-LE network (i.e. a BT-LE piconet) follows a star topology. - Master and slave can correlate with 6LBR and 6LN (host). A BT-LE piconet running IP would be a single-hop IP network. - 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 (per se) does not currently support the formation of mesh networks. - Section 3 states the 6LoWPAN specs that have to be supported by a BT-LE node. It may be interesting to see which mechanisms of the current 6LoWPAN specs are not necessary for BT-LE (e.g. the mesh under header of RFC 4944 will not be used since BT-LE does not support mesh topologies). - The BT-LE L2CAP MTU (i.e. maximum L2CAP payload size) has to be considered, as this is one of the most challenging elements. This MTU is equal to 23 bytes. This means that a compressed IPv6 header containing global addresses (which according to section 3.2 is 26 bytes) does not fit into a single BT-LE packet (!!). In addition, the header overhead of BNEP has to be taken into consideration. - A mechanism for stateless address autoconfiguration based on BT-LE identifiers is needed. - The security considerations section may benefit from discussing the following: o BT-LE Link Layer supports encryption and authentication by using the CCM mechanism and a 128-bit AES block cipher. CCM does not consume bytes from the 23-byte L2CAP MTU (since these bytes have their own field in the link layer data unit). o Whereas key management is out of scope of IEEE 802.15.4 specs, BT-LE provides SMP, a protocol for key management. Some minor details: - Section 2. I am not sure about whether the term 'BT-LE Physical Layer' that appears at the bottom of the protocol stack includes also 'BT-LE Link Layer'. Maybe this layer could be explicitly included in the figure. - Section 3.1. "A BT-LE needs" -> "A BT-LE node needs" All the best, Carles _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
