AGENDA ROLL - IETF 96 15:50-17:20 Wednesday Afternoon session II Time: 90 minutes Topic Time Presenter Status of the working group ----------------------------------------------- 15:50 - 15:52 (2 min.) --------- Peter/Ines Use of rpl info draft - draft-ietf-roll-useofrplinfo ---------------------- 15:52 - 16:10 (18 min.) -------- Michael Richardson DIS Modifications - draft-gundogan-roll-dis-modifications ------------------ 16:10 - 16:20 (10 min.) -------- Cenk Gündogan Source-Routed Multicast for RPL - draft-bergmann-bier-ccast ---------------- 16:20 - 16:35 (15 min.) -------- Carsten Bormann Mpl Forwarder select - draft-vanderstok-roll-mpl-forw-select --------------- 16:35 - 16:45 (10 min.) -------- Peter van der Stok AODV-RPL - draft-satish-roll-aodv-rpl -------------------------------------- 16:45 - 16:55 (10 min.) -------- Charles Perkins No-Path DAO Problem Statement - draft-jadhav-roll-no-path-dao-ps-00 -------- 16:55 - 17:05 (10 min.) -------- Rahul Jadhav Charter discussion + AOB --------------------------------------------------- 16:05 - 17:20 (15 min.) -------- Peter and Ines ===== Meeting starts 15:50 Note Well Agenda [15:51] Status of the working group (Peter/Ines) Milestones WG Drafts, related drafts [15:52] DIS Modifications (Cenk Gündogan) Recap on what DIS is. Explains current state. Rahul : RFC6550 does forbid to send CO in multicast DIO. Can configuration option can be sent as part of multicast option Cenk: Yes Cenk explains case of node joining the network, with current situation (RFC6550). Does not know routers, hence uses multicast DIS, hence multicast DIOs and Trickle timer reset. Lots of activity. Wants to improve this behavior by having quiter behavior. 3 behaviors to improve: - DIS type and Trickle timer Proposes DIS flags to have better control on responses. Also response spreading in time if collisions are expected. - Selectivity of DIS requests Explains current behaviour of selectivity of multicast DIS messages and proposed improved behavior. Rahul: multicast DIO may make more sense. Pascal: agrees with this. Question: gives the control to device instead of to the network? Dominique: some networks are planned, density is known, desired behavior is provisioned into the nodes. - Information carried by unicast DIO. Desired: be able to tell in the DIS which information should be included in DIO response Proposed R flag and TLV to do that. Concludes with current proposals. Questions postponed to charter discussion Emmanuel Baccelli: implementation already available in RIOT, play with it! [16:06] Use of rpl info draft (Michael) Meant to document when to use IP-in-IP, when to use RPI option, when to use RH3? Useful to document, as well as to prepare work on compression of these. Now 2460bis might change the premises of this! The 6man wg put a note saying *nodes* along the path will examine and process the Hop by Hop option if explicitely configured to do so. Pascal: this is about routers. Still cannot insert or delete an extension header (such as RH3). Pascal: "insertion ... * can result * .. " doesn't mean you aren't allowed to do it. Michael goes through illustrative graph. From RPL-aware node to non-RPL-aware node, with current situation and then with 2460bis. Don Sturek: what DAO option did node E use to tell everybody about node G? Pascal: ... E bit = external. Michael: in the absence of information that node G is RPL-aware, node F has to assume that this is the case and use IP-in-IP. Don: how does F know G is part of the same RPL domain? Michael: text assumes that if same prefix, is in hte DODAG. Don: bad assumption. E.g. other DODAG ....<< please fill in>>> Michael: agreed. Must pessimistically use IP-in-IP. Michael goes through second example. Without and with 2460bis. Notice that packet received is from un-anticipated node, but payload ok. Third example: going out to the internet. No change in node-to-node in non-storing mode, always had to send to the root anyway. Michael solicits help to word the explanation. Also about the E bit propagation. Don: in the example, how could you use link local addresses? Michael: in this exemple, IP-in-IP is hop by hop, destination is neighbor. E.g. node E to node B. Header only goes a single hop. So could use link-local address. May compress better (MAC address). Pascal: some devices may have more than one radio. Link-local might be only choice. [16:28] Source-Routed Multicast for RPL (Carsten Bormann) these slides fell off IETF95 meeting. In storing mode, RPL multicast creates state everywhere. What about non-storing mode? Source routing needs to enumerate all forwareders and listeners. BIER WG for bit-indexed multicast replication. Enumeration in bit map. Needs stable map of all routers (??) This draft proposes to use Bloom filter. Makes use of hash function, so false positives create spurious transmission. This wastes energy, but behavior still functionally correct. How bad is energy waste? To be compared to energy saved by sending less packets. Goes through numerical analysis. Up to 100 forwarders still ok under simulated conditions. Introduces MLAO. Might use a 6LoRH header. Implemented in Contiki in 2013 (along with a non-storing mode!) Rahul: for Bloom fileter to work, set of hash functions have to be standardized. Carsten: yes, or use a parameter. Olaf: we used SHA256 Rahul: Carsten: SHA256 may be already in your node. Needs a little more work and decide for one. xxx: number of links? Carsten: decision on each outgoing interface. Depends on what you call links. Carsten: designed so that bitmap filled on average in half. Counting the forwarders that get the packet. xxx: Emmanuel Baccelli: most wireless nodes usually have one outgoing interface. Carsten: dense network and multicast to 80% of nodes, lots of false positive, but not that bad because message already goes to most nodes. xxx: algorithm to compute the number of bits given the info known on the network? Ines: short on time, bring this discussion to the mailing list Olaf Bergmann: these numbers represent a theoretical probability of collision. Pascal: one desicsion is Bloom vs bits. Also indicating outgoing interface vs destination. In Bier.. Carsten: that would work for storing mode. [16:46] Mpl Forwarder select (Peter van der Stok) situation is dense network with MPL forwarding which creates Lots of forwarding. Would like to reduce the number of forwarders. Wants algorithm that automatically selects the forwarders. Network is assumed to be relatively stable. Goes through state to be maintained and protocol Selection algortihm is: order neighbors, when own node at top, select yourself. Simulations seem good. Stability criterion to have the algorithm work corre ctly is not well defined yet. Handling of node departure still to be investigated. Justin Dean (chair of MANET): trying to build prices at MANET right now that could be useful to you. [16:52] AODV-RPL (Charles Perkins) AODV good scalability characteristics. Would do a good job at point to point networkin in LLN. Copes with bidirectional but asymmetric links. This extends P2P-RPL RFC6997 Would be interesting to know proportion of RPL networks doing non-storing vs storing. Argues that a little more memory saves a lot of transmission. Proposes a new RPL Mode of Operation (MOP) that allows Route-Requests and Route-Reply's Construct a DODAG in each direction. Route-Request from OrigNode to TargNode enables data from TargNode to OrigNode. Emmanuel Baccelli: does S bit set mean RFC6997 behavior? CP: no because want to get rid of distance vector. Charles goes through illustrated examples. S bit according to symmetric/asymmetric assumption on the links. Steers different protocol behavior. Charles solicits feedback on the draft. [17:02] No-Path DAO Problem Statement (Rahul Jadhav) This draft explains the problems and requirements. Recap on NoPath DAO. NPDAO sent to the parent. Loss of link to parent is main reason for havong to send NPDAO in the first place, so this doesn't work. RFC6550 has a vague statement about this. This draft intends to clarify this. For example, a node could send NPDAO on behalf of another one. Does it have the state required? Example of situations that work. Former parent has PathSequence. Discussion on PathSequence number increment. Lists requirements. Q&A Charles: increment by 2 because ... Rahul: not stated in RFC. .. Charles: seems can be made to work, will think about it. [17:10] Charter discussion (Peter+Ines) Charter is discussed on the mailing list, grateful for all the comments received. Reduced the historical part. Peter reads the currently proposed text. Carsten: are these term defined in RPL terminology draft/RFC? Cite it and this charter can be made even shorter. Peter: will do. Charles: if interest in AODV-RPL draft, would fall under "improving ..." sentence? Peter: yes. Pascal: P2P-RPL was experimental draft for a reason Carsten: was experiemnt succesful? Emmanuel: too early to state. More experiment required. Still interested in the new proposal as presented by Charles. Justin Dean: add MANET to the list of WG to align with, especillay regarding the multicast work. Carsten: use YANG will decrease repulsion to MIB. Carsten: BIER-forwarding is very specific. Instead of "such as ...", put "See ...". Alvaro: Even avoid that. ... PIM (protocol for Internet multicast) ... Anything to add? Michael: forgot to ask WG wheter we should assume 2460bis or not to steer our work? Do we work with what we had or to we wait to clearly make their mind? Pascal: they have a deadline. We can wait. Ines: milestones: we will add AODV-RPL. We'll bring the milestones to the mailing list and get feedback. If support for the drafts, we will add them to the milestones. [xx:xx] AOB [17:22] meeting concludes.