1. 22 May 2015 Webex IPv6 over the TSCH mode of IEEE 802.15.4e Chairs:
Pascal Thubert
Thomas Watteyne
Etherpad for minutes:

2. Note Well
This summary is only meant to point you in the right direction, and doesn't have all the nuances. The IETF's IPR Policy is set forth in BCP 79; please read it carefully.
The brief summary:
By participating with the IETF, you agree to follow IETF processes.
If you are aware that a contribution of yours (something you write, say, or discuss in any IETF context) is covered by patents or patent applications, you need to disclose that fact.
You understand that meetings might be recorded, broadcast, and publicly archived.
For further information, talk to a chair, ask an Area Director, or review the following:
BCP 9 (on the Internet Standards Process)
BCP 25 (on the Working Group processes)
BCP 78 (on the IETF Trust)
BCP 79 (on Intellectual Property Rights in the IETF) 2 2

3. Reminder: Minutes are taken. This meeting is recorded
Reminder: Minutes are taken * This meeting is recorded ** Presence is logged ***
* Scribe; please contribute online to the minutes at
** Recordings and Minutes are public and may be subject to discovery in the event of litigation.
*** From the Webex login 3 3 3 3

4. Agenda - Administrivia [2min]
Minutes Last meetings
- Status for draft-ietf-6tisch-architecture [5min]
- Status for draft-ietf-6tisch-minimal [10min]
- plugtest and hackathon news and dates [10min]
- COMI and CoAP draft [15min]
- Rechartering [10min]
- AOB [3min] 4 4 4 4 4

5. Administrivia

6. Admin is trivia Approval Agenda Approval minutes
‘e’ removed from charter
RFC 7554 (TSCH) is out!!! 6 6 6 6

7. Other Announcements New ETSI IP6 ISG
The ETSI “IPv6 integration” Industry Specification Group (IP6 ISG) is a working group to focus on IPv6-based best practices, deployment guidelines and success showcases identifying thereby what and where consensus and harmonization could be reached.
 We invite all interested parties from your organization or others to join in. Participation in the ISG IP6 is subject to signature of an ISG IP6 Agreement you can find at ETSI portal. Explanation about those agreements is also available from the same location.
One standard of particular interest:
“IPv6-based Industrial Internet leveraging 6TiSCH Technology” 7 7 7 7

8. Status for draft-ietf-6tisch-architecture

9. Proposal 08 published Intended Track: Informational
All LC issues solved
Shepherd write up taking place
Thanks Shwetha !!!
Authors are being polled for IPR
All answered, OK there
Next step IESG

10. draft-ietf-6tisch- minimal-07
Xavi Vilajosana (Ed.) Kris Pister

11. draft-ietf-6tisch-minimal-06
Status
Status:
Reworked sections 4 and 5
Referenced to examples
Added examples at the end – Section 10
Needs to be finished:
For example 2 and 3 add the byte stream in LSB
draft-ietf-6tisch-minimal-06 11

12. 5/14/2018

13. 5/14/2018

14. 5/14/2018

15. 5/14/2018

16. 5/14/2018

17. plugtest and hackathon news and dates

18. COMI and CoAP draft

19. Introducing CoMI
Aligned with RestCONF (draft-ietf-netconf-restconf-04)
Common data modeling language (YANG defined in RFC 6020)
Protocol (CoAP instead of http)
Security (DTLS instead of TLS)
Payload encoded (CBOR instead of XML or JSON)
Data node identifier (30 bit hash value instead of data node path) Hash values are encoded in base64 in URI, in binary in payload

