1. 20 February 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] Summary of roll interim call [20min]
summary 2 sec call + ROLL
Dallas agenda, will do call for agenda items
re-org meeting material
Summary of roll interim call [20min]
ZigBee IP-in-IP encapsulation
Robert’s Proposal for mesh header
Consequences on plugtest/decisions [20min]
discussion
reminder ETSI CfE
Architecture draft last call [10min]
summary slides
AOB [3min] 4 4 4 4 4

5. Administrivia

6. Admin is trivia Approval Agenda Approval minutes last call
Dallas meeting asks and call for agenda
About using the IETF site instead of bitbucket to store interim proceedings 6 6 6 6

7. ROLL interim

8. Agenda
Links:
( but I cannot access that !!! )
Items:
Agenda bashing
Goals and desired outcomes for this meeting
Arrive at consensus on the scope of the compression of 6553/6554 problem.
How much effort to spend, and where shall the problem be solved.
Explore the three alternatives; and the constraints on the solution space
Cover origin of problem: how did we get here
a. 6tisch requirements for minimal
b. 6man review of flow label
c. 6lo review of NHC
d. publication of dispatch header solution
Architectural deep dive of proposals on the table
10/10/2017

9. Key take-aways Discussed NHC and 6loRH proposals
Pascal presented why not NHC++
Gabriel and Ralph concerned with overloading of 0x10xxxxxx dispatch:
May raise Issues with other SDOs
Recommend to document the NHC++
Group asked Robert about Zigbee (see next slides)
Robert hinted about a variation of 0x10xxxxxx proposal with less impact

10. Notes
The interim discussion pointed out that IPv6 –and the specs that went through 6MAN- expects the addition on IPinIP when headers have to be stripped or added by an intermediate router.
ROLL should produce rapidly a spec that disambiguates the frame content in various steps of storing and non- storing.
It will probably take time till ROLL comes back with the exact frame layouts as IPv6 would expect them. It is still unclear what the compression will be since the reuse of the 0x10xxxxxx mesh-under dispatch raises political concerns.

11. Why not NHC++ ? RFC 6282 Code Point starvation RFC 6282 Code Base
NHC “greedy” discussion => conservative use
RFC 6282 Code Base
Backward compatible code on IP
Separate routing operation from endpoint
RPL or not RPL?
TLV space for other routing and tagging purposes
Legacy hosts
Allows decaps. of 6LoRH at penultimate node
- First, working on NHC it was clear that the group is conservative with code points taken from RFC6282, so we cannot expect a lion share for RPL artifacts. The proposal extends a field which is (arguably, unsure if it is still debated) a lion share of the dispatch sub-byte. The mesh header is currently only defined for mesh-under, and more specifically for and for 16 or 64bits MAC addresses. Considering that we now extend 6LoWPAN on many other MACs and support route-over, blocking all that dispatch space is simply not acceptable. We actually propose an extensible reuse of that field for route-over networks where it is virtually free space. We argue that it is also free space for non MACs, and if other MACs use the 6LoRH proposal, then they can define their own TLVs for their own mesh header as well within the 6LoRH infrastructure.
- Second, backward compatibility is an identified issue that we discussed again at the last 6TiSCH interim. The 6LoRH proposal does not change RFC 6282, so the code does do not need to check for a version field, which, in fact, does not exist in the protocol.
- Third, the group is very sensitive to allowing non-RPL routing on equal grounds as RPL (see discussion on 6775-update-reqs). The proposal is extensible through TLV to additional routing artifacts that would come from another routing protocol.
- Finally, 6TiSCH wishes to support non-RPL hosts in a RPL network. In that case, it is a good idea to go beyond RFC6554 and allow the penultimate router (the 6LR for the destination) to strip all the RPL artifacts before delivery. The proposal does that by simply removing the 6LoRH, same argument and benefits as the dual IP-in-IP format. IOW, the proposal enables non-RPL leaves in a RPL network, as long as the leaves support whatever comes out of 6775-update-reqs regarding RPL needs.

12. ZigBee IP-in-IP encapsulation

13. IP-in-IP in ZigBee IP Used in a number of places
Sending to RPL Root to carry RPI option
Sending from RPL Root to carry RH3 header
Multicast encapsulation
Concentrate on (1) and (2) for this call
Traces shown come from Wireshark used at ZigBee IP Specification Validation Event (SVE)

14. Topology R1 R2
Root
Global prefix 2001:db8::/64 on context ID 0 R1 16-bit address 0x5566 R2 16-bit address 0x3344 Root 16-bit address 0x1122

15. To RPL Root
Echo Request from R1 to Root Packet 1 from 0x5566 to 0x3344
MAC header
(0x5566 to 0x3344)
IPHC
(outer)
NHC
(RPI)
NHC
(IPv6)
IPHC
(inner)
ICMPv6
Payload
Packet 2 from 0x3344 to 0x1122
MAC header
(0x3344 to 0x1122)
IPHC
(outer)
NHC
(RPI)
NHC
(IPv6)
IPHC
(inner)
ICMPv6
Payload

16. Packet 1 IPHC outer
IPHC Header = Pattern: IP header compression (0x03) = Traffic class and flow label: Version, traffic class, and flow label compressed (0x0003) = Next header: Compressed = Hop limit: 64 (0x0002) = Context identifier extension: False = Source address compression: Stateless = Source address mode: Compressed (0x0003) = Multicast address compression: False = Destination address compression: Stateless = Destination address mode: Compressed (0x0003) [Source context: fe80:: (fe80::)] [Destination context: fe80:: (fe80::)] Source: fe80::ff:fe00:5566 (fe80::ff:fe00:5566) Destination: fe80::ff:fe00:3344 (fe80::ff:fe00:3344)

17. Packet 1 NHC RPI RPI Hop-by-hop header (RFC6553)
IPv6 extension header = Pattern: IPv6 extension header (0x0e) = Header ID: IPv6 hop-by-hop options (0x00) = Next header: Compressed Header length: 6 Data (6 bytes) c..... Data: [Length: 6]
RPI Hop-by-hop header (RFC6553)

18. Packet 1 NHC IPv6
IPv6 extension header = Pattern: IPv6 extension header (0x0e) = Header ID: IPv6 header (0x07) = Next header: Inline
This indicates next header is IPHC (RFC6282 section 4.2)

19. Packet 1 IPHC inner
IPHC Header = Pattern: IP header compression (0x03) = Traffic class and flow label: Version, traffic class, and flow label compressed (0x0003) = Next header: Inline = Hop limit: 64 (0x0002) = Context identifier extension: False = Source address compression: Stateful = Source address mode: Compressed (0x0003) = Multicast address compression: False = Destination address compression: Stateful = Destination address mode: 16-bits inline (0x0002) [Source context: 2002:db8:: (2002:db8::)] [Origin: 48] [Destination context: 2002:db8:: (2002:db8::)] Next header: ICMPv6 (0x3a) Source: 2002:db8::ff:fe00:5566 (2002:db8::ff:fe00:5566) Destination: 2002:db8::ff:fe00:1122 (2002:db8::ff:fe00:1122))

20. Packet 2
…is more or less the same format as Packet 1

21. From RPL Root
Echo Reply from Root to R1 Packet 3 from 0x1122 to 0x3344
MAC header
(0x1122to 0x3344)
IPHC
(outer)
NHC
(RH3)
NHC
(IPv6)
IPHC
(inner)
ICMPv6
Payload
Packet 2 from 0x3344 to 0x5566
MAC header
(0x3344 to 0x5566)
IPHC
(outer)
NHC
(RH3)
NHC
(IPv6)
IPHC
(inner)
ICMPv6
Payload

22. Packet 3 IPHC outer
IPHC Header = Pattern: IP header compression (0x03) = Traffic class and flow label: Version, traffic class, and flow label compressed (0x0003) = Next header: Compressed = Hop limit: 64 (0x0002) = Context identifier extension: False = Source address compression: Stateful = Source address mode: Compressed (0x0003) = Multicast address compression: False = Destination address compression: Stateful = Destination address mode: Compressed (0x0003) [Source context: 2002:db8:: (2002:db8::)] [Origin: 48] [Destination context: 2002:db8:: (2002:db8::)] Source: 2002:db8::ff:fe00:1122 (2002:db8::ff:fe00:1122) Destination: 2002:db8::ff:fe00:3344 (2002:db8::ff:fe00:3344)

23. Packet 3 NHC RH3 RH3 Routing header (RFC6554)
IPv6 extension header = Pattern: IPv6 extension header (0x0e) = Header ID: IPv6 routing (0x01) = Next header: Compressed Header length: 14 Data (14 bytes) ee `..Uf Data: 0301ee [Length: 14]
RH3 Routing header (RFC6554)

24. Packet 3 NHC IPv6
IPv6 extension header = Pattern: IPv6 extension header (0x0e) = Header ID: IPv6 header (0x07) = Next header: Inline
This indicates next header is IPHC (RFC6282 section 4.2)

25. Packet 3 IPHC inner
IPHC Header = Pattern: IP header compression (0x03) = Traffic class and flow label: Version, traffic class, and flow label compressed (0x0003) = Next header: Inline = Hop limit: Inline (0x0000) = Context identifier extension: False = Source address compression: Stateful = Source address mode: Compressed (0x0003) = Multicast address compression: False = Destination address compression: Stateful = Destination address mode: 16-bits inline (0x0002) [Source context: 2002:db8:: (2002:db8::)] [Origin: 48] [Destination context: 2002:db8:: (2002:db8::)] Next header: ICMPv6 (0x3a) Hop limit: 63 Source: 2002:db8::ff:fe00:1122 (2002:db8::ff:fe00:1122) Destination: 2002:db8::ff:fe00:5566 (2002:db8::ff:fe00:5566)

26. Packet 4
…is more or less the same format as Packet 3

27. Proposal for mesh header

28. A Routing Header Dispatch for 6LoWPAN
draft-thubert-6lo-routing-dispatch-03
Proposes re-appropriating mesh dispatch code on the basis that
It is not used much
Its use would be consistent throughout a specific mesh network implementation
Mesh network implementations are independent
This has caused some concern on the basis that RFC4944 has been published for some years and it is not easy to gauge the use of the mesh header dispatch code amongst implementations

29. Basic solutions Ignore the naysayers and proceed
Specify a complete replacement for 6LoWPAN
Consider the most likely use case for mesh header and avoid conflict with that
(1) would set an uncomfortable precedent
(2) is practical but weakens the already highly present brand of 6LoWPAN
This solution takes approach (3)
There may be other practical solutions as well to be explored further

30. Proposal Ensure that dispatch code 0b1011 is not used
0b1011 represents a mesh header using 16-bit originator and final addresses; probably the most likely case
0b1000 would mean both 64-bit addresses, which is costly in space
0b1001 and 0b1010 would mean mixed size addresses, which seems unlikely in practice

31. Thread
Thread uses mesh header 0b1011 so that is one clear implementation Thread could change – specification is not set in stone yet (as of Feb ) However, Thread would prefer to use an established specification (RFC4944) instead of an early draft

32. Implications on the draft
The use of 0b1011 in draft-thubert-6lo-routing- dispatch-03 represents the elective format with a length from 16 to 31 bytes Therefore, this would mean limiting the length of the elective format to The only currently specified elective format is IP-in-IP 6LoRH It is unlikely this would exceed 15 bytes in practical use

33. New Elective 6LoWPAN Routing Header
|1|0|1|0| Len | Type | | <-- Len -->

34. Question to the group
Would this be a problem?

35. Impact on ETSI plugtest

36. PlugTest coverage Security? Synchronisation, common schedule
– probably not, suggest PSK
Synchronisation, common schedule
- YES!!!
RPL operation
– YES!!! but …storing, non-storing, both ?
6top interface
- YES!!! We need to learn about completeness of the spec
Data flows?
– probably not final form, so?
- Occam’s razor says leave implementation as is
- Alternates on next slide

37. So what do we do for the plugtest?
Occam’s razor: Document our own layouts in storing and non-storing, bypassing 6MAN for this round, no IPinIP
Follow the ZigbeeIP specs, whatever was done and tested there, and try to standardize it at ROLL
Wait for ROLL and implement their flows. No compression of RH3 (EID=1) and RPI HbH (EID=0) in LOWPAN_NHC.
Implement what we have on the table, either FL, NHC, 6LoRH or a combination thereof, to get implementation feedback. 
Questions arise :
- to implementers: what’s doable by Prague time?
- all: advice / comments?

38. draft-ietf-6tisch-architecture-05
WGLC of
draft-ietf-6tisch-architecture-05

39. Status at a glance
Started on – 28th January Ended – 18th February Number of respondents – 18, with the following votes:
Publish
Publish with edits
Do not publish 14 4

40. Feedback
Editorial Technical suggestions Consolidated in bitbucket

41. Top feedback
Speculation – Reference to next round of the draft, Version of the draft - s/Volume/Edition? [ Maria Rita, Michael Richardson, Jonathon Simon]
I-D.ietf-roll-rpl-industrial-applicability [Michael Richardson]
Cleanup – Abstract, Introduction, Application and goals [Michael Richardson, Jonathon Simon]
Refactoring and clean up of some of the sections [Michael Richardson ]*
Maria Rita:
pag 7 are we sure we want to mention in the next round of the document we will have evaluated PANA applicability? we may need/want to publish the second part of the architecture before that, we don’t know yet. So, we could skip that, if you agree.
I think that the 4 scheduling paradigms should be mentioned in
    the introduction as well!  To first order, I think that is perhaps
    the most important thing in the document.
"   If the size of a bundle is configured to fit an average amount of
   bandwidth, peak emissions will be destroyed."
(I don't think the word you want is "destroyed".  I think that it
means that packets will be dropped, but I don't think that describing
the dropped packets as destroyed is the correct IETF idiom here, even
though it might be grammatically correct)
19)    6TiSCH supports three different forwarding model, G-MPLS Track
   Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6 Forwarding
   (6F).
   also should be mentioned in the introduction...

42. Next steps
Authors to respond to open questions on alias Revised ID / discussion with reviewers IESG writeup following revised ID

43. AOB ?

44. Thank you!