Liaison statement
LS on concerns on the deprecation of dispatch type in 6loWPAN and its header compression mechanism to 6lo

State Posted
Posted Date 2015-07-07
From Group ITU-T-SG-15
From Contact Hiroshi Ota
To Group 6lo
To Contacts Samita Chakrabarti
Gabriel Montenegro
CcBrian Haberman
Terry Manderson
IPv6 over Networks of Resource-constrained Nodes Discussion List
John Drake
Scott Mansfield
Response Contact
Purpose For action
Deadline 2015-07-24 Action Needed
Attachments LS on concerns on the deprecation of dispatch type in 6loWPAN and its header compression mechanism
Liaisons referring to this one Response to LS on concerns on the deprecation of dispatch type in 6loWPAN and its header compression mechanism to 6lo
ITU-T Study Group 15 has been designated as the lead study group for communications-related aspects of Smart Grid. Question 15 (Q15/15) is responsible for Recommendations ITU-T G.9903 (Narrow-band OFDM power line communication transceivers for G3-PLC networks – approved in 02/2014) and ITU-T G.9905 (Centralized Metric based Source Routing – approved in 07/2013). These two Recommendations normatively reference 6loWPAN (RFC 4944) and its header compression mechanism (RFC6282).

We would like to bring to your attention that on-going discussion in IETF 6lo and ROLL WGs on reusing the ESC and MESH dispatch headers for route-over and mixed operations may lead IETF to deprecate the possibility of using RFC4944 and/or RFC6282 in pure mesh-under networks. This deprecation would create a conflict with Recommendation ITU-T G.9903 and possibly also other standards.

Below we give details on how ITU-T G.9903 uses the ESC and MESH dispatch headers, confirming how important the stability of the 6LoWPAN standard and related IANA allocations are for ITU-T G.9903:

1.      ITU-T G.9903 provides native mesh-under functionalities (the LOADng protocol, which is described in Annex D) while not prohibiting the use of other mesh-under (e.g. CMSR specified in ITU-T G.9905) or route-over routing protocols. If other routing protocols are used, then the native mesh-under LOADng protocol can be disabled.
a.      The first octet corresponds to the ESC Dispatch Header as specified in RFC 6282, i.e. 0b10 000 000.
b.      The second octet corresponds to the command ID. As specified in Table 9-35/G.9903, three possible commands are currently specified (additional commands can be specified to support other routing protocols):
i.      o LOADng command frame
ii.     o loWPAN bootstrapping command frame
iii.    o CMSR command frame (see ITU-T G.9905).

c.      The rest of the frame carries the payload for the relevant command frame.

2.      The ESC Dispatch Header is used by ITU-T G.9903 exclusively for command frames. A command frame is built as follows (see Figure 9-12/ G.9903):

3.      During the bootstrapping phase, the 6LOWPAN_IPHC and ESC headers are present in the same frame. The ESC dispatch header is placed after the 6LOWPAN_IPHC header.
4.      The MESH Header as specified in RFC 4944 is used for data frames only and contains vital information for the correct delivery of G.9903 data frames when the mesh-under LOADng routing protocol is used.

As of today, Japan and France have already started deployment of ITU-T G.9903 smart meters (in France smart meters will represent a total of 32 million ITU-T G.9903 smart meters – 100% national coverage − by 2021). There are also deployed wireless technologies for smart metering (e.g., based on 802.15.4) that support layer 2 mesh routing as well. Furthermore, interest in such technologies transcends smart metering applications and includes a broader set of Smart Grid applications and beyond, making ITU-T G.9903 an important enabler also for IoT applications.

As several existing standards/products rely on using the Dispatch ESC Header for exchanging mesh-under routing and bootstrapping command messages, we would like to bring to your attention that deprecating this feature would have detrimental effects on Smart Grid plans of several countries and utilities:
•       Planned deployments would have to be delayed until a viable alternative is found, standardized, and tested in the field. This would make several utilities in the world inevitably incur high costs.
•       Future deployments based on the above alternative would be non-interoperable with the currently installed base of devices that rely on the availability of the Dispatch ESC Header.
•       Any delay would put at risk complying with deadlines set by regulators of several countries. One notable example is the 2008 Directive from the European Union which mandates EU countries to deploy 80% of smart meters by 2020.
ITU encourages IETF to:
•       Avoid deprecation of the ESC and MESH dispatch headers and look for alternative solutions that do not create conflict with existing standards and products.
•       Work in cooperation with Q15/15 to find alternate solutions that do not create conflicts with ITU-T Recommendations.
Q15/15 looks forward to continued cooperation with IETF.