1. doc.: Submission, Slide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [IG 6tisch Opening Report for Jan 2015 Session] Date Submitted: [11 Jan 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 January 2015 Session.] Abstract:[Opening Report for the Jan 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-0021-00)  Monday 12 January, PM1:  802.15.4 Revision status presented to 6TISCH (doc 15-15-0034-00)  Status of IETF 6TiSCH  6tisch issues discussion  RPL overhead  Security  ReCharter  6tisch-802.15 Liaison discussion  Next Meeting – IETF92, Dallas; 22 – 27 March 2015

3. doc.: Submission, Slide 3 6TISCH Status  TSCH draft completed and moved to the IESG for publication  Completed last call for minimal.  Changes: state that we are not using the beacon to synchronize, sync is only achieved by data packets, beacons are not used to synchronize  what is the coverage of the minimal draft in terms of security  minimal draft should not address all the lifetime of a device, so it can be assumed that minimal starts after the key is known.  Issue on how to compress the routing headers.  we do not have any draft that we can point to indicating how to compress. We depend on other WG that need to adopt that proposals.  Options for the routing header:  delay minimal  use the default current mechanism, i.e. not compressing the RPL extension headers.  Completed last call for CoAP draft

4. doc.: Submission, Slide 4 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.

5. doc.: Submission, Slide 5 6TISCH ISSUES - RPL overhead Summary about RPI/RH3 discussions  talk last week to find a solution to compressing the RPL packets  Three possible outcomes: 1.no changes to existing specs 2.only reset the Flow Label to 0 inside the LLN. Flow Label cannot be used for RPI 3.free use of the Flow Label as long as does not goes out of the LLN.  Note: 6man is opposed to use the Flow Label to carry RPL information

6. doc.: Submission, Slide 6 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

7. doc.: Submission, Slide 7 6TISCH ISSUES - RECHARTER Current Charter:  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.  Potential new items  Join process  Dynamic scheduling  OTF  Chunks appropriation  DetNet/tracks

8. doc.: Submission, Slide 8 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.

9. doc.: Submission, Slide 9 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.

10. doc.: Submission, Slide 10 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.

11. doc.: Submission, Slide 11 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.

12. doc.: Submission, Slide 12 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

13. doc.: Submission, Slide 13 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.

14. doc.: Submission, Slide 14 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.

15. doc.: Submission, Slide 15 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.

16. doc.: Submission, Slide 16 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.

17. doc.: Submission, Slide 17 6TISCH ISSUES – 6tisch-802.15 Liaison discussion Email sent from Rene Struik on 9 Dec 2014 During the 6tisch meeting of IETF-91, I asked the question how one would be sure the 802.15.4 revision spec would satisfy the needs of 6tisch. At the time, it was suggested that 6tisch-802.15 liaison would take care of this. I have a question here, though, since I have never seen any discussion on this "liaison" in 6tisch. Shouldn't one have more transparency here of who is representing 6tisch here and that this would liaison would really address 6tisch's technical interests? I know that the set of people participating in 6tisch and 802.15 does have a non-empty intersection (i.e., some participate in both). While I do acknowledge the experience of those people, this does not necessarily mean they can speak for 6tisch's interests, at least not without consensus. I do realize there is some tension here, since IEEE operates in a different way than IETF, but I think this is an important enough topic to raise this.

18. doc.: Submission, Slide 18 6TISCH ISSUES – 6tisch-802.15 Liaison discussion Email from Romascanu, Dan (Dan) 12/10/2014 5:23 AM Hi, The 6tisch WG has the option of nominating a Liaison Manager to the IEEE 802.15 WG. This is not always necessary and not always the best way of communicating with peer organizations which the IETF works with in close collaboration like the IEEE 802 WG but it can be done if the WG feels it is needed. See http://www.ietf.org/id/draft-bradner-ietf-liaisoning-00.txt (work in progress) For useful information about the responsibilities of the IETF liaison managers, and the process of nominating them.http://www.ietf.org/id/draft-bradner-ietf-liaisoning-00.txt Ted as Shepherding AD and myself can help you with further information. Regards, Dan (speaking as IETF liaison manager to the IEEE-SA)

19. doc.: Submission, Slide 19 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

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

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

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

23. doc.: Submission, Slide 23 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.