6TSCH Webex

05/17/2013

Add note on visibility

• It is our collective responsibility to make 6TSCH visible and attract participant

• Paper @ Industrial Track in esIoT (July)• IERC Cluster Book 2013• ?

Agenda

•BoF in Berlin: 40 minutes•Bootstrapping 5 minutes•6TUS split: 15 minutes.

BoF Request

BoF request form

1) BOF's full name and acronym in brackets:Deterministic IPv6 over IEEE802.15.4e Timeslotted Channel Hopping (6TSCH)

2) AREA under which Working Group or BOF appearsINT

BoF request form

3) Chair(s) Name(s) and e-mail address(es)Michael Richardson suggests it is good that the chairs and people explaining things are not the proponents 4) Agenda (too long?)•TSCH presentation 30mn •Work items and mapping with existing work and WGs 1H •Charter discussion 1H

BoF request form

• 3) Full Description of BOFWG creation BoF on Deterministic IPv6 over the TSCH mode

of IEEE 802.15.4e. The WG will propose an architecture that supports centralized and distributed routing and resource allocation over a TSCH based mesh. The group will resolve the impacts on existing protocols such as RPL and 6LoWPAN. It will define a component that provides the expected link functionality for IPv6 over the TSCH MAC and a G-MPLS switching sublayer, and standardize the protocols and/or protocol extensions to establish time slots between peers and reserve resources along a path. <add links to drafts>

BoF request form

5) CONFLICTS to avoidROLL 6MAN CoAP COMAN INTAREA RTGAREA

6) Expected Attendance : 607) Number of sessions: 18) Length of session: 2 1/2 hours

Marc’s recommendations

Control your scope

A scope that is too large will scare people off

Suggestions:1.Start complex items with requirement draft :

• Centralized computation ?• 6TUS subset ?

2.?

Inspire confidence

People must understand that the WG can achieve deliverables in due time.Suggestions:

1. Say that we:• emulate existing industrial solution for centralized and

TSCH, and Zigbee IP for distributed• produce the missing links either in-house or by pushing

work to other WGs (we do reqs)• e.g. TSCH draft, architecture, coexistence with ISA et

HART, applicability (indus, automation, …)

2. Existing drafts

Clearly present gap analysis and problems to be solved

Suggestions1.Our draft charter has a gap analysis. Keep revalidating as our understanding evolves. 2.Include req drafts as work items. Should start asap3.Spend enough time on charter work as opposed to solution drafts4.?

Clearly propose work items

People must understand that the WG can achieve deliverables in due time.Suggestions1.Our draft charter has work items. Keep revalidating as our understanding evolves.2.Spend enough time on architecture presentation so work items are clearer3.?

Explain why this is IETF work

Why work does not belong to existing WG Suggestions ?1.There is IPv6 over foo and routing area work. Refer to architecture draft2.Reqs are centered on TSCH use cases but work will be pushed elsewhere

Show activity

Suggestions:1.Weekly call2.Drafts and Repo activities3.ML stats (135 members!!!) and archive http://www.ietf.org/mail-archive/web/6tsch/current/maillist.html

4.?

Do not deep-dive in drafts gory details

That would lose the audience.

Suggestions:1. Keep it to Architecture and TSCH drafts2. Req drafts focus?

External relations

Official Liaison work is double edged sword. Mostly keep informal, talk about exchanges.Suggestions:1.Participate to ISA100.202.Participate to IoT 63.Participate to Heathrow group4.Others ?

Network bootstrapping

Network bootstrapping ---+---------------------- | External Network | +-----+ +-----+ | | Router | | PCE/ | | | | NME +-----+ +-----+ | | | Subnet backbone | +--------------------+------------------+ | | | +-----+(RPL root) +-----+(RPL root) +-----+ | | Backbone | | Backbone | | Backbone | | router | | router | | router +-----+ +-----+ +-----+ o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o

1. TSCH network formationNOT completely defined in IEEE802.15.4e! Many

OPTIONAL OPTIONAL features

6TUS6TUS networkformation commands

2. TSCH network – PCE connection / interaction

EBs configuration:- transmission period- slotframeID- cell (i.e., timeOffset and channelOffset)

- Security/ Authentication-Procedure for regulating schedule requests from motes to PCE

splitting the 6tus draft

Current TOC2. 6tus Adaptation Layer

Specification 2.1. Overview 2.2. Link Model 2.3. Data Convey Model 2.4. Commands 2.5. Message Formats 2.6. Time Sequence 2.7. Statistics 2.8. Monitoring

3. Using 6tus 3.1. RPL on 6tus 3.2. GMPLS on 6tus

Commands• Link Commands

– Add/remove hard/soft links• Slotframe Commands

– Add/remove slotframe• Monitoring Commands

– Configure monitoring process• Statistics Commands

– Configure statistics to collect– Retrieve statistics

• Network Formation Commands– Configure Enhanced Beacons

contents– Configure when to send EBs

• Time Source Neighbor Commands– Set a node’s time source neighbor(s)

• Neighbor Commands– Manage the neighbor table

• Queuing Commands– Create a queue– Read queue statistics

• Security Commands– Manage the node’s keying material

• Data Commands– Send and Receive data

Packet Formats• 6tus uses TSCH Payload IEs• Defined by IEEE802154e:

– TSCH Synchronization IE– TSCH Slotframe and Link IE– TSCH Timeslot Template IE– TSCH Channel Hopping IE

• Defined by 6tus– 6tus Opcode IE– 6tus Bandwidth IE– 6tus Generic Schedule IE

• 6tus assembles IEs to form 6tus messages

What 6tus does● Manages hard cells

● “pass-through” layer for PCE● Manages soft cells

● Negotiation protocol● Monitoring function

● Switching based on (implicit) labels

Proposal● 6tus specification

● current draft● minus the negotiation protocol● plus the commands to manage the label switching

● 6tus for centralized scheduling● how to use 6tus in the presence of a PCE● relates protocol between the PCE and the nodes

● 6tus for distributed scheduling● negotiation protocol● monitoring function

● 6tus support for label switching● switching a packet along a track