06 February 2015 Webex IPv6 over the TSCH mode of IEEE 802.15.4e Chairs: Pascal Thubert Thomas Watteyne Etherpad for minutes: http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true

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

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 http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true ** Recordings and Minutes are public and may be subject to discovery in the event of litigation. *** From the Webex login 3 3 3 3

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

Administrivia

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

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

Architecture

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)

New TOC

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

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

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)

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)

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?

IETF92 meeting request

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

Important Dates http://www.ietf.org/meeting/important-dates-2015.html 2015-02-06 (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. 2015-02-20 (Friday): Preliminary agenda published for comment. 2015-02-25 (Wednesday): Cut-off date for requests to reschedule Working Group and BOF meetings UTC 23:59. 2015-02-27 (Friday): Final agenda to be published. 2015-03-09 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool. 2015-03-09 (Monday): Draft Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool. 2015-03-13 (Friday): Early Bird registration and payment cut-off at UTC 23:59. 2015-03-16 (Monday): Revised Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool.

ETSI plugtest

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

ROLL interim meeting preparation / discussion

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

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

Generic TLV format 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ |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 0 1 |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] 12..16 : BIER-6LoRH [RFCthis]

RPI-6LoRH <-TSE-> Critical format, 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+ |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.

RH3-6LoRH Size indicates the number of compressed addresses (minus1) 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ .. +- -+ |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 > | 0 | 1 | | 1 | 2 | | 2 | 4 | | 3 | 8 | | 4 | 16 | 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.)

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

RPI-6LoRH <-TSE-> Critical format, 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+ |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.

Optimized IP in IP 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ |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.

AOB ?

Thank you!