20. Example RestCONF (214 bytes payload) CoMI (52 bytes payload)
GET /restconf/data/ietf-6tisch-mac:TSCHSpecificPIBAttributes Host: example.com Accept: application/yang.data+json HTTP/ OK Date: Mon, 23 Apr :01:30 GMT Server: example-server Content-Type: application/yang.data+json { "ietf-6tisch:TSCHSpecificPIBAttributes" : { "macMinBE" : 3, "macMinBE" : 7, "macDisconnectTime" : 255, "macJoinPriority" : 1, "macASN" : , "macNoHLBuffers" : true }
REQ: GET example.com/mg/nDAal RES: 2.05 Content (Content-Format: application/cbor) a1 1a 270c06a5 a6 1a 18f1deec 03 1a 3a4367ae 07 1a 0fd897c1 18 ff 1a 0f817d a 35920a57 1b a 2386c778 f5

21. YANG hash clashes
Hashes are computed using the murmur3 hash on the canonical representation of the data node path. For example: mmh3 ('/6top:TSCHSpecificPIBAttributes/6top:macMinBE', 42) = or "Y8d7s" in base64
Hashes may be identical for different names, so- called clashes
Hash clashes within a module can be detected and fixed at module design time
Hash clashes between modules depend on the set of modules implemented by each CoMI server

22. YANG hash clashes Set of YANG hashes for Module A
Set of YANG hashes for Module B
Set of YANG hashes for Module C
Hash clashes

23. Hash clashes handling as defined in draft-vanderstok-core-comi-06
CoMI servers with hash clashes need to implement a “rehash” list containing:
The hash causing the clash
The data node path
A character appended to the path to resolve the clash
CoMI clients need to retrieve the “rehash” list of each CoMI server prior to accessing them
CoMI clients use the “rehash” list as a lookup table to associate the right data node with the right hash
CoMI clients need to store the full data node names

24. Hash clashes handling as defined in draft-vanderstok-core-comi-06
CoMI client
CoMI server #1
Path of each data node for lookup in “rehash” lists
Server 1 “rehash” list
Server n “rehash” list
Data nodes
, value
, value (Rehash to ) …
“rehash” list
, “/6top:TSCHSpecificPIBAttributes/6top:macMinBE”, “_”
Step 2
Step 1
Step 1
Retrieve “rehash” list from server #1 to #n
Step 2
For each access to data node, perform a lookup in “rehash” list to associate the right data node with the right hash
CoMI server #n
Data nodes
, value
, value …
“rehash” list
<empty>

25. First alternate solution (simplified “rehash” list)
Assuming that hash clashes within each module are resolved at design time
CoMI servers return a “hash clash” error only when a CoMI client tries to access data node(s) with hash clashes
The CoMI client generates a simplified “rehash” list containing:
The old hash
The new hash
The module identifier (local to client)
The CoMI client uses the “rehash” list to resend the request with the proper hash

26. First alternate solution (simplified “rehash” list)
CoMI client
CoMI server #1
Step 1
Module name & data nodes hashes
Server 1 “rehash” list
Server n “rehash” list
Data nodes
, value
, empty (Rehashed to ) …
“extend” list
, value
[ Step 3 ]
[ Step 2 ]
Step 1
Try to access a data node
Step 2
If “hash clash” error receive, retrieve “rehash” from “clash_file”
using module name, old hash”
Step 3
Try again to access a data node
with the rehash value
CoMI server #n
Data nodes
, value
, value …
“rehash” list
<empty>

27. Second alternate solution (No “rehash” list)
Assuming that hash clashes within each module is resolved at design time
CoMI servers return a “hash clash” error only when a CoMI client tries to access data node(s) with hash clashes
On reception of a “hash clash” error, a CoMI client resends its request with the optional query parameter specifying the module name. Notes:
This format can also be used all the time to avoid “hash clash” errors.
“rehash” list are not required (to implement, to retrieve, to lookup)
But requires communication overhead, and module name in server For example: GET example.com/Y8d7s?select= ietf-6tisch-mac
Permanent query overhead

28. Second alternate solution (No “rehash” list)
CoMI client
CoMI server #1
Step 1
Module name & data nodes hashes
Data nodes
, ietf-6tisch-mac, value
, ietf-6tisch-mac, value …
[ Step 2 ]
Step 1
Try to access a data node
Step 2
If “hash clash” error receive, try again to access the data node with the module name added as optional query parameter.
e.g. GET example.com/Y8d7s?select= ietf-6tisch-mac
CoMI server #n
Data nodes
, ietf-6tisch-mac, value
, ietf-6tisch-mac, value …

29. Third alternate solution (Managed IDs)
Partially managed identifiers (Module ID) or fully managed identifiers (Module ID & Data node ID)
Require IANA registration of each YANG module writer. Each writer need to assign module IDs and optionally data node IDs.
Allows payload size reduction
For example (24 bytes payload): REQ: GET example.com/mg/1&select(5) RES: 2.05 Content (Content-Format: application/cbor) a1 01 a ff b f5

30. Third alternate solution (Managed IDs)
CoMI client
CoMI server #1
Step 1
Module ID & data nodes ID
Data nodes
data node #1, module #5, value
data node #2, module #5, value …
Step 1
Access a data node
e.g. GET example.com/mg/1&select(5)
CoMI server #n
Data nodes
data node #1, module #5, value
data node #2, module #5, value …

31. Other items to be discussed within CoMI
Support of the YANG RPC Similar approach as the RestCONF RPC (protocol operations)
Support of the YANG notification Similar approach as the RestCONF notification

32. Rechartering

33. Complete ?
Archie 1 and TSCH
Minimal
CoAP and 6top interface

34. Additions Security Dynamic scheduling Requirements to DetNet
Join Process
More?
In Archie 2?
Dynamic scheduling
OTF
6top
Archie 2
Requirements to DetNet
Track organization and operation

35. AOB ?

36. Thank you!