Light-Weight Implementation Guidance - Prague, IETF80 WG meeting Monday March 28, 2011 Afternoon Session II - 15:10-16:10 Room: Barcelona/Berlin Chairs: Zhen Cao Robert Cragie Minutes of meeting by: Carl Williams (carlw@mcsr-labs.org) Cao stated that this is the first working group meeting for LWIG. The focus is to produce a light-weight implementation guidance document. Cao went over the goals and milestones. Design team has been selected and Carsten Bormann will be editor of document. This was announced on the mailing list. Cao noted that there is room on design team for additional implementers. Cao noted that the IAB held a workshop on March 25 (Prague) on Interconnecting Smart Objects with the Internet. Cao stated that some of the materials will be relevant for things we do here. He pointed us to the position papers and documents at: http://www.iab.org/about/workshops/smartobjects/papers/ Cao went over the agenda outline and asked if anyone had any questions or comments. 1) Agenda for IETF 80 meeting was presented by Zhen Cao - Introduction, Agenda Bashing -- Chairs, 5 min - 6lowpan implementation consideration -- Carsten Bormann (10min) - Minimal IKEv2 Implementation -- Tero Kivinen (10min) - LWIG API Survey of implementations and considerations -- Carl Williams (5min) - Introduction to the Guidance Document and Focus Discussion --- Robert Cragie (30min) Cao asked if anyone had any questions or comments on the agenda. No one had any objections and Cao introduced Carsten Bormann to provide a 10 minute presentation on 6lowpan implementation considerations. 2) 6lowpan implementation consideration -- Carsten Bormann (10min) Carsten Bormann main point of his presentation is that the draft-bormann-6lowpan-roadmap is not contradictory with work that is chartered in 6lowpan. Carsten stated there has been recently been document posted to the 6lowpan called: draft-bormann-6lowpan-roadmap which is meant to fill the position of the 6lowpan implementer's guide that the 6lowpan group has as a milestone in their charter. Carsten stated that this has caused some discussion since the chartering of the light-weight implementation guidance working group (LWIG). Carsten explained the relationship between this implementer's guide and the work that is being done in this working group. Carsten thought it would be a good idea to look at what these two different documents are going to do but before he does that he must provide a little bit of background. Carsten stated that from previous experience that when you build a complex protocol that you need clarifications because there will be different interpretations. For example, when protocol details were initially written it appeared to be clear but it was found that you need some more information there. Carsten said you may need small fixes. Carsten also stated that you need something like a roadmap occasionally because you may have 20 documents and someone needs to explain how those documents fit together. Carsten said that was the background. Carsten also noted that in the ROHC working group that they created such a document which he says is RFC4815 - title is 'RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095'. Carsten stated that it was most useful when it was draft-ietf-rohc-rtp-impl-guide-* (ROHC Implementers Guide). Carsten stated that this draft went through 23 revisions over 5 years. The draft collected information from implementers that explained how the normative specifications for which parts were not clear and which parts needed to be implemented a little bit differently from what the specification seem to be saying. Carsten said that this is the background that he is coming from with this presentation on implementation considerations for 6lowpan. Carsten said that this roadmap document for 6lowpan is attempting to do the same thing (as ROHC roadmap). Carsten stated that when 6lowpan was re-chartered last time we got that implementers guide as part of the new charter. Carsten said that this 6lowpan roadmap document is trying to answer questions like (a) which documents that you have to read to make a 6lowpan; (b) what is defined in a confusing or misleading manner in these set of documents; and (c) what things need to be fixed (in a grander picture). Carsten followed-up by saying if you look at the grander picture 每 that being all three documents that makeup 6lowpan. Carsten stated that this document has just been posted and only list 2 issues that will give you a feeling of what these issues will be. Carsten stated that when we first design 6lowpan was designed for stub networks. As such 6lowpan MTU was set at 1280 (minimum IPv6 allows). Carsten stated that this MTU size doesn't work with RPL 每 which uses 6lowpan as the carrier of tunnels between nodes 每 6lowpan is no longer a stub network and we may have to change this requirement. So what this document does is it contradicts the base specification 每 it states that if you build 6lowpan with RPL then please build 6lowpan with a larger MTU. Otherwise, RPL won't work. Carsten noted that this may be obvious to some at first but stated that if you build 6lowpan first and RPL a year later then you may be in a situation where things just don't work. Carsten stated that is just an example of what you will find in these implementers guides. Carsten then went into 6lowpan issue 2 regarding the use of PAN identifiers. He stated that this is a rather arcane thing we did that we didn't discuss to the end in 6lowpan but in the original specification (RFC 4944 - Transmission of IPv6 Packets over IEEE 802.15.4 Networks) and since the header compression document has made a decision there 每 it only supports one way of doing this 每 somebody needs to point out not to read that part of the base specification and implement it in a different way than is described there. Carsten said that this is really what the roadmap document is really about. It is about changing normative specifications in small places. Not having to re-spin every RFC every half year because we found another little issue but collecting those little issues in one place. And provide the seams that make the things work together as a whole. The target for this 6lowpan roadmap document is it being a Standards Track document 每 unless we decide to re-spin all RFCs in the meantime. Carsten stated that what this document is not doing is providing implementation techniques. Carsten gave a few examples of a few things that should go into a implementers techniques document 每 (1) 6lowpan Fragment forwarding; and (2) CoAP Token handling. Carsten stated that these techniques should go into LWIG implementers document. This technique for example is out there but should be written down and vetted in a working group context. That this for example is a really viable way for implementing this fragment forwarding technique. Carsten says that this doesn't belong in the roadmap document but belongs in this (LWIG) working group. Another example is CoAP which is currently not in the LWIG charter but may come here later. 6lowpan had a lot of discussion on how do you handle tokens and it would be nice to write this up at some point. Carsten stated that there is no contradiction between having a 6lowpan working group document called Roadmap and a light-weight implementers guidance working group document describing techniques. Carsten says there will be a grey area at some point in the middle then we will have to decide where to put it. Carsten emphasized that that won't be a big problem. Cao stated that questions/comments will come during discussion sessions. Cao then introduced next speaker. 3) Minimal IKEv2 Implementation -- Tero Kivinen (10min) Tero stated that this work is about what minimal IKEv2 implementation could look like. Tero stated that minimal IKEv2 implementation only supports initiator end of the protocol, and only supports the initial IKE_SA_INIT and IKE_AUTH exchanges and does not initiate any other exchanges, and replies with empty (or error) message to all incoming requests. Tero stated this means that most optional features of IKEv2 are left out: NAT Traversal, IKE SA rekey, Child SA Rekey, Multiple Child SAs, Deleting Child / IKE SAs, Configuration payloads, EAP authentication etc. Tero noted that some optimizations can be done because of this selection of supported features. Such optimizations can be included in a light-weight implementers guidance document. Tero presented these optimizations. Tero noted that he made this presentation during the IAB workshop the previous Friday as well but changed a few things that may be most interested in this working group. He went over small scale use case example. Questions: Lars: Since you are one of the first ones who is presenting one of these, I am going to use you to ask you some questions. What does light-weight mean? This is one of the points of this working group and I guess my definition is if you look at the original specification and you are doing a light weight implementation you must not violate any of the specification musts, and you should not violate any of the should and you may violate some of the may's. You must not violate any of the musts as then you aren't spec compliant. TCP is liberal in what it accepts and conservative in what it sends. You can send a broken stuff that is not spec conformant and a liberal tcp sender will keep talking and it will work. You want to do a spec compliant protocol for light weight. Is this a light weight IKEv2 spec compliant? Tero: Yes and no. The mandatory feature in IKEv2 is certificates and I left that out. Everything else is there. This implementation will talk to any implementation that is compliant to IKEv2. Lars: It is fine to say that I could make it even more light weight if these musts in the original specification were different. You can got to the group that did them and ask what do you think. That is fine as an outcome. Tero: We need to separate the cases where for example this packet that is mandatory to implement I understand that. But the other thing we need to do is you must be able to send this kind of packet if you support this kind of feature that is something that we don't need to do. For example, in my case I don't want to be sending certificates. Lars: If the feature is optional to support ＃ Tero: No. It is optional to use but mandatory to implement. But it is valid to configure the system not to use it so how is anybody going to find out that you haven't implemented it. You are the only one who first starts talking and if you never use that feature no one knows that you haven't implemented it. Joe Touch(ISI): That is a very important distinction. We have must, should, may and all of those words but other words we don't use are 'and' and 'or'. So we don't say anything about the fact that some of these things like you say. You are the one in control of making the decision and if you never initiated it never becomes a compliance problem. It is important that these documents in this group to make that distinction and make the distinction that some of these things are 'and' or 'must' but only in a 'context' and if we say that that 'context' may never happen other than you never use it or you shouldn't use it. Either way it is ok for us to say we are still compliant even though we don't support it. So I think that is the distinction to be made here. 4) LWIG API Survey of implementations and considerations -- Carl Williams (5min) Carl presented considerations of the API on light weight implementations. Carl stated that the work is about examining the considerations and implications of the constrained physical and stack environments on the API implementation, API specification and application developer. The API considerations document should be a part of the light weight implementation guidance suite of documentation. Carl noted why this is important. He noted that there will be API changes 每 both in specification and he interface between the API and the lower levels (udp, tcp, IP). This will aid implementers of the API by providing documentation and guidance on common experiences learned and recommendations of how to deal with the API in light weight stacks. This understanding will support the needs of the users of the API for these light weight stacks. Carl noted that we don't want to have to invent or learn a whole new way to write networking applications for these devices. The survey portion of the document is the first of two tasks. The survey seeks to collect existing experiences from implementations of IP stacks in constrained devices with a focus on API or application impacts and considerations. TinyOS and uIP are two referenced in the survey so far but seeking other existing implementations including proprietary stacks with APIs. The API implementation considerations include impact on RAM, throughput, cpu utilization and impact on Flash. For example, the need to balance code size for API (libraries, code) and the applications that fit into limited flash. It was noted that the consideration of if the applications will be well-suited to the resulting API changes. Synthesis of collection of experiences is a second task that will allow us to see what is good and what is bad. This also includes detailing the benefits and consequences of varied approaches, scaling issues, etc. The next steps is working with Geoff and to continue to collect implementation experiences for survey. This includes working with IPSO alliance and other implementation. It is important to continue to synthesis these experiences and update the analysis as well as seek new perspectives on things that were not mentioned. 5) Introduction to the Guidance Document and Focus Discussion --- Robert Cragie (30min) What I am now going to do strawman of the considerations document that will lead nicely into the discussion. As a new working group clearly we have a few initial ideas 每 strawman ideas 每 that we want to put out to the group for discussion. In charter we are saying one document so question is that do we want one document that has title 'Guidance for light weight implementations' or should we split into compartmental documents. We would like to get some feedback on. This is about implementation guidance only. We are not trying to create or change any protocol or services. This is informational RFC. We are not trying to develop anything new for light weight implementations. We are going to look at the existing protocol or ones that are currently being developed RFCs, drafts, and see how appropriate they are for light weight and see how we can add additional guidance on how they can be used in light weight implementations. This is not software engineering best practices. We are not to use a link list here or whatever here. It is just guidance. We have to focus on a limited number of protocols. There is a large number of protocols in the IETF and there is only a subset of those that will be really relevant for constrained devices or light weight devices 每 6lowpan, ROLL, but others may be appropriate as well like dhcpv4. Some data plane protocols 每 at the app layer 每 http, CoAP, others 每 XMPP, TFTP; transport layer 每 TCP, UDP, others?; network layer 每 Ipv4/IPv6 and link layer support 每 6lowpan. Robert stated that considerations include what can be left out and what is the bare minimum. Two classes of devices that are constraint are: (1) 'quite constrained' and (2) 'Constrained'. Constraints may be wire-visible and wire-invisible. Protocols listed in charter are: Ipv4, IPv6, UDP, TCP, ICMPv4/v6, MLD/IGMP, ND, DNS, DHCPv4/v6, 6lowpan, and RPL. Jari: The charter does list a number of protocols and the idea is that we stick to those. We can add more if we really think it is necessary but I do think that the working group does have quite a lot on its table already. So lets try to focus on the ones we have on the list and the other thing that I think is very important is that we have many things on your slides and previous discussions lots of potential topics to talk about but if you focus on things that people have implemented. For example, if Tero implemented this version of IKEv2 then that is great because we have some implementation experience that we are backing this guidance with. So if you take that as our guideline in following the implementations than I think you will be fine. Robert mention slides with security protocols that are on the list. He then went over 'Wire-visible' constraints such as fragmentation and reassembly. We can do some implementation optimization on fragmentation. He then went over 'wire-invisible' constraints such as how much buffer you may need for certain scenarios. In these constrained devices you may run out of buffer and we must make sure we do graceful handling of that. Robert noted that this was his straw-man and that he wanted to put categories in place and thought processes and tying the focus on specific number of protocols. Comment: Do you think that we really need to have the categories of highly constrained versus constrained devices. The reason is that these numbers will change and thus the class will change 每 say in a year. That may be dangerous to do. Jari: We should not theorize to much about that at this point. It really depends on what kind of implementers we get. If they have an implementation on a very constrained node then that is fine that is what we are going to describe. Then if we don't have any other implementers than that is all we have. Follow the implementers. Comment: In other working groups we have applicability statement and maybe the chairs sit down and figure out what we do and where. For example we may have applicability statement to say how to tune the parameters. Robert: We won't repeat work done in other working groups. We will just reference that work. Comment: When we formed some of these working groups we were only focused on IPv6 only. You mention IPv4 protocols. Core and 6lowpan are IPv6 only. Jari: Both are in the charter and again let us follow what kind of material we actual get here. There is probable more to say about Ipv6 because it is more complicated. Comment: Should we send message from IETF that we are producing protocols based on IPv6 only. Lars: If you look at the charter it says 'collecting experiences from implementers' and we are not just collecting experiences from implementers of IPv6 but there is value to collect experiences from IPv4 implementations as well. For our work going forward I agree with you that IPv6 is way we want to go but there is something to be learned from having done for IPv4. I haven't seen the critical mass of people coming with IPv6 implementation proposals so that we should exclude the IPv4 ones. Jari: I am not sure there is much practical thing to say about IPv4 implementation nor IPv6 for that matter - it is all about ND 每 there is some room for discussion and all the other protocols on top of it. They are mostly the same anyway regardless if they are IPv4 or IPv6. So I don't see it as big issue. I don't want to cut IPv4 completely away from this working group charter so that we can send a message. We need to take our responsibility and describe the implementation techniques that people are using and will be using going forward. Of course there is more IPv6 stuff here. Carsten: Quickly to clarify what these classes are for 每 I agree with Jari that they aren't for theorizing about. But we had endless discussions about that this technique works on a constrained node and this technique doesn't work on a constrained node and so on and it is useful for the various nodes to clarify their contexts. So we have some rough raw classes in mind for that. Robert: just to summarize we must base this on real implementation experiences. Robert stated that we are out of time and concluded the discussion. He noted that there would be a design team meeting later in week.