6lo: IPv6 over networks of resource-constrained nodes WG Minutes Meeting : IETF 88 Tuesday November 5, 2013 Time : 1610-1840 Afternoon Session III Location : Regency A Chairs : Samita Chakrabarti Ulrich Herberg Secretary : Ralph Droms Minutes : Timothy J. Salo, Ralph Droms Jabber : xmpp:6lo@jabber.ietf.org Audiocast : http://ietf88streaming.dnsalias.net/ietf/ietf885.m3u URLs : https://www.ietf.org/mailman/listinfo/6lo http://datatracker.ietf.org/wg/6lo/ ========================================================= The meeting was chaired by Samita Chakrabarti and Ulrich Herberg. The chairs opened the meeting at 4:14 p.m. Ulrich Herberg reminded the attendees of the IETF Note Well and reviewed the agenda. Samita Chakrabarti reviewed the working group's recently approved charter. The working group will focus on IPv6-over-foo adaptation layer specifications that use the 6LoWPAN technologies and related activities, such as low-complexity header compression. Samita also presented the proposed working group milestones. A brief discussion ensued about a typo and a possibly missing document on the milestone list. Transmission of IPv6 packets over ITU-T G.9959 Networks draft-brandt-6man-lowpanz = = = = = = = = = = = = = Carsten Bormann presented an overview of the draft, which specifies how IPv6 packets are to be transmitted over ITU-T G.9959 networks, more commonly known as Z-Wave networks. These networks support both route-under (mesh) routing and route-over (IP) routing. This draft was originally presented in the 6man working group. This draft largely follows 6LoWPAN, except that mesh routing is not used, fragmentation is not needed, and short addresses are 8-bits, rather than 16-bits. Carsten considers the draft mature. The working group chairs asked whether this draft should be accepted as a working group document. In response to a question, it was stated that there is no competing solution. No objections were raised to adopting this as a working group draft. IPv6 over MS/TP Network draft-lynn-6man-6lobac = = = = = = = = = = = This draft, presented by Kerry Lynn, specifies a method for encapsulating IPv6 packets over MS/TP networks (LoBAC). This draft was originally introduced in the 6man working group. MS/TP (Master-Slave/Token-Passing) networks are used in building control applications. This standard is part of BACnet, a protocol for building automation and control networks developed by ISO/ANSI/ASHRAE. These are wired networks and use RS-458, which is similar to RS-232, except that differential drivers are used. MS/TP only supports link-local broadcasts; there is no multicast facility. Several changes to MS/TP have been proposed, to better support IPv6 and 6LoWPAN. Don Sturek: Is this specification only for the MS/TP over RS-485? MS/TP supports several other media. Kerry Lynn: Yes, this is for only RS-485 networks. All of the other BACnet media already have IPv6 adaptation layers. Michael Richardson: Does MS/TP use HDLC-like framing? Kerry Lynn: No, MS/TP is byte-oriented, not bit-oriented, and it does not use the byte-oriented HDLC framing. Samita: [Apparently a question about market size] Kerry Lynn: Several million devices are sold each year. Samita: Why is the MS/TP MSDU size being changed to 1500 octets? Kerry Lynn: There is a desire to avoid fragmentation/reassembly, although most packets aren't this large. Pascal Thubert: Shouldn't this draft reference RFC 6282 rather than RFC 4944? Kerry Lynn: RFC 6282 should be referenced. Carsten Bormann: [something about 6282, always 4944] Michael: Because BAC is increasing the frame size larger to avoid fragmentation, why is this draft needed? Lynn: MS/TP uses a [bandwidth] constrained medium, and so there is a need for header compression to save bandwidth. Kerry briefly described the MS/TP control and data frame formats. Data are encoded using COBS (a run length encoding that compresses strings of zeros). LoBAC Encapsulation uses the RFC 4944 Dispatch Header. Two types of messages are used: IPv6 datagrams and RFC 6282 compressed IPv6 headers. The mesh, broadcast, and fragmentation headers are not used. The one-byte addresses used by MS/TP are padded with a leading byte of zero. Don: The strategy described on page 9 of the presentation (the use of the RFC 4944 dispatch header) strategy won't work in wireless environment. Lynn: This is the dispatch header specified in RFC 4944. Plus, RFC 4944 includes an escape code, which permits additional dispatch codes to be used. Pascal Thubert: The 6LoWPAN dispatch type codes were modified by RFC 6282. Lynn: The intent is to use RFC 6282 dispatch type codes. Don: Does this draft introduce any conflicts with the neighbor discovery (ND) work, such as the interface ID? Lynn: This hasn't yet been examined. Brian Haberman: This draft was reviewed by the 6man working group, before it was moved to the 6lo working group. The 6man working group thought that this draft looked fine from an IPv6 perspective. Ralph Droms: Can a device communicate with every other device on the MS/TP bus? Kerry Lynn: yes. Can a MS/TP network have more than one master station? Kerry Lynn: All devices on the MS/TP bus are masters. This specification is meant for masters. Brian: This draft was parked in 6man waiting for external standards activity to be completed [such as expanding the MDSU to 1501 bytes]. How long before you expect these external standards to be updated? Lynn: Six months. Geoff Mulligan: Are multiple 6lowpan LBRs permitted? Kerry Lynn: Each controller would be an LBR, because each strips dispatch header. Carston: This is classic 6LoWPAN. It only borrows context distribution. Geoff: I didn't see any language in the draft that LBRs need to agree on context distribution. Samita: Should this document be modified to state that LBRs need to agree on context distribution? Or, should this be stated in another document? Kerry Lynn: It would be nice if it were stated in one place. Carsten Bormann: You have to configure a router today, so it's no problem to also configure protocol information consistently. Carsten Bormann: This draft should warn that context information needs to be configured consistently. Zack Shelby: I think that it is sufficient to state that the recommendations of RFC 6775 should be followed. The chairs asked whether this draft should be adopted as a working group document. There were no objections to adopting this as a working group draft. Transmission of IPv6 Packets over DECT Ultra Low Energy draft-mariager-6lowpan-v6over-dect-ule = = = = = = = = = = = = = = = = = = = A draft that specifies how IPv6 packets should be transported over DECT Ultra Low Energy (ULE) networks was presented by Zach Shelby. DECT is a digital wireless technology, which uses 1880-1900 MHz spectrum in Europe, and 1920-1930 MHz in the U.S. It has a range of 75-300 meters. The recently defined ultra-low energy mode is similar to Bluetooth LE. These networks use a star technology, so multi-hop and mesh routing are not needed. A broadcast capability exists, but doesn't work very well. DECT is used in home games. Zach stated that the addressing portion of this document still needs work. Each DECT controller is assigned a globally unique, 40-bit, International Portable Equipment Identity (IPEI) during manufacturing. The DECT controller assigns a 20-bit Temporary Portable User Identity (TPUI) to each DECT device; the TPUI is unique within the network attached to the controller. The draft says that the IPEI/TPUI can be used by the IPv6 adaptation layer, or a 48-bit IEEE MAC address could be created, (although the draft does not state how the 48-bit MAC address would be created). Brian: This discussion may be premature, depending on whether the 6man working group decides deprecate the use of 48-bit MAC addresses for creating IPv6 addresses. Pascal Thubert: It may be fine for 6man to deprecate the use of 48-bit MAC addresses, but the 6LoWPAN protocols may still find them. Pascal Thubert: These addressing schemes might have implications for privacy. Zach: Bluetooth LE has thought some about this issue. Ralph: Are any implementations available? Zach: A few chip makers working with RTX have implementations. A German company is using this in a home automation system. Don: Does DECT support multi-cell roaming and, if so, how does this interact with ND? ND would need to deal with this. Zach: Good question: This hasn't been looked at, so we aren't really sure what implications this might have for ND. Pascal Thubert: DECT originally designed as a last-mile solution, but wasn't successful in that application. DECT has dedicated spectrum and a TDM capability. Douglas Chan: Is this technology scalable in this spectrum? Zack: This spectrum is really unused compared to 2.4 GHz. So, there should be plenty of spectrum available for our sorts of applications. Pascal Thubert: Furthermore, time slots help use spectrum more efficiently. Xxx: Device-to-device communications is not supported directly by DECT; rather DECT nodes must communicate through the base station. Is anyone looking to support direct device-to-device communications? Zach: I don't think so. Additionally, would be nice if the broadcast capability were improved. For example, there is no broadcast security. Pascal Thubert: Has technology been considered for MAN communications? Zach: I don't know. DECT doesn't have a multi-hop capability. As such, it might support homes and buildings, but might not be as well adapted to MANs. It was generally agreed that this document is not ready for adoption by the working group. Generic Header Compression draft-bormann-6lo-ghc = = = = = = = = = = = Carsten Bormann provided an update on the Generic Header Compression (GHC) draft. He reviewed the motivation for header compression and the current status of header compression in low-power, wireless networks. 6LoWPAN technologies (RFC 4944, RFC 6282, and RFC 6775) can compress the IPv6 fixed header, some IPv6 extension headers, and the UDP header. GHC can compress additional headers (and some header-like payloads) that aren't compressed by RFC 6282. It operates in a generic fashion: it doesn't embody any knowledge of the format of the header or data being compressed. GHC uses LZ77 compression, is stateless, and makes use of the Next Header Compression (NHC) capability specified in RFC 6282. The GHC draft specifies an LZ77-style bytecode, glue to integrate GHC with the RFC 6282 NHC feature, and an ND option. The draft also includes numerous examples of compressed headers. GHC was originally proposed in 2010. Since then, several features have been deleted. Additionally, some research on the effectiveness of GHS has been conducted. For the most part, this draft has been waiting for the 6lowpan working group to transition to the 6lo working group. Kerry Lynn: Has any cost-benefit analysis been performed, which would indicate whether developing a compression scheme for a particular header is worthwhile? Carsten Bormann: The draft has some information on this. Clearly, we wouldn't want to develop a header-specific compression specification for little-used headers. Michael: I used this approach for RPL headers. It didn't require much effort to make effort header compression worthwhile. Michael will analyze the effectiveness of his scheme on any interesting RPL Christmas tree packets that are sent to him. Don: How sensitive is GHC to the 127-byte payload of IEEE 802.15.4? Many link-layer protocols have much smaller payloads. Carsten Bormann: GHC is optimized for small payloads. Erik [?]: What risk do incorrectly encoded frames present? That is, is this a potential security problem? Carsten Bormann: This is an issue with any compression scheme. Carsten requested that interesting packets be sent to him for analysis. Carsten Bormann: It might be possible to improve the performance of GHC by tweaking static dictionary. There was no objection to adopting this as a working group draft. LOWPAN-MIB draft-schoenw-6lo-lowpan-mib = = = = = = = = = = = = = = Juergen Schoenwalder summarized the LOWPAN-MIB draft. This document specifies counters that record statistics about the processing in the 6LoWPAN layer of received and transmitted packets. These counters are useful in identifying problems in 6LoWPAN fragmentation, compression, or mesh forwarding. The counters specified in this draft have been implemented in the Contiki operating system, to the extent possible. These counters were exported to a Contiki SNMP implementation. Michael: Is the diagram in the presentation for mesh-under networks? Juergen: Yes. Xxx: The 6tisch working group is using CoAP for a similar purpose. How does this work relate with the 6tisch CoAP-based approach? There seems to be similar needs for monitoring and managing nodes. It would be nice to have a common solution. Juergen: coman (Management of Constrained Networks and Devices) was also discussed today. Zach: Some devices need to use CoAP [for other purposes]. If you can't use SNMP, it would be nice to have a way to represent information with something else. CoAP is a general object format. There was a general awareness of the issue of multiple possible approaches to encapsulating network management information in constrained nodes. Ulrich: Yes, there is an issue with multiple network management approaches. But, this probably isn't the working group that ought to address this. Pascal Thubert: RESTCONF was mentioned in 6tisch working group meeting. RESTCONF has, for example, transactions, which might be useful for configuration. Samita: Pascal, are you suggesting this draft discuss the issue of multiple, potentially competing approach to network management in constrained deices? Pascal Thubert: This is a cross-working group problem. It should be discussed as a common problem. Zack: Should we do something different? No, this draft is what 6lo should do. Carsten Bormann: xxx also will discuss transporting management info. There was a brief, inconclusive discussion about whether changes were needed for Bluetooth LE or DECT ULE. Carsten Bormann: Should there be counters for packet discards? Contiki has two different discard policies, for multicast and for unicast. In general, people should look at their code and see what counters are missing. Ulrich: During the chartering discussion, there comments about the need for information models in addition to data models. Is there any interest in this? There was no response to Ulrich's question. The chairs ask whether this should be adopted as a working group document. Pascal Thubert: Would every 6LoWPAN device need to have this MIB? Ulrich: I don't think every 6LoWPAN implementation is required to implement this MIB. Ralph: There is no overall definition of what it means to be 6LoWPAN compliant. Rather, implementations may claim to be compliant with individual RFCs. Carsten Bormann: Actually, the 6LoWPAN Roadmap draft specifies what it means to be 6LoWPAN compliant. But, this draft hasn't been brought to the working group yet. Ralph: Will the 6LoWPAN Roadmap be informational? If so, it doesn't create any compliance requirement. A brief discussion about compliance ensued. Mack Elmore [?]: The ZigBee working group is looking at ZigBee profile that will include a MIB. Samita: Does this document apply to Bluetooth LE? Juergen: This draft tries to be generic. Pascal Thubert: How ought additional counters be added? Kerry Lynn: We probably want to make the 6LoWPAN MIB more modular, since we are seeing that documents are taking some parts of 6LoWPAN, but not others. Juergen: I don't see any technical change required by other technologies. This document simply focuses on 6lowpan; other layers would have their own MIBs. While there were no objections to adopting this as a working group document, the chairs stated that this draft will be discussed on the mailing list, and then considered for adoption. 6LoWPAN Simple Fragment Recovery draft-thubert-6lo-forwarding-fragments = = = = = = = = = = = = = = = = = = = Pascal Thubert provided an update on the 6LoWPAN Simple Fragment Recovery draft. Pascal summarized the motivation for this draft. The small frame size of 802.15.4 may cause an IPv6 packet to be fragmented into more than 16 fragments. Hop-by-hop reassembly should be avoided, since a lost fragment may cause the network to lock until the reassembly timer times out. Also, forwarding fragments along different paths can cause problems. The draft proposes a new header for fragments and a header that carries fragment acknowledgements. This scheme uses four RFC 4944 dispatch types. The fragment header can be used as a switching label. The fragment acknowledgement header contains a 32-bit bitmap of acknowledged fragments, essentially selective acknowledgements. The acknowledgement header also includes a variable window size for congestion control, and can return an RFC 3168-style Explicit Congestion Notification (ECN) indication. The capability described in this draft is needed by the 6tisch working group, which is using the 802.15.4e 2006 physical layer. Pascal considers the draft largely stable, except for a couple of issues. Ulrich: This draft uses four RFC 4944 dispatch types. There aren't a lot of dispatch types available. Does this draft really need four dispatch types? Should this be discussed on the mailing list? Ulrich: This draft replaces the 6LoWPAN mesh header. Does this cause any interoperability problems with existing implementations? Does this obsoletes RFC 4944? Pascal Thubert: Nobody uses the mesh header. Geoff: I used it. Carsten Bormann: Was concerned about many of the premises stated in this document. The abstract says that every packet needs to be reassembled at every node. This doesn't need to be done. Carsten expressed concern that this draft has been discussed for three-four years, but the authors don't seem to be responding to some of the issues that have been raised Don: Expressed mixed feelings about draft. There are problems with fragmentation that need to be addressed, but it looks like this draft is rebuilding TCP. Ralph: Suggested keeping fragment forwarding independent of fragment recovery. Fragment forwarding can probably progress faster through the working group than fragment recovery. He asked whether the authors have talked with transport group about interactions between fragment recovery and transport layer retransmission. Has this analysis been done? Pascal Thubert: No. Ralph: The document is vague about how retransmission times will work. Pascal Thubert: Yes. Ralph: Fragment retransmissions can adversely affect TCP round-trip time (RTT) calculations. Pascal Thubert: There is already a similar issue with link-layer acknowledgements and TCP RTT calculations. Michael: Affirmed Ralph's suggestion that fragment forwarding and fragment recovery be separated. Michael asked: does the 6tisch working group want to forward on a 802.15.4e track based on the fragment header? In that case, is there is any difference between reassembling at each node, versus at the end of the track? Pascal Thubert: There are three possible fragment forwarding models: the IP model (reassemble at each node), the 6tisch or MPLS model, and the fragment forwarding model discussed in this draft. Michael: Is this needed by the 6tisch best-effort service? Pascal Thubert: There are issues of cell allocation. It was concluded that this draft should be further discussed on the mailing list. Milestone Discussion = = = = = = = = = = Samita again presented the current list of milestones. There was little discussion. Samita also reminded the group that there was a desire that the working group consider information models; she solicited suggestions on this topic. The working group concluded at 6:30 p.m. Draft meeting notes respectively submitted by: Timothy J. Salo