Minutes for Light-Weight Implementation Guidance (Room: lwig)

Meeting start time: 5:40pm

Chairs: Introduction, Agenda Bashing

Chairs welcomes audience and refers to Note Well

Ben Poon designated as Note Taker 

Chairs mentions Logistics and blue sheet

One change to agenda, order swap between Zigbee IP Deployment (Carsten Bormann) and Lightweight Implementation Guidance Document (Robert Cragie)

Mehmet Ersue: COnstrained MANanagement (COMAN) Management of Networks with Constrained Devices: Use Cases and Requirements
draft-ersue-constrained-mgmt-02

Management of network and devices, notes 2nd revision of draft

Problem statement, motivation

Aims/goals of COMAN
 
Next Steps
?	Need for more discussion
?	Need for gap analysis

Presenter seek contributors and reviewers
?	COMAN (non-WG) mailing-list: https://www.ietf.org/mailman/listinfo/coman 

Chair opens floor for question/comments
?	Discussion to be held on mailing-list

Carsten Bormann: LWIG guidance document
draft-ietf-lwig-guidance-02 

Reminder of scope

Two classes of constrained, Class 1 and Class 2
?	Discovered during Prague workshop

New section 2, new terminology

Proposal to separate out section 2 and 3.1 into own documents
?	Make useful for more than just LWIG

Next Steps
?	Seeking continued work

Chairs seek comments
?	Also consider a separate implementation-specific document

Chair proposes to make section 2 and 3.1 into separate documents.

Q (Robert): Is the aim to allow the documents to be used by others or not?

A (Carsten): Not for the long term perspective, and at the moment it is better to use other existing terms.

Robert Cragie: ZigBee IP Deployment

Intro to ZigBee IP
?	Co-chair for task group in ZigBee Alliance
?	Protocol work by IETF, interoperability certification work by ZibBee Alliance

Transport Layer
?	TCP, UDP

Network Layer
?	IPv6, 6LoWPAN, SLAAC

Neighbor Discovery
?	Parts of ND, 6LoWPAN ND extensions

Routing
?	RPL, MRHOF objective function RFC, Trickle multicast (progressed to RFC)

Security (1)
?	Link layer security
?	PANA (network access) 
o	draft-yegin-pana-encr-avp to become RFC
o	UDP for 6LoWPAN

Security (2)
?	TLS, TLS cipher suites

Additional IETF Protocols Developed
?	MLE (Mesh Link Establishment), PANA relay, PANA encryption extensions

Implementation
?	Aimed at LWIG class 2 devices, various capabilities and OSs

Restrictions to meet resource constraints
?	6LoWPAN, RPL (not-storing), TLS (2 cipher suites), Buffer

Other Implementation Efficiencies
?	Holistic approach
?	AES-CCM baked-in
?	RPL, ND, MAC optimized
?	Link tables from different protocols
?	Cross-layer management

Status December 2012
?	Specs, PICS, Test plan almost complete
?	Specification Validation Event (SVE) in January 2013

Next Steps
?	Additional details in guidance doc


Q (Zhen): Share test plan with IETF?

A (Robert): Proprietary

Q (Zhen): Conformance or performance testing?

 (Robert): Conformance, part of ZigBee certification program

Matthias Kovatsch: Implementing CoAP on Clas-1 Device
draft-kovatsch-lwig-class1-coap-00

Class 1 Stack Configuration

CoAP Implementation (with Contiki)

Memory Management
?	Static parameters, want deterministic behaviour
?	Often much less than 1280 MTU due to low ram constraints

Message Buffers
?	Cooperative multi-threading

Separate Responses
?	Long lasting resource handlers
?	Split-phase execution
?	API to avoid code duplication

Retransmissions
?	Provides message buffers

Observing
?	Manage observe entries per resource
?	Provide one message buffer per observed resource

Blockwise Transfers
?	Expensive to provide buffer for whole transfer
?	Main sender problem: sonprintf()
o	Make library to perform function

Sleepy Nodes
?	Many drafts, but not suited for 15.4 nodes.

Q (John): Any experience with applying IEEE 802.11e to this?

A (Matthias): No hardware currently available to combine channel hopping and cycling.	 Difficult to see what¡¯s going on with IEEE.

Q (John): Low power specific on Contiki?

Q (Matthias): This is normal 15.4 operation, depends on scheme.

