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 sgalli@assia-inc.com
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
Body
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.