[07:28:28] pete.stpierre@gmail.com joins the room [07:50:57] mstjohns joins the room [07:56:19] mstjohns leaves the room [07:58:09] hirocomb joins the room [08:00:36] hirocomb leaves the room: Replaced by new connection [08:01:07] mstjohns joins the room [08:01:52] carsten covering basic intro - slide 2 [08:02:29] RFC 3979 reminder given [08:03:48] Agenda overview (page 1) [08:03:58] hirocomb joins the room [08:04:49] agenda available at: http://www.ietf.org/proceedings/08jul/agenda/6lowpan.txt [08:05:20] carsten is given an overview of 6lowpan [08:05:27] "What is 6lowpan" slide 4 [08:06:01] summary: make interesing l2 networks like 802.15.4 look like IPv6 links [08:07:27] scribe note: consolidated slide deck is at: http://www.ietf.org/proceedings/08jul/slides/6lowpan-0.pdf [08:07:44] carsten introducing segment 1: WG status [08:08:21] carsten handed it over to Geoff to talk about industry adoption of the first 6lowpan RFC [08:08:41] there is an upswing in people adopting 6owpan [08:09:05] an alliance called IPSO (IP on Smart Objects) is forming to promote use of 6lowpan in small devices [08:09:13] (end of adverstisement) :-) [08:09:34] Carsten talking about milestones [08:09:41] (from the charter page) slide 6 [08:10:04] two areas we are producing standards documents [08:10:11] HC and bootstraping/ND [08:10:18] the other items are informational [08:10:41] charter 1/6 (slide 7) [08:11:10] nsko joins the room [08:11:13] most time today will be spent on bootstrapping/NS optimizations [08:11:26] pete.stpierre@gmail.com leaves the room [08:13:08] pete.stpierre@gmail.com joins the room [08:13:22] sorry - got dropped. [08:13:37] carsten still recaping WG charter (slide 11) [08:14:01] slide 12: Lowpan Security analysis (charter item 6 of 6) [08:14:35] charter recap finished [08:14:39] arjen joins the room [08:14:44] slide 13: [08:14:55] starting ND/Bootstrapping draft review [08:15:01] 5 drafts in this area [08:15:17] pete.stpierre@gmail.com leaves the room [08:15:42] Jyrki.Soini joins the room [08:15:52] pete.stpierre@gmail.com joins the room [08:16:03] commisioning and bootstrapping: slide 14 [08:16:06] Yuichi IGARASHI joins the room [08:16:10] UlrichHerberg joins the room [08:16:35] commissioning is about human intervention in setup of a device [08:16:47] bootstrapping is automatic steps for setup [08:17:09] commissioning is out of scope of charter [08:17:32] commissioning includes initial security information [08:17:45] bootstrapping - how do the configured nodes come together [08:17:59] may include authentication/transient keying [08:18:30] soyoung joins the room [08:18:54] slide 15 [08:19:07] review of C&B information set [08:19:29] john.zhao joins the room [08:19:50] some items related to routing, other to L2 routing (mesh under) [08:19:59] need header compression [08:20:04] question on previous slide: [08:20:29] do we have to work on commisioning? [08:20:50] Carsten: No. we have a place to work on architecture, which has C issues. [08:21:06] pete.stpierre@gmail.com leaves the room [08:22:06] pete.stpierre@gmail.com joins the room [08:22:11] Carsten: how do we do the bootstrapping. reuse ND, DHCPv6, etc. [08:22:21] maybe we invent a new protocol... [08:22:42] charter bias is to use existing protocols where appropriate [08:23:00] unless we're doing more harm than good by modifying them [08:24:01] slide 17: overview of the next hour [08:24:31] FIrst draft says commssioning, but really is about bootstrapping [08:25:10] K. Kim presenting Commissioning draft [08:25:40] Kim: only have 5 minutes. won't cover details of protocol [08:25:45] will cover open issues [08:26:19] We need to define bootstrapping architecture (bootstrapping requirements and design choice) [08:26:32] Kim: what is necessary information? [08:26:59] should it be different from Wifi or Ethernet? (3rd comissioning slide) [08:27:46] Kim: if there are multiple lowpans, how to select PAN to join? [08:28:22] next slide [08:28:45] scribe note: most of presentation taken directly from slide text [08:29:07] next slide [08:29:16] what is the necessary protocol? [08:29:44] will ND be enough or do we need a LBS (lowpan bootstraping protocol) [08:30:20] next slide "this draft" [08:31:02] defines information base, specifies procedure, defines bootstrapping protocol (LBP) and short address assignment policy [08:31:35] next slide: LIB definition [08:31:45] two parts: pan specific and device specific [08:32:03] next slide: bootstrapping exchange [08:32:21] intvelt joins the room [08:32:53] next slide: secure Lowpan [08:33:04] next slide: example with EAP [08:33:39] next slide: LBP message types [08:34:08] summary: need to define bootstrapping [08:34:14] comments/questions? [08:34:36] zach shelby: I think ND and./or DHCPv6 is a better way [08:34:43] no need for new proto. [08:35:18] David Culler: more useful distinction may be "what steps do we need to communicate vs. what do we need to exchange data once we can communicate" [08:35:42] Geoff M: not sure where it (the draft) fits. [08:36:20] dhcp may not solve some aspects. how do you get on the network in the first place [08:36:46] how do you set channel/pan on 10,000 lights? [08:36:54] geoff done. [08:37:09] Jonathan Hui: many of these things are specific [08:37:26] channels - what if you are channel hoping? how to define things that are link specific. [08:37:45] Kim: Defining a new protocol is just one way. We still need to determine what the actual information really is. [08:38:08] Manual B.: Interested in what's going on here. [08:38:28] Next speaker: Samita C. and 6lowpan ND optimizaiton draft [08:38:55] draft has been around for a while [08:38:59] john.zhao leaves the room: Computer went to sleep [08:39:01] next slide: "Document history" [08:39:12] next slide [08:39:50] goals: minimize mcast, reduce/avoid DAD and support of mesh and star topos. [08:40:06] solution is applicable to other non-mcast netwrks [08:40:43] similar to 16ng [08:41:15] next slide: topo examples [08:41:43] star on left, mesh on right [08:41:50] next slide [08:42:20] john.zhao joins the room [08:42:27] next slide: changes from -04 [08:42:48] next slide [08:42:55] (more changes from -04) [08:44:11] current values are experimental. may allow nodes to not adverstise in next revision [08:44:49] some feedback says values may be high for mobile networks. [08:45:31] next slide [08:46:09] slide garbled. will skip (diagram is in the draft) [08:47:01] next slide [08:47:25] draft includes a set of assumption/requirements for bootstrapping [08:47:37] address assignement/auto-config [08:47:46] dynamic or static v6-router info [08:47:57] secure ND is not part of this doc. [08:48:14] next slide [08:48:21] to do list [08:49:31] UlrichHerberg leaves the room [08:49:55] can this suport full mesh? [08:50:15] It's difficult but may be done at L3 with routing protocol (route over) [08:50:22] next slide [08:50:24] comments? [08:50:48] Geoff: mark said we should take this on as a WG document [08:51:01] Daniel Park: [08:51:57] is this a mesh under issue (questing agenda slide)? [08:52:09] frodek joins the room [08:52:15] Geoff: Samita said it supports mesh under, but can also support L3. [08:53:09] samita done. [08:53:21] next up Erik Nordmark ND registration extension [08:53:35] next slide - motivation [08:54:17] how do we avoid mcast [08:54:32] remove unncessary traffic for non existent addresses [08:54:52] other WG have talked about infering things from DAD messages [08:55:04] next slide [08:55:07] Approach [08:55:21] it's an option to the RA [08:55:30] adds a reg message [08:55:52] set of addresses allowed, soft state, no ack [08:56:36] next slide: security [08:56:56] should be able to use secure ND extention [08:57:10] next slide: open issues [08:57:14] minor issues [08:57:40] issues if registry not on the router [08:57:57] reg period not known (add a lifetime to the message?) [08:58:12] does this draft fit more in 6lowpan or 6man WG [08:58:21] what other reasons are these messages good [08:58:26] for [08:59:23] questions? [09:00:02] Vint Cerf: Q about the model for this network [09:00:29] is it the case the nodes at the end points are not routers, or may the end nodes also be routers? [09:00:39] Geoff: answer - it depends [09:00:58] in some impls, all nodes are the same. [09:01:05] in others, there are FFD and RFDs [09:01:28] nothing in 6lowpan precludes either topo [09:02:16] Vint: some nodes may be able to detect nodes and report, but not actually route packets [09:02:44] 15.4 says two RFD can't communicate directly - only through FFD [09:02:58] David C: those terms are 15.4 specific terms. [09:03:20] David C; question-- isn't this like a heartbeat? [09:03:37] could be renewal of a lease [09:03:52] is heartbeat an architectural component of 6lowpan? [09:04:21] Erik: different between a renewed registraion and a heart beat for reachability [09:05:07] David: If it's going to be a heart beat, we should use it for everything we can (every bit is important) [09:06:07] missed name: asked question about how ND works (missed specific question) [09:06:22] Erik: explained basic aspect of ND [09:06:42] Q: is the soft state sufficient [09:07:04] Erik: if you have redundancy, you can avoid DAD [09:07:08] (whiteboard idea) [09:07:22] john.zhao leaves the room: Replaced by new connection. [09:07:23] john.zhao joins the room [09:08:00] Pascal: I like the heartbeat in some situations, I wouldn't tie heartbeat to registration [09:08:26] mobile node will have to register frequently when it moves. may be difficult to keep state consistent [09:09:07] next speaker: Pascal [09:09:10] whiteboarding [09:09:54] topic: backbone router [09:10:07] first slide: phys topo [09:10:16] (from ROLL industrial req.) [09:11:18] pascal describe the diagram [09:11:23] next slide [09:11:30] BBR draft [09:11:48] ND registration - node registeres with 1 or 2 routers [09:11:53] routers keep hard state [09:12:01] router represents node address on the BB [09:12:12] "Proxy ND" for this. [09:12:41] what is the scope of link local? [09:12:57] how do you DAD as the link changes (if you move) [09:13:23] nodes may attach to multiple BBRs. how does this affect the "link" definition? [09:14:17] maybe all the nodes within a set of proxy ND nodes constitute a "link". [09:14:27] we know we can defend the addresses properly [09:14:36] goal: eliminate mcast ND mesages [09:14:43] avoid RAs avoid NS/NA [09:14:49] (next slide) [09:16:29] pascal is describing the protocol's operation on an ANYCAST address [09:16:34] next slide [09:16:46] mstjohns leaves the room: Replaced by new connection [09:16:47] details of White Board vs. "Cry Out Loud" [09:16:49] mstjohns joins the room [09:17:07] ND is a reactive protocol [09:17:40] this is "cry out loud". [09:17:49] Mobile IP has registered HA addressess (white board [09:17:51] ) [09:18:22] cubicle joins the room [09:18:32] cubicle leaves the room [09:18:52] sureshk joins the room [09:19:10] next slide: what's new in this version? [09:19:29] created new ICMP message [09:19:38] instead of modified NS message [09:20:02] added concept of primary BBR. secondary discussed but not decided on how [09:20:06] arjen leaves the room: Replaced by new connection [09:20:08] arjen joins the room [09:20:13] added well known set of anycast addresses [09:22:01] pascal is discussing the use of each anycast addr [09:22:33] next slide [09:22:45] message format [09:22:51] Binding solicitation [09:23:06] causes hard state setup [09:23:20] looks much like MIP (inspired by it) [09:24:17] next slide [09:24:21] binding conf. [09:24:53] next slide [09:24:57] proxy ND op. [09:25:12] compares usages of ND and proxy ND [09:25:24] much work to still be done [09:25:37] eg - NA override [09:27:20] next slide - references [09:27:49] questions? [09:27:57] David C: [09:28:03] Backbone vs. border router [09:28:16] the border may be a router to other things [09:28:57] Pascal: refered to earlier slide. border router is shown as "gateway" in his diagrams [09:29:12] could be a plain IPv6 router (not nesc. 6lowpan) [09:31:06] pascal: you can have both Backbone and border routers. Or you can have each individually [09:31:24] David and Pascal agree [09:31:43] Samita C: Do you assume there is mesh under inside? [09:31:51] Pascal : we try not to assume that [09:32:26] Samita: Right now backbone routers route link local? [09:32:30] Pascal: yes. [09:32:43] proxy ND allows us to do this [09:33:10] Samita: is Binding solicitation part of ND option? [09:33:30] Pascal: no - we used to trick NS/NA but we created new ICMP message [09:35:28] missed name: part of the problem is can we have a link model on Adhoc networks? [09:35:47] Emmanuel Bacelli [09:36:00] tyvm [09:36:43] there are many discussions in this space on "what is a link" [09:37:35] Pascal: DAD is basically useless when nodes may not hear you and there is no hard state [09:37:55] mstjohns leaves the room: Replaced by new connection [09:37:57] Erik N: are there time points where you need to do things differently wth proxy ND? [09:37:59] mstjohns joins the room [09:38:16] pascal: Proxy ND needs hard state [09:38:43] Erik: need to define behavior when register in two place. [09:39:32] Q; are you assuming only the nodes are mobile. can the BB be mobile? [09:40:05] Pascal: can be, but not really. (a NEMO router) mobile nodes covered later (carsten) [09:40:43] Q: does proxy ND have timeout [09:41:10] Pascal: yes - [09:41:43] carsten asking we move along [09:41:58] Jonathan Hui presenting on ND and autoconf [09:42:15] A route over solution (as ROLL is concerned) [09:42:21] slide 53 in the PDF [09:43:13] route over is good for IP level visibility into radio comms [09:43:20] I can walk up to something and talk to it. [09:43:28] next slide [09:43:40] RFC 4861 not really applicable [09:43:49] john.zhao leaves the room: Replaced by new connection. [09:43:49] john.zhao joins the room [09:44:05] 6lowpan ND and autoconf summary (slide 55) [09:44:29] mstjohns leaves the room [09:44:55] how do we apply more traditional methods in this space [09:44:59] next slide [09:45:16] proposal - IID must be derived from 802.15.4 addrs [09:45:25] no addr resolution procols and caches [09:45:49] local scope - short address [09:46:00] possibly DHCP assigned [09:46:46] next slide [09:46:49] ND Summary [09:48:45] next slide: ND Messages [09:49:35] slide 58: RA Options (prefix info option) [09:50:57] prefix summary option - carry just the header [09:51:15] next slide: stateless autoconf [09:51:25] nothing ground breaking here (Jonathan) [09:51:31] next slide DHCPv6 [09:51:39] 6lowpan routers can be relays [09:51:53] "things just kinda work out on their own" [09:52:02] (slide 60) [09:52:18] Prashant Pillai joins the room [09:52:32] next slide (61) [09:52:43] new IA_6lowpan option for DHCPv6 [09:53:11] next slide [09:53:48] only handing out necessary pieces, node derives the rest [09:53:50] next slide [09:54:04] summary: something simple that supported needs of route over solution [09:54:08] Questions? [09:54:31] Vint: loves simplification, don't get excited about dhcpv6 work [09:54:41] sorry not Vint [09:54:49] Zach speaking [09:55:19] don't see a reason you have to do dhcp. can be applicable, but shouldn't be a requirement [09:55:52] Jon/David culler: shall we call it a whiteboard [09:56:03] Zach: would rather see it use one protocol not many. [09:56:26] Zach: could use both but lets not mandate. [09:56:40] Vint: You just reinvented the packet radio network from the 70s. [09:56:54] You may want to look at how that handled mobility. [09:57:36] Vint: regarding whiteboard. anytime you use anycast with multipel objects, it may be possible each of those objects is indistigushable. there may be need for other mechanisms to insure state is common [09:58:09] Erik N: do all the nods share a /64 [09:58:16] Jon; yes [09:58:50] Erik: from the outside (routing) this has a /64 prefix. What does it look from the inside? [09:59:16] Inside, how do you do the /128 routing for LL vs. global? [09:59:49] David C: are we back to "what is a link"? [10:00:33] Jon: having the diff between LL and global is good for neighbor connections [10:01:09] Erik: how does this work when topo changes? [10:01:27] David C: link local change with structure, global have to be routed. [10:02:03] Erik: but each ll domain would have a unique /64 prefix [10:02:45] Geoff: prefix is actually larger (include PANID?) [10:03:10] Carsten: we're having two discussions what is the Arch - and what are the protocols. [10:03:15] arjen leaves the room [10:03:25] We won't finish route over today. Are there questions on the proto? [10:03:37] Pascal: supports this work, but the devil is in the details. [10:03:45] arjen joins the room [10:03:54] loopless distribution of information [10:04:48] Jon: this is all broadcast based [10:05:35] Q: PIO definition has no prefix length [10:05:41] isn't this a limitation? [10:06:03] Jon: LL is a well known prefix [10:06:17] no notion of "on link" other than LL [10:06:58] frodek leaves the room [10:08:48] Geoff: we need to move on [10:08:53] ask questions on the list -- please [10:09:29] Jon: it's a big proposal. should we need to deal with addr resolution protocols? [10:10:28] Emmanuel Bacelli: in MANET we've worked on this for 10 years and this does not scale very well [10:10:48] Jon: this is trickle based. supression type solution [10:11:36] COmment: draft looks good from our (Hitachi) experience [10:11:38] done [10:11:42] next topic: [10:11:45] way forward [10:11:55] Carsten: what to do with these 5 drafts [10:12:15] carsten summarizing the main topic of each draft [10:12:30] hirocomb leaves the room: Replaced by new connection [10:12:38] it isn't clear we can select one at this point and move on. [10:12:55] we need to look at the differences (and similarities) between these proposals [10:12:57] hirocomb joins the room [10:13:18] the authors of the 3 groups of drafts should talk to each other and look for a common way forward. [10:13:49] Pascal: we should form a design team and make them responsible for pulling things together [10:14:33] we need a design team and a charter for the design team (at a high level) [10:14:49] sureshk leaves the room [10:14:58] Erik N: some of us should sit down later this week. there aren't that many pieces we need to put together. [10:15:16] Carsten: it's 11:25 and we're on header compression [10:15:46] (it's actually 11:15) [10:16:03] Jonathan: header compression draft overview [10:16:13] presenting changes in HC header [10:16:27] next slide (68) [10:16:35] 2 byte encoding [10:16:55] next slide: review on modes of compression [10:17:22] next slide [10:17:27] UDP header compression [10:17:35] checksum compression (from discussion on list) [10:18:02] special case for ISA100 UDP (compressed udp chk.) [10:18:14] next slide: unicast examples [10:18:21] next slide: mcast examples [10:18:24] next slide: discussion [10:18:35] Jon: questions: should this be a WG group? [10:18:51] Q from list: (David C) should we deprecate HC1/HC2 [10:19:07] Erik: does border router regenerate UDP checksum? [10:19:14] Jon: talk to pascal - [10:19:37] Pascal: ISA has defined additional checksum capability. [10:20:06] Prashant Pillai leaves the room [10:20:16] Erik: Seems broken on the part of ISA 100. using a different chk with UDPs protocol number is asking for trouble. [10:20:33] Geoff: any more comments? [10:21:08] Geoff: HC1/HC2 should we dprecate? [10:21:42] Crsten: we should discuss this when we've reached a stronger point on HC completion [10:22:18] Carsten: from the list, feeling is strong to leave HC1/HC2 behind, but this may be premature [10:22:54] David C: argue against this. maybe we take HC in two steps. HC1 only dealt with ll addresses. [10:23:11] layer 4 compression goes in the L4 part of the stack, not the L3 part [10:23:30] important that we start moving in this direction. [10:23:57] JP: agrees with David [10:24:15] Carsten: Context based HC [10:24:28] (Slide 74) [10:25:22] how to compress global prefixes? protocol to reach agreement [10:25:29] next slide: what is the information set? [10:25:41] we can discuss the special cases on the list. [10:25:48] next slide: examples [10:25:59] how do we get agreement on the context and which nodes are part of the agreement [10:26:09] slide 76 [10:27:07] not much tme left so we need to take it to the list [10:27:18] who are the partiest to the agreement on context [10:27:30] 3 minutes left for the last 45 of the agenda. [10:27:42] Carl Williams: mobility considerations [10:27:47] john.zhao leaves the room: Computer went to sleep [10:28:04] Mobility considerations: slide 78 [10:28:20] next slide: global reachability [10:28:32] next slide: interconnect framework [10:28:33] john.zhao joins the room [10:29:15] next slide: next steps [10:29:28] consider mobility upfront in arch documents [10:29:35] should it be a seperate doc or part of the base doc? [10:30:22] Samita: I had an old document on 6lowpan arch requirements. would you like me to resubmit? [10:30:26] Samita will resubmit. [10:30:39] Geoff: we need to figure out on the list what the mobility requirements are [10:31:16] carl and samita to combine their work. [10:31:27] carsten to summarize the rest of the outstand work: [10:31:35] Showed MIB structure (slide 84) [10:31:44] is SNMP model the right approach at all? [10:32:07] arjen leaves the room [10:33:00] Carsten: see slides for remainder of updates [10:33:16] we have updates on routing reqs, use cases and security [10:33:45] hirocomb leaves the room: Replaced by new connection [10:33:58] people interested in security should see Geoff/Carsten after the meeting. [10:34:06] meeting is officiall closed. ty all [10:34:23] hirocomb joins the room [10:34:24] pete.stpierre@gmail.com leaves the room [10:34:40] soyoung leaves the room [10:35:22] Yuichi IGARASHI leaves the room [10:36:33] soyoung joins the room [10:36:41] hirocomb leaves the room [10:36:43] soyoung leaves the room [10:41:16] intvelt leaves the room: Replaced by new connection [10:41:45] intvelt joins the room [10:44:14] john.zhao leaves the room: Computer went to sleep [10:45:31] Jyrki.Soini leaves the room [10:46:52] intvelt leaves the room [10:47:25] john.zhao joins the room [10:55:36] nsko leaves the room: Computer went to sleep [10:55:37] john.zhao leaves the room [12:07:20] Yuichi IGARASHI joins the room [12:07:30] Yuichi IGARASHI leaves the room [12:09:04] Exodus joins the room [12:09:08] Exodus leaves the room [12:35:05] intvelt joins the room [12:35:20] intvelt leaves the room