Q (Carsten): Need more info in draft to say how APIs can make integration more efficient.  For example, Java probably won¡¯t do this, need to find libraries that does optimization.

A (Matthias): This model uses resource handlers and fits in a standard framework.

Comment: API is the best way to innovate in this area.

A (Matthias): Difficult part is determining use case, sensors around office space, learning how and what happens in implementations.

What is the use case?  So many ways this can be used.

A (Matthias): Mostly getting String handlers and parsing JSON.  Firmware updates can use flash memory.

Comment: Build firmware in flash, doesn¡¯t change that often.

Hennes Tschofenig: ¡°Lightweight¡± D-TLS
draft-tschofenig-lwig-tls-minimal-01

Binary Code Size 
?	Many choices, select only parts required

Presenter seek comments on what to include in a security document.

Comment (Robert): Use library instead of layered approach, embedded designs usually cross-layer.

Comment (Matthias): Sometimes possible but others maybe not.

Comment (Pierpaolo G): for encryption in ECC, Big Integer Library is the major obstacle and we should share knowledge in this subject

Q: Was it incorporated in transport layer or application only?

A: Implement of D-TLS

Q: Any elliptical curve crypto?

A: RSA Code

Comment (Carsten): Several questions talk about DTLS in library.  Would be good idea to discuss the two, they are very similar.  Initial testing on interoperability and DTLS.

Comment (Hannes): Getting input to share would be good.

Q (Manual D?): Library approach is good.

Comment (Hannes): Tricky part is to balance detail between an IETF RFC and a guidance document. 

Comment (Robert): Libraries are often platform specific, collecting experience is good regardless.

Comment (Matthias): DTLS 1.2 interoperability test server available with description on the website. 

Q (Hannes): What specific parts of transport layer security?

A: Null sec, PSK, public keys

Q: Which record layer?  Elliptical curve?

Q (Hannes): Diffie-Hellman (D-H), shared secret, record layer, different modes?

A: D-H is implemented, looking at other combinations.

Comment (Carsten): Need to understand compression for DTLS.  Need to constraint cipher suites.

Comment (Hannes): Sometimes in the header 11 bytes are redundant, compressing 22 bytes is likely.

Q (Hannes): In the handshake?

A (Carsten): Not normally.

Comment (Hannes): Compression considerations not likely to go in this document.

Comment (Hannes): Original proposal was to use normal transport layer security record layer, but VoIP guys don¡¯t like it due to large header size.  There is an extension that allows change to the record layer.

Comment (Carsten): Include the cypher suite into this.

Q (Hannes): Negotiation possible in TLS 1.2, possible here?

A (Carsten): Cypher suites do this, not here.

A (Carsten): If want new suite, may require new PKI

Comment (Hannes): Before 1.2 not part of ¡°template¡±, expanded by implementation

Comment (Carsten): Focus only on 1.2

Q (Robert): SHA3 supposed to be super improved?

Comment (Carsten): ¡°Sponge¡± construction, great if implement in hardware

Comment (Hannes): SHA3 not as exciting as hoped, likely to move forward but not sure if good for advancement

Comment (Robert): Implementation issue

Zhen Cao: Synchronization Layer: an Implementation Method for Energy Efficient Sensor Stack 
draft-cao-lwig-syn-layer-00
The Problem, Radio is always on, especially in chatty environment
The Idea, Use a synchronization middle layer

Q (Robert): Is this a time-synchronized channel?

A (Zhen): Yes.

Q: Sync time and radio for send and listen or just one?

A: Both

Q: Any considerations for jitter mechanism to lower collision?

A: MAC and PHY does this, not a big deal.

Comment (Carsten): Transmit usually use more power than receive, because it takes longer.  Maybe a new protocol that can combine multiple packets in one transmission?

Q (Matthias): Contiki for 15.4 Tx usually smaller than Rx?

A (Zhen): Results based on another paper

comment (Robert): The graph may include use of other MAC like CDMA

Q: How to aggregate packets?  Multiplex into one large packet?

A: Purpose of draft to start ideas in this area.

Comment: Wireless Sensor Network highly optimized to make work, now adding additional layers to keep things in control.

A: Not necessarily, for example class 1 devices.

Comment: Will be hard to build applications

A: Will be a trade off, either do in application layer, or generalize and ¡°improve¡± tx/rx?

Chair seeks final comments, none offered

Meeting adjourned