------------------------------------------ IETF81 LWIG WG meeting minutes (tentative) (Minutes taken by Yoshihiro Ohba) 1. Opening Cao presented goals and milestones. Cao mentioned lwig-guidance draft is under development and needs more input. 2. Agenda bashing. Jari: Let the group know that Samita and Eric are working on energy- aware ND in 6man WG. 3. Guidance for Light-Weight Implementations of the Internet Protocol Suite (draft-bormann-guidance): Cao presented route-over fragment forwarding Angelo: there is a risk of collision in fragmentation. Two fragmented packets may have the same datagram tag. Cao: I don't think collision happens. Angelo: we can talk offline. Olaf presented CoAP guide, including message layer processing Jari: It may be difference between sending and receiving fragm. Just sending messages, more complex impl. receiving can be a bigger problem. Michael: IP fragment? Jari: Yes. Olaf: Block option avoid fragmentation of IP layer. Alex: Is CoAP running proxy? Olaf: Not necessary. Kerry: Device may not use IP. KNX and BACnet prevent use of CoAP proxies. Needs to consider very careful. Jari: Just clarify that CoAP is an IP based protocol. Deployment may use non-IP proxy for non-IP devices. Angelo: What is generating separate responses? A server may need to keep state of requests. Maintaining a state may not be a requirement for servers. Olaf: Server will need to keep state. You need additional memory for template of response. Angelo: Static or dynamic allocation of memory? Olaf: Currently use dynamic Cao: Previous part mentions how to simplify fragmentation. Here you suggest avoiding fragmentation. What is the overall guidance? Olaf: Anyway applications should be aware of L2 that only supports very small packets. Kerry: General question. CoAP uses retry mechanism such that if response does not come back client retry. In your view, it is up to server? Olaf: Server probably needs to keep request state for that purpose. Kerry: It is a uniform interface for http and coap? (from jabber): These are solved by message ids. Jari: Process comment. If something is wrong with the CoAP protocol, it should be solved by CORE WG. Alex: Comment about risk of collisions. If collisions happens, it can consume bandwidth. -- Token handling Olaf explained that default vaule 0 is used while not pipelining. Need non-0 for multiple outstanding requests. Angelo: There is a problem with token. Token will be request/response layer. We are interested in msg layer. Olaf: I don't separate clearly the two layers. Angelo: Keep the token in some layer-violating way cause some problem. 4. Yoshihiro presented PANA on behalf of Mitsu Kanda 5. Jari Arkko presented Tiny CoAP sensors (draft-arkko-core-sleepy-sensors). Jari: Prototype implementation on ARM-based platform. Implemented protocols: Ethernet, IPv6, UDP, COAP, XML, and appliation, multicast, checksums msg and device IDs. No configuration is needed. Jari claims that CoAP communication model is wrong. Angelo: Could consider use of some L2 features of radio to address communication issue. Jari: Cellular does L2 mechanisms for sleepy nodes. Probably needs both L2 and higher layer optimization. Michael: L2 will try to synchronize with beacons. Lots of optimized way may not be necessary with using L2 features. Jari: Wired is special. Alex: There is an RFC giving code of checksum. Implementors need guideline on how to implement checksum. Michael: Is there a pseudo header? Jari: Yes. Michael: If you preserve the RAM, it drains power. Kerry: What is observe? Who is observing who? You are just multicasting data. Jari: This is a very different way to observe data. Oscar: What would be the key type message to use template? Jari: Such as DHCP response and CoAP observe request. Michael: dot decimal format should be ok. Cao: Any buffer? Jari: There is one buffer. Cao: In 6lowpan, implementation complexity is a lot. Jari: Communication model is important. Alex: In your draft communication model is very different from other usages. Is your implementation using network byte order or host byte order? Jari: Depending on CPU, the types of byte orders are the same. Ralph: You are not changing protocols, but you are very careful what part of the protocol needs to be considered. OTOH, you address a single deployment scenario instead of general deployments. Ralph: Are you really getting IPv6 at this point? Jari: No need for DHCP (joking). Protocols give you flexibility to choose the right design. Ralph: What we are getting by having IP on these devices? Alex: I would say this effort is a future proof. Jari: Answering to Ralph. I want to get rid of small Ethernet switch with IP stack to connect my tiny devices to IP network. Michael: Another answer to Ralph. Example: Temperature sensors. You need specific box to talk to. Important thing is you plug-in the device and you can use IP-based tools to analyze protocols, etc. You need to rely on a particular manufacturer to connect it to the network. Jari: I would like to have general purpose technologies. Kerry: If you have IP, you can measure temperature and send it remote. - HTTP-CoAP (by Angelo) Angelo claims that http-coap proxy requires cross-protocol URI mapping. Identification of cross-protocol URIs is needed. Cao: It is stateful, isn't it? Angelo: Having state can reduce the network load. Cao: How the proxy determine to do translation or not? Angelo: It's based on static configuration. Dynamic configuration can be a next step. Alex: Is this prosy using socket interface or something else? Angelo: You can use whatever. My implementation uses squid module with sockets.