1. doc.: Submission, Slide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [IG 6tisch Opening Report for March 2015 Session] Date Submitted: [9 Mar 2015] Source: [Patrick Kinney] Company [Kinney Consulting LLC] Address [Chicago area, IL, USA] Voice:[+1.847.960.3715], E-Mail:[pat.kinney@ieee.org] Re: [IG 6tisch Opening& Closing Report for March 2015 Session.] Abstract:[Opening Report for the March Session] Purpose:[] Notice:This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release:The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15.

2. doc.: Submission, Slide 2 IG 6T Meeting Goals (Agenda 15-15-0184-00)  Monday 9 March, PM2:  Status of IETF 6TiSCH  6tisch issues discussion  RPL overhead  Security  ReCharter  Next Meeting – IETF92, Dallas; 22 – 27 March 2015

3. doc.: Submission, Slide 3 The IEEE-SA strongly recommends that at each WG meeting the chair or a designee: –Show slides #1 through #4 of this presentation –Advise the WG attendees that: The IEEE’s patent policy is consistent with the ANSI patent policy and is described in Clause 6 of the IEEE-SA Standards Board Bylaws; Early identification of patent claims which may be essential for the use of standards under development is strongly encouraged; There may be Essential Patent Claims of which the IEEE is not aware. Additionally, neither the IEEE, the WG, nor the WG chair can ensure the accuracy or completeness of any assurance or whether any such assurance is, in fact, of a Patent Claim that is essential for the use of the standard under development. –Instruct the WG Secretary to record in the minutes of the relevant WG meeting: That the foregoing information was provided and that slides 1 through 4 (and this slide 0, if applicable) were shown; That the chair or designee provided an opportunity for participants to identify patent claim(s)/patent application claim(s) and/or the holder of patent claim(s)/patent application claim(s) of which the participant is personally aware and that may be essential for the use of that standard Any responses that were given, specifically the patent claim(s)/patent application claim(s) and/or the holder of the patent claim(s)/patent application claim(s) that were identified (if any) and by whom. –The WG Chair shall ensure that a request is made to any identified holders of potential essential patent claim(s) to complete and submit a Letter of Assurance. –It is recommended that the WG chair review the guidance in IEEE-SA Standards Board Operations Manual 6.3.5 and in FAQs 12 and 12a on inclusion of potential Essential Patent Claims by incorporation or by reference. Note: WG includes Working Groups, Task Groups, and other standards-developing committees with a PAR approved by the IEEE-SA Standards Board. Instructions for the WG Chair Slide 3

4. doc.: Submission, Slide 4 Participants, Patents, and Duty to Inform All participants in this meeting have certain obligations under the IEEE-SA Patent Policy. Participants: l “Shall inform the IEEE (or cause the IEEE to be informed)” of the identity of each “holder of any potential Essential Patent Claims of which they are personally aware” if the claims are owned or controlled by the participant or the entity the participant is from, employed by, or otherwise represents l “Personal awareness” means that the participant “is personally aware that the holder may have a potential Essential Patent Claim,” even if the participant is not personally aware of the specific patents or patent claims l “Should inform the IEEE (or cause the IEEE to be informed)” of the identity of “any other holders of such potential Essential Patent Claims” (that is, third parties that are not affiliated with the participant, with the participant’s employer, or with anyone else that the participant is from or otherwise represents) l The above does not apply if the patent claim is already the subject of an Accepted Letter of Assurance that applies to the proposed standard(s) under consideration by this group Quoted text excerpted from IEEE-SA Standards Board Bylaws subclause 6.2 l Early identification of holders of potential Essential Patent Claims is strongly encouraged l No duty to perform a patent search Slide #1 Slide 4

5. doc.: Submission, Slide 5 Patent Related Links All participants should be familiar with their obligations under the IEEE-SA Policies & Procedures for standards development. Patent Policy is stated in these sources: IEEE-SA Standards Boards Bylaws http://standards.ieee.org/guides/bylaws/sect6-7.html#6 IEEE-SA Standards Board Operations Manual http://standards.ieee.org/guides/opman/sect6.html#6.3 Material about the patent policy is available at http://standards.ieee.org/board/pat/pat-material.html Slide #2 If you have questions, contact the IEEE-SA Standards Board Patent Committee Administrator at patcom@ieee.org or visit http://standards.ieee.org/board/pat/index.html This slide set is available at http://standards.ieee.org/board/pat/pat-slideset.ppt Slide 5

6. doc.: Submission, Slide 6 Call for Potentially Essential Patents If anyone in this meeting is personally aware of the holder of any patent claims that are potentially essential to implementation of the proposed standard(s) under consideration by this group and that are not already the subject of an Accepted Letter of Assurance: –Either speak up now or –Provide the chair of this group with the identity of the holder(s) of any and all such claims as soon as possible or –Cause an LOA to be submitted Slide #3 Slide 6

7. doc.: Submission, Slide 7 Other Guidelines for IEEE WG Meetings l All IEEE-SA standards meetings shall be conducted in compliance with all applicable laws, including antitrust and competition laws. l Don’t discuss the interpretation, validity, or essentiality of patents/patent claims. l Don’t discuss specific license rates, terms, or conditions. l Relative costs, including licensing costs of essential patent claims, of different technical approaches may be discussed in standards development meetings. l Technical considerations remain primary focus l Don’t discuss or engage in the fixing of product prices, allocation of customers, or division of sales markets. l Don’t discuss the status or substance of ongoing or threatened litigation. l Don’t be silent if inappropriate topics are discussed … do formally object. --------------------------------------------------------------- See IEEE-SA Standards Board Operations Manual, clause 5.3.10 and “Promoting Competition and Innovation: What You Need to Know about the IEEE Standards Association's Antitrust and Competition Policy” for more details. Slide #4 Slide 7

8. doc.: Submission, Slide 8 6TISCH Status  TSCH draft approved by IESG  Completed last call for minimal.  Completed last call for CoAP draft  Using IEEE802.15.4e TSCH in an IoT context: Overview, Problem Statement and Goals draft-ietf-6tisch-tsch-06  6tisch-Security group seems dysfunctional, noting the polarization between members Rene Struik and Pascal Thubert.

9. doc.: Submission, Slide 9 6TISCH Status Email from WG Chair to WG requesting consensus on RPL use in 6tisch We are now in last call for draft-ietf-6tisch-minimal-04 which describes an interoperable operation of RPL over 802.15.4e TSCH. In order to guarantee interop, the draft must indicate which compression technique to use for the RPL option, and, if any, the RH3 as well. The question was apparently solved at the ROLL meeting in Toronto, and we were going to use the IPv6 flow label to carry the RPI, with no compression for the RH3. Adrian noted that since this is a deviation to RFC 6437, we should go to 6MAN to validate. We went to 6MAN in April and got support from Brian Carpenter. The ask in 4 points was discussed again in Hawaii. But still no final decision to date that we could reset/reuse the flow label in LLNs. Considering the lack of progress at 6MAN earlier in the year, we studied an alternate compression technique for the RPI at 6lo. Decision in Hawaii was that the NHC draft could not be accepted as is, since we should compress also the RH3, and without a clear view of how that would happen, the details of the NHC compression could not be determined. So the NHC approach was abandoned and we proposed a new 6lowpan routing header that would reuse for Route-over the 1/3 of the total dispatch space that is used for Mesh header in Mesh-under. There were interesting discussions and an update but there we are, no WG document anywhere that we can reference, and no consensus that 6lo will adopt that work. Yet we need to choose one compression for the minimal version that we will submit to IESG. At some point we hoped that the NHC would cut it but as I said, the meeting in Hawaii left us with little hope that this would happen. So what should we do now? I think we need to call to 6lo and 6MAN for a decision on the topics we have been asking. And since a decision may not come in time, we also need to define our default.

10. doc.: Submission, Slide 10 6TISCH ISSUES - Security Layer-2 security aspects for the IEEE 802.15.4e MAC draft-piro- 6tisch-security-issues-03  This draft focuses on layer-2 security aspects and describes standard compliant procedures for configuring layer-2 security services in IEEE 802.15.4e-based Low-power and Lossy Networks. In particular, main features covered by this document are:  a review of security aspects presented in both IEEE 802.15.4 and IEEE 802.15.4e specifications, with particular attention to the set of parameters that need to be set for enabling security services at the MAC layer  the definition of types and properties of layer-2 keys  the classification of possible secure network configurations, which include Fully Secure, Unsecure, Partial Secure, and Hybrid Secure networks  the description of a set of consecutive steps (i.e., Setting-up, Bootstrap, Join, and Key Negotiation phases) that are required to establish a layer-2 secure link among a couple of nodes  the design of a lightweight Key Management Protocol useful for negotiating a per-peer layer-2 key

11. doc.: Submission, Slide 11 IETF 92 6TISCH Agenda- Monday Distributed Scheduling OTF (Diego) [30 min] DetNet draft-finn-detnet-architecture (Norm) [20 min] draft-gunther-detnet-proaudio-req (Craig) [10 min] draft-wetterwald-detnet-utilities-reqs (Patrick) [10 min] 6TiSCH reqs (Chonggang) [10 min] Wrap up for rechartering [10 min]

12. doc.: Submission, Slide 12 IETF 92 6TISCH Agenda - Thursday Thursday -------- Last Call Status [40 mins] draft-ietf-6tisch-tsch(Thomas) draft-ietf-6tisch-minimal (Xavi) draft-ietf-6tisch-architecture (Pascal) draft-ietf-6tisch-terminology (Maria-Rita) Other Drafts [30 mins] draft-ietf-6tisch-6top-interface (Qin/Xavi) draft-wang-6tisch-6top (Qin/Xavi) draft-ietf-6tisch-coap (Raghuram/Pouria) Plugtest [10 mins] Security [30 mins] DT status and design goals (Michael) draft-struik-6tisch-security- architecture-elements (René) Rechartering [40 mins] Summary of Monday's meeting Scheduling goals and deliverables Security goals and deliverables

13. doc.: Submission, Slide 13 6TISCH ISSUES - IoT Network Formation The LLC needs to control the way the network is formed, including how new nodes join, and how already joined nodes advertise the presence of the network. The LLC needs to: 1.Define the Information Elements included in the Enhanced Beacons advertising the presence of the network. 2.For a new node, define rules to process and filter received Enhanced Beacons. 3.Define the joining procedure. This might include a mechanism to assign a unique 16-bit address to a node, and the management of initial keying material. 4.Define a mechanism to secure the joining process and the subsequent optional process of scheduling more communication cells.

14. doc.: Submission, Slide 14 6TISCH ISSUES - IoT Network Maintenance Once a network is formed, the LLC needs to maintain the network's health, allowing for nodes to stay synchronized. The LLC needs to: 1.Manage each node's time source neighbor. 2.Define a mechanism for a node to update the join priority it announces in its Enhanced Beacon. 3.Schedule transmissions of Enhanced Beacons to advertise the presence of the network.

15. doc.: Submission, Slide 15 6TISCH ISSUES - IoT Multi-Hop Topology RPL, given a weighted connectivity graph, determines multi-hop routes. The LLC needs to: 1.Define a mechanism to gather topological information, node and link state, which it can then feed to RPL 2.Ensure that the TSCH schedule contains cells along the multi-hop routes identified by RPL 3.Where applicable, maintain independent sets of cells to transport independent flows of data.

16. doc.: Submission, Slide 16 6TISCH ISSUES - IoT Routing and Timing Parents At all times, a TSCH node needs to have a time source neighbor it can synchronize to. The LLC therefore needs to assign a time source neighbor to allow for correct operation of the TSCH network. A time source neighbors could, or not, be taken from the RPL routing parent set.

17. doc.: Submission, Slide 17 6TISCH ISSUES - IoT Resource Management A cell in a TSCH schedule is an atomic "unit" of resource. The number of cells to assign between neighbor nodes needs to be appropriate for the size of the traffic flow. The LLC needs to: 1.Define a mechanism for neighbor nodes to exchange information about their schedule and, if applicable, negotiate the addition/ deletion of cells 2.Allow for an entity (e.g., a set of devices, a distributed protocol, a PCE, etc.) to take control of the schedule

18. doc.: Submission, Slide 18 6TISCH ISSUES - IoT Dataflow Control TSCH defines mechanisms for a node to signal it cannot accept an incoming packet. It does not, however, define the policy which determines when to stop accepting packets. The LLC needs to: 1.Define a queuing policy for incoming and outgoing packets. 2.Manage the buffer space, and indicate to TSCH when to stop accepting incoming packets 3.Handle transmissions that have failed. A transmission is declared failed when TSCH has retransmitted the packet multiple times, without receiving an acknowledgment. This covers both dedicated and shared cells.

19. doc.: Submission, Slide 19 6TISCH ISSUES - IoT Deterministic Behavior As highlighted in [RFC5673], in some applications, data is generated periodically and has a well understood data bandwidth requirement, which is deterministic and predictable. The LLC needs to: 1.Ensure timely delivery of such data. 2.Provide a mechanism for such deterministic flows to coexist with bursty or infrequent traffic flows of different priorities.

20. doc.: Submission, Slide 20 6TISCH ISSUES - IoT Scheduling Mechanisms Several scheduling mechanisms can be envisioned, and possibly coexist in the same network. For example, [I-D.phinney-roll-rpl-industrial-applicability] describes how the allocation of bandwidth can be optimized by an external Path Computation Element (PCE). Another centralized (PCE-based) traffic- aware scheduling algorithm is defined in [TASA-PIMRC]. Alternatively, two neighbor nodes can adapt the number of cells autonomously by monitoring the amount of traffic, and negotiating the allocation to extra cell when needed. An example of decentralized algorithm is provided in [tinka10decentralized]. This mechanism can be used to establish multi-hop paths in a fashion similar to RSVP. The LLC needs to: 1.Provide a mechanism for two 6TiSCH devices to negotiate the allocation and deallocation of cells between them 2.Provide a mechanism for device to monitor and manage the 6TiSCH capabilities of a node several hops away 3.Define an mechanism for these different scheduling mechanisms to coexist in the same network.

21. doc.: Submission, Slide 21 6TISCH ISSUES - IoT Secure Communication Given some keying material, TSCH defines mechanisms to encrypt and authenticate MAC frames. It does not define how this keying material is generated. The LLC needs to: 1.Define the keying material and authentication mechanism needed by a new node to join an existing network 2.Define a mechanism to allow for the secure transfer of application data between neighbor nodes 3.Define a mechanism to allow for the secure transfer of signaling data between nodes and the LLC.

22. doc.: Submission, Slide 22 Meeting Accomplishments  802.15.4 Revision status presented to 6TISCH (doc 15-15-0034-00)  Overview and status of 6TISCH project  Issues include:  RPL Hop-by-Hop flow label size (+8 octets), and security architecture  802.15.4 TSCH timings must change per band to accommodate data rates, etc.  Numerous mistakes in TSCH text must be corrected

23. doc.: Submission, Slide 23 IETF 6TISCH Mailing List Information

24. doc.: Submission, Slide 24 IETF 6TISCH call information

25. doc.: Submission, Slide 25 IG 6TISCH reflector information

26. doc.: Submission, Slide 26 IETF 6tisch Working Group Scope 6tisch Goal: The 6tisch Working Group is focused upon enabling IPv6 over the TSCH mode of the IEEE802.15.4e standard. The extent of the problem space for the WG is one or more Low Power and Lossy Networks (LLNs), eventually federated through a common backbone link via one or more LLN Border Routers (LBRs). Work Item 1: Produce "6TiSCH architecture" to describe the design of 6TiSCH networks. This document will highlight the different architectural blocks and signaling flows, including the operation of the network in the presence of multiple LBRs. Initially, the document will focus on distributed routing operation over a static TSCH schedule. Work Item 2: Produce an Information Model containing the management requirements of a 6TiSCH node. This includes describing how an entity can manage the TSCH schedule on a 6TiSCH node, and query timeslot information from that node. A data model mapping for an existing protocol (such as Concise Binary Object Representation (CBOR) over the Constrained Application Protocol (CoAP)) will be provided. Work Item 3: Produce "Minimal 6TiSCH Configuration" defining how to build a 6TiSCH network using the Routing Protocol for LLNs (RPL) and a static TSCH schedule. It is expected that RPL and the Objective Function 0 (OF0) will be reused as-is.