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

State Posted
Posted Date 2015-07-07
From Group ITU-T-SG-15
From Contact Hiroshi Ota
To Group roll
To Contacts Ines Robles
Michael Richardson
CcAlia Atlas
Alvaro Retana
Deborah Brungard
Routing Over Low power and Lossy networks 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 roll
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.