Skip to main content

Minutes for 6LO at IETF-88
minutes-88-6lo-1

Meeting Minutes IPv6 over Networks of Resource-constrained Nodes (6lo) WG
Date and time 2013-11-06 00:10
Title Minutes for 6LO at IETF-88
State Active
Other versions plain text
Last updated 2013-11-11

minutes-88-6lo-1
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 <samita.chakrabarti@ericsson.com>
                Ulrich Herberg <ulrich@herberg.name>
Secretary   :   Ralph Droms <rdroms.ietf@gmail.com>
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