1. 06 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]
Approval agenda
Approval minutes last call
Updates since last call
Architecture draft last call [Pascal Thubert] [20min]
Terminology draft [Maria Rita Palattella] [5min]
IETF 92 meeting request [5min]
ETSI plugtest [5min]
ROLL interim meeting preparation / discussion [10min]
Recharter chat [QSP]
AOB [3min] 4 4 4 4 4

5. Administrivia

6. Admin is trivia
Approval Agenda
Approval minutes last call 6 6 6 6

7. 6TiSCH-related calls Security DT call 27 Jan 2015
Minutes published at archive/web/6tisch- security/current/msg00417.html
OTF authors call 6 Feb 2015
Summary Diego
Minutes to be published? 7 7 7 7

8. Architecture

9. draft-ietf-6tisch-architecture
Status
05 published
Last call started, ending on 18-Feb-2015
Updates
Security Section (added authors)
Fixed TBDs, new detailed scoped section
Updated stack (COMI, CCAMP, TEAS …)
Updated references (e.g. minimal draft)

10. New TOC

13. draft-ietf-6tisch-terminology-04
MR. Palattella, Ed.
P. Thubert
T. Watteyne
Q. Wang

14. draft-ietf-6tisch-terminology-04
Status:
Adopted at IETF88
Latest version (-03) published 08/01/
New version (-04) available on bitbucket
terminology/src/master/
Includes comments from Rene and Chonggang

15. Main changes 1/2 1) Improved definition of 2) Added definition of
CDU matrix
Chunk EB
ASN
Blacklist of frequencies 6F
DAR/DAC
JCE and JA
2) Added definition of
Deterministic Network
Interference Domain
Centralized cell/track reservation (replacing PCE cell/track reservation)

16. Main changes 2/2 3) Deleted definition of
CoAP
Chunk ownership appropriation/delegation
Security-related terms: DevID, DTLS, IDevID, LDevID, PANA, unique join key, JN, KMP, SA, Peer-to-peer L2 Key
4) Fixed format of each term (upper case for first letter of a word)
5) Provided missing full spelling of acronyms
(e.g., 6LoWPAN, RPL, LLN, P2P, P2MP, MP2MP)

17. Open Issues
Use Payload Data Unit in the 6top Data Convey Model instead of acronym PDU (which is Protocol Data Unit, RFC994)
b) Improve definition of IE?
c) AoB?

18. IETF92 meeting request

19. Proposal Deadline today TODO: chairs to submit proposal
2.5h session, morning
50 attendees
Conflicts to avoid:
First priority: detnet (BoF), 6lo, core (roll not meeting)
Second priority: 6man, ace, dice
Third tsvwg

20. Important Dates http://www.ietf.org/meeting/important-dates-2015.html
(Friday): Cut-off date for requests to schedule Working Group meetings at UTC 23:59. To request a Working Group session, use the IETF Meeting Session Request Tool.
(Friday): Preliminary agenda published for comment.
(Wednesday): Cut-off date for requests to reschedule Working Group and BOF meetings UTC 23:59.
(Friday): Final agenda to be published.
(Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool.
(Monday): Draft Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool.
(Friday): Early Bird registration and payment cut-off at UTC 23:59.
(Monday): Revised Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool.

21. ETSI plugtest

22. 6TiSCH Plugtest updates
Finalizing room reservation (with IETF)
Asked for July, IETF93 hotel
Next step:
call for experts
Spread the word to participants

23. ROLL interim meeting preparation / discussion

24. draft-thubert-6lo-routing-dispatch
Status
03 published
Federates authors of previous proposals
Features
Compression of all RPL artifacts
Extensible through TLV
Reuse of the mesh header in non-mesh-under
| 10 xxxxxx | MESH => 1/3 of 6LoWPAN addressable
Not backward compatible, implies different networks
Proposes a mesh header compression for mixed mode

25. 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.

26. Generic TLV format
|1|0|1| Length | Type | |
<-- Length -->
Elective format (above) is skippable thanks to standard length field whereas
Critical format is not. Length is derived from Type/ Type Specific Extension
|1|0|0| TSE | Type | |
<-- Length implied
by Type/TSE -->
6LoWPAN Routing Header Type values:
0..4 : RH3-6LoRH [RFCthis]
5 : RPI-6LoRH [RFCthis]
6 : IPinIP-6LoRH [RFCthis]
8..11 : MH-6LoRH [RFCthis]
: BIER-6LoRH [RFCthis]

27. RPI-6LoRH <-TSE-> Critical format,
|1|0|0|O|R|F|I|K| 6LoRH Type=5 | Compressed fields |
<-TSE->
Critical format,
O,R,F bits from RFC 6553 in the TSE
Same I, K flags as in NHC proposal, placed in TSE as well
Compressed fields inferred from I and K flags, 1 to 3 bytes
The trick is that since it is optimized for a case where one of the end points is the  well-known “root” whatever that it is an abstract mesh, and clearly well-known in RPL, and the other end-point may often be the source or the destination of the inner header, in which case it can be elided. The rest of the IP header being IP-in-IP we specify what it must be set to so we can elide it all. It results a very, very efficient compression of the outer IP header, but it is still there when we need it (e.g. we do not need it when the packet stays within the LLN), much better than would be available with 6282.
RPLInstanceID field that is all zeroes, and defines a 'I' flag that, when set, signals that the field is elided.

28. RH3-6LoRH Size indicates the number of compressed addresses (minus1)
|1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN |
Size indicates the number of compressed addresses (minus1)
The form of compression is indicated by the Type as follows:
| Type | Size Unit | < More details on compression
needed in next version >
| | |
| | |
| | |
| | |
| | |
In the case of a RH3-6LoRH, the TSE field is used as a Size, which encodes the number of hops minus 1; so a Size of 0 means one hop, and the maximum that can be encoded is 32 hops. (If more than 32 hops need to be expressed, a sequence of RH3-6LoRH can be employed.)

29. Example use of RH3-6LoRH Root sends 2001:DB8::ABCD forwards
0x80 0x04 <2001:DB8::ABCD> > 1 * 16-bytes address
0x82 0x01 0xCAFE 0xBEEF 0xCA5A -> 3 * 2-bytes addresses
2001:DB8::ABCD forwards
0x80 0x04 <2001:DB8::CAFE> > 1 * 16-bytes address
0x81 0x01 0xBEEF 0xCA5A > 2 * 2-bytes addresses
2001:DB8::CAFE forwards
0x80 0x04 <2001:DB8::BEEF> > 1 * 16-bytes address
0x80 0x01 0xCA5A > 1 * 2-bytes addresses
2001:DB8::BEEF forwards
0x80 0x04 <2001:DB8::CA5A> > 1 * 16-bytes address
2001:DB8::CA5A removes the 6LoRH and routes to dest. in IPHC
In the case of a RH3-6LoRH, the TSE field is used as a Size, which encodes the number of hops minus 1; so a Size of 0 means one hop, and the maximum that can be encoded is 32 hops. (If more than 32 hops need to be expressed, a sequence of RH3-6LoRH can be employed.)

30. RPI-6LoRH <-TSE-> Critical format,
|1|0|0|O|R|F|I|K| 6LoRH Type=5 | Compressed fields |
<-TSE->
Critical format,
<need to indicate whether to remove on penultimate>
O,R,F bits from RFC 6553 in the TSE
Same I, K flags as in NHC proposal, placed in TSE as well
Compressed fields inferred from I and K flags, 1 to 3 bytes
The trick is that since it is optimized for a case where one of the end points is the  well-known “root” whatever that it is an abstract mesh, and clearly well-known in RPL, and the other end-point may often be the source or the destination of the inner header, in which case it can be elided. The rest of the IP header being IP-in-IP we specify what it must be set to so we can elide it all. It results a very, very efficient compression of the outer IP header, but it is still there when we need it (e.g. we do not need it when the packet stays within the LLN), much better than would be available with 6282.
RPLInstanceID field that is all zeroes, and defines a 'I' flag that, when set, signals that the field is elided.

31. Optimized IP in IP
|1|0|1| Length | 6LoRH Type 6 | Hop Limit | Encaps. Address |
Elective format, size of 1 indicates encapsulator is root.
<need to provide compression when not>
Usually, only one byte of data for Hop Limit
Inner (IPHC) hop limit can be compressed elided
If destination downwards is same as that of IPHC,
or root on upward packets => can be elided too
Use RH when destination cannot be elided, examples given.
The trick is that since it is optimized for a case where one of the end points is the  well-known “root” whatever that it is an abstract mesh, and clearly well-known in RPL, and the other end-point may often be the source or the destination of the inner header, in which case it can be elided. The rest of the IP header being IP-in-IP we specify what it must be set to so we can elide it all. It results a very, very efficient compression of the outer IP header, but it is still there when we need it (e.g. we do not need it when the packet stays within the LLN), much better than would be available with 6282.
RPLInstanceID field that is all zeroes, and defines a 'I' flag that, when set, signals that the field is elided.

32. AOB ?

33. Thank you!