Minutes IETF101: roll
Routing Over Low power and Lossy networks
||Minutes IETF101: roll
Thursday 21 March; 9h30 - 12h00
Peter and Ines: Introduction (10 minutes) .
Papadopoulos: object function (15 Minutes)
Papadopoulos: RPL DAG Metric Container (15 minutes)
Rahul: discussion of open problems (30 minutes)
Carsten (and Pascal) use of BIER in RPL uni- and multicast (45 minutes)
Michael (and xxxx): Parent selection before or after enrollment (30 minutes)
5 MINUTES open MIC to discuss continuation
- Dominique Barthel, Georgios Papadopoulos
- more welcome!
[9:30] Meeting starts
[9:30] Introduction (chairs)
* Note Well, note takers, blue sheets, Note Well
* updated the milestone list to more realistic target dates
* Active internet drafts
* notice IPR on two drafts, mail was sent out. Please react
* Peter: this time, long ROLL meeting. Many topics to discuss. Want to get
some feedback on the length of this meeting
Aris: is presenting his draft on Load Balancing
* new routing metric container proposed.
* simulation results
* the proposal is developed over Contiki OS (and Cooja simulator)
* number of DIOs sent as a measure of network stability: this proposal does
a bit better than state of the art (i.e., MRHOF, Child Count draft) * open
questions: packets or bytes? time units? assumption of homogeneous
forwarding cpapacity of nodes, should we send capacity as well in DIO? *
how to relate energy consumption to packets/bytes sent? * * Shall this
value be integrated with EB/IE, * Giorgios: this is layer 3 info, should
not get into EB * Rahul: interesting work, done something similar * Aris:
let compare notes * MCR: your diagram on slide 12, how do you ensure node 7
attaches to 4 in order to allow 5 to accommodate 8? * Michael: there should
be more experiments with more children per parent, to see the impact of
overloaded children per device * Rahul: OF here only takes packet
transmission rate into account. * Aris: would use other metric as well, and
this one as a secondary metric. * Charlie Perkins: * Charlie: study
[9:49] RPL DAG Metric Container (MC) Node State and Attribute (NSA) object
type, extension (Aris)
* New TLV proposed in NSA object, for packet replication and elimination
* already presented at Singapore
* aim is determinism for reliability
* The employed mechanism is the so-called Packet Replication and
* key point is to select the alternate parent to send replica to
* idea is to pick alternate parent that has common ancestor with best parent.
* new TLV contains IPv6 addresses so that ancestors can be learnt
* wireshark dissector was written
* drawback is size of IPv6 addresses that are sent. Compressed out some of
it. * The idea is to keep the default parent and alternative parent so that
to have the parents as close as possible to allow overhearing * MCR: to
compress IPv6 addresses, look at 6LoRH header, code available * Carsten:
your draft has NSA in the title ;-) * Peter: how does your proposal co-exist
with other parent selection draft? * Aris: this is just a Constraint, not a
metric. Can work with OFs * Pascal: the OF at IETF are simple, but more
metrics exposed. OF should be piece of logic. Your OF would be one with high
level of intelligence. * Peter: would be nice if this draft reflects how it
interacts with OFs * Ines: this is of interest to ROLL, also needed by
6TiSCH * Pascal: 6TiSCH does not *need* this, but a solution that benefits
from 6TiSCH would also benefit from this.
[10:01] draft-rahul-roll-rpl-observations-00 (Rahul)
* just observations of issues, no solution here
* Smart Meter networks, 60 hops, thousands of nodes
* issues mostly related to storing mode
* how to handle DTSN increment? want to also check how BIER does
* issue is DAO not getting through to the Border Router. Need for some
redundancy. Re-transmit at every DIO Trickle timer interval? * has seen
10% of nodes not joined, for a long time. * on parent switch, should
node increment DTSN
* * (Dilemma 2) On parent switch, should node increase its DTSN?
* DAO-ACK: could be a solution if were handled properly. Current RPL
spec has multiple interpretations possible. * Contiki (new) implemented
DAO-ACK hop-by-hop. RioT implements end-to-end. * RPL spec say
aggregated target is possible, but how to handle failure? * problem
will show on multiple hops, not simple one-hop network * third
proposal: downside is aggregated ACKs is not possible.
* handling node reboots: how is RPL state is maintained.
* not acceptable to write to flash repeatedly (endurance issue).
Incrementing DTSN 5 times a day is a problem, reportedly * Carsten:
what level of ?? are you considering? * Rahul: numbers in the draft,
please look at them and comment
* handling resource unavailability
* neighbor cache full, routing table full: how do you signal it?
* impacted packet delivery rate in this experiment. Some ideas for
workaround, but would like to hear about other's experience.
* MCR: excellent work, should adopt it. Lots of useful points. Hadn't
realized that the spec was ambiguous. * MCR: one document with solution:
e.g. DTSN increment is clearly a bug in the spec. * MCR: another document
to discuss issues we don't have a solution for. * Pascal: agrees to thank
for the work, not so much for the rest that michael said. * Pascal: a bit
of history: left a few things open when writing spec because did not know
what to decide. Don't rush to immediate solution. * Pascal: RPL is not just
for wireless. It's a routing protocol. Also used on wires. * Pascal:
explains thinking about DAO-ACK. We need something to solve the end-to-end
delivery. * Pascal: version rebuilds everything, DTSN " repaints" the
DAODAG. Discrepancy is found when seeing traffic from unknown node. *
Pascal: wanted capability to rebuild the network intelligently by having a
timer that is long enough so that ...., never specified that. * MCR: seems
Pascal agrees. Just clarified a lot of things. 6550 did not capture that
clearly. Low hanging fruit document should only include non-controversial
points. * MCR: a bunch of knowledge just exposed, glad it's captured on
tape. Want to capture it in text quickly. * Rahul: will go to the mailing
list to get consensus on what is non-controversial * Ines: a document for
the problem statement and links to solutions * Pascal: problem statement
does not need to be published * Peter: draft could expire. * Rahul:
understand could maintain this draft as long as needed, and develop
solutions in other documents? * Carsten: in the past in RoHC WG, have kept
a standing doc for 5 years.
[10:31] draft-ietf-roll-ccast-01 (Carsten)
* this is more than 5 years old.
* thought it would be good to have multicast for non-storing mode.
* result of a " constrained-cast" reseach project.
* in 2014, BIER appeared, revived interest.
* Carsten shows tutorial slide. Efficient representation of lists of data.
Bloom filters, dating back 1970's. * False positives create spurious
transmissions, energy consumption. How bad is it? In dense network, gets
worse. Still, can leave with some of it * False positives depend on number
of bits allocating. Two many bits is also a problem. * Matt Gillmore
[10:40] draft-thubert-roll-bier-01 (Pascal, Toerless Eckert)
* has backup slides to explain how BIER works with RPL, look at them at the
back of the presentation or ask me to present them * can be used in storing
or non-storing, unicast or multicast * Carsten: *set* vs. *sequence* *
Pascal: set out to write a doc showing how all 4 cases can be done. * with
bitmap, amount of storage is related to number of children, which can be
controlled. Could revive storing-mode. * BIER-TE specifies bits for each
hop to follow. False positive create forwarding to wrong path *
Toerless: don't we want rough characterization (overhead, resources) before
writing the drafts? * Pascal: Bit-by-bit fits the BIER architecture. Bloom
filter needs some adaptations. * Carsten: comparing different metrics: good
way to compress bit fields. Number hosts (storing mode) of forwarding nodes
(non-storing mode). * Pascal: 200 hosts, how many bits do I need? *
Toerless: * Carsten: bit assignment can be managed with RPL, with ND. *
Carsten: could look at more ways to compress bitmaps. Could get efficiency
close to that of Bloom filters. * Carsten: I' m interested in non-storing
mode * Pascal: could use * Carsten: non-storing case is slightly simpler,
because the actual source is always the root. * Pascal: with Bloom, creates
a problem. By contrast, bit by bit allows to send multicast from inside the
network. This is a differentiating point * Pascal: work to be done at BIER:
allocation of bit to address, * still work to be done to compress RPL
control plane messages (DIO, DAO, ...) * Toerless: what 's the packet
format? can we replace IPv6 header with BIER header? * Pascal: compressed
form, but packet complies with the IPv6 architecture. Can always
reconstruct the full IPv6 packet using the implicits. * Pascal goes through
RPL tutorial slide. Bit allocation. Aggregating bits in DAO operation. *
Giorgios: what do you do if too many nodes? * Pascal: Bier can do groups. *
Pascal explains how to forward messages based on bitmaps. * can be made
reliable with ACK, which are OR'ed together as they go back up. * Peter: is
there interest in the working group for this work? Humm now: humms heard. *
Peter: anybody opposed? Speak up now. * Carsten: IPR? * Peter: propose to
start design team. * Carsten: send lawyers * Toerless: isn't it always the
case? Can create a design team and see later if proposed options are
covered with IPR. * Peter: suggest Carsten, Pascal, Toerless, Olaf, Greg,
Ijsbrand (Cisco), Giorgios, Emmanuel. * Peter: Toerless to coordinate. *
Peter: DT to create doc with alternatives, IPR info.
[11:16] draft-richardson-6tisch-roll-enrollment-priority-00 (Michael)
* set of requirements coming from 6TiSCH to do in ROLL.
* not specific to 6TiSCH, though.
* Problem is network selection. Given a node that can hear many routers
belonging to several networks, which one to select? * Would like to not
have to try all routers, but rather know which network they belonging too
without revealing too much. * We need to do DODAG selection, inside a
network. * if different PANIDs, probably different keys. * Carsten: if
secret handshake, none of the two parties disclose anything to a third
party. * Michael: not quite the same problem. * our objective is node not
going through all networks * Carsten: done with SSID * MCR: no SSID in
15.4. Has PANID, but too short and other problems. * in 6TiSCH, IE to
* proxy priority: reflects resources allocated for unknown nodes
wanting to join * R says if it will answer unicast Router Solicitation
* network ID * DODAG priority: reflects willingness to accept new
* Carsten: this reveal node is trying to join
* MCR: secret handshake in zero-touch way, would love it
* Thomas: emphasizes waste of energy of blind search. This helps a lot.
Real use case. * Pascal: agrees with Thomas. Mostly interested in DODAG
priority. In the field, we see instability in structures that we build.
Oscillations. * Pascal: load at the root is the load of thee network. Work
to do is to end up with balanced situation * need new metric container.
Will be transmitted unchanged as DIOs go down the network. * new DIO
configuration option. To convey the new network ID. * Pascal: your new
metric does for the whole network what an OF does for a node. * Pascal:
number of node left, amount of bandwidth left. Not so much percentages,
because could translate to different absolute values. * MCR: in storing
mode, as RPL is now, we don't know the load of the nodes * Peter: can you
say again what this documennt is exactly about? * MCR this is just the
description of a DIO container. Maybe suggest way of calculating this
metric. * Peter: parent selection in another document? * MCR: true. *
Peter: who's read? who's willing to review? who thinks we should adopt? *
Ines: we'll go to the mailing list.
[11:43] Open mic
* Aris: finds all problems discussed very interesting. What about
replicability? how to share information that would allow to reproduce
situation in simulation * Rahul: agree it's a big issue. Working on a
framework specifically for this. Whitefiled? framework. * MCR: F-interop is
also very cool. * MCR: been the case in ROLL WG that issues were reported
but no detailed info was available to simulate/replicate issue. * MCR:
Cooja runs Contiki, does not allow to compare RIOT and Contiki
implementations. * Thomas: there's a lot to verify. F-interop to verify
interoperability. For performance, 6TiSCH python simulator and interface.
Allows to enter a scenario and get graphs.
Only part of the answer to your question, but still something.
* Ines: introduces tomorrow's meeting.
* Peter welcome feedback on time of this meeting. Do you prefer longer or
[11:51] meeting ends
Friday 23/3 9h30-11h30
Ines+Peter: Introduction (5 min)
Charlie: Asymmetric AODV-P2P-RPL in LLNs (15 mins)
Pascal: ND only device connects to RPL DODAG. (20 mins)
Rahul: DCO performance report (15 mins)
Pascal: Objective function specification and selection for parent selection,
DAG selection (30 minutes) draft-thubert-roll-unaware-leaves-01
Pascal: Root initiated routing state in RPL (15 mins)
Dominique: state of Dis-modifications (5 min)
xxxxx: RPL-load balancing (15 mins)
15 MINUTES DISCUSSION: All: Discussion on new subjects
Which topics and priority,
[9:30] Meeting starts
[9:31] Routing for RPL Leaves (Pascal)
* original idea was low cost nodes roaming through 6LRs.
* called a leaf, is RPL-unaware. Does not know RPL is being used. Only uses
6LoWPAN ND * had to change 6LoWPAN-ND because fabric has to know what is
the latest location, so that it can route to the leaf * comparing
timestamps does not work because tolerance on timers and mobility speed
unknown * now, source generates a sequence. Ordering becomes obvious * also
change source address validation. Address could be spoofed (stolen) and
traffic diverted. * association mechanism mimicking that of 802.11. Leaf
pro-actively installs state in the 6LR (equal to AP in 802.11) so that the
6LR knows has to forward multicast
traffic for this leaf
* this supports RPL but also any other similar routing protocol
* Pascal shows the address validation mechanism. ROVR is token to prove
ownership of address. Only proves address on first hop * new spec: leaves
set the R bit to 1 to instruct 6LR to inject this address into routing *
Transaction ID is a sequence counter to be injected into the DAO Path
Sequence Number. * Rahul: Path Sequence is optional * Pascal: believe it is
mandatory. Otherwise, we have a problem * Rahul: will check. * Registration
lifetime: in ND, expressed in minutes. In RPL, configuration that tells the
time-unit. * Rahul: Transit Info not mandatory * Pascal: will check *
Rahul: none of the open source RPL implementation currently use Path
Sequence. * Pascal: if the MUST is missing, this is a bug. We'll look at it
offline. * Pascal: still lacking a reference open-source implementation of
RPL. Do not judge the quality of RPL by the quality of some implementations
out there. * shows message exchange diagram. New spec mandates 6CIO option
from 6LBR down to the 6LRs. * Peter (from the floor): what happens if we
mix 6LR with and without the new option? * Pascal: the spec discusses this.
It works. On security side, weaker because smaller keys. Spec recommends a
leaf attaches to a "new" 6LR. An old 6LR on the way from the attachment 6LR
and 5LBR is okay. * signaling is in the 6775-update doc, how proxy
operation is done is in the backbone doc. * Got reviews from IESG, not
quite closed yet but looking good. * shows diagram on address validation:
protects the legitimate owner against other nodes trying to steal that
address. * re-iterates that only first hop is protected, RPL is not. *
we'll discuss on the mailing list on Rahul draft (DAO-ACK). * Pascal: if
you're implementing RPL, understand that when a 6LR accepts a DOA from a
child, it takes responsibility for transmitting ii up. * is the RPL root
the LBR? technically, could be separate. In Pascal's mind, should be the
same * big discussion that needs to be had: do we MUST that 6LBR and RPL
root are one? * proposes to use RPL DAO to accomplish what DAR/DAC does. *
remember that RPL will not do DAD, since ROVR doesn't go to Root. *
summary: very simple node roams smoothly across meshed 6LRs, many DODAGs. *
on terminology: RPL defines "leaf", a node that understands RPL but does
not route. This draft defines "unaware-leaf", a node that doesn't even
understand RPL. * pre-requisite: 6775-update, IP-in-IP, RPI header * if
6LBR was not RPL root: could make it work, no too sure. * do we have a use
case for it? * Peter: who has read the draft? a few hands? * Peter: is this
6Tisch-related? useful to 6TiSCH, but not even routing-related. * Pascal:
simple work, but really important. Most of it done at 6lo. * Pascal: had
this dream from the start, could not implement it with RPL, now can. * work
not quite done yet, if you are interested, join in.
[10:15] Asymmetric AODV-P2P-RPL in LLNs (Charlie)
* allows asymmetrical routes between nodes pairs.
* went into last call, got lots of comments
* most extensive comments: some features of P2P-RPL not implemented in
OADV-RPL. As a result, attempted to include these. * discussion on use of
DSTN for sequence number. * Pascal: two sequence counters coming down from
the root. One when new DAODAG is built (version number), rebuilding a new
DODAG including reparenting. * DTSN is to refresh the state associated to
current topology. * what exactly is your destination sequence number? *
Charlie: not sure, will have it as a separate discussion. * will suggest
using OADV's feature to deal with uni-directional links. * this draft was
published quickly to meet the submission deadline. Will get a revised
version soon. * Pascal: original P2P-RPL used DIO for RReq and DAO as
RReply. Needs a certain degree of bidirectionality. * Pascal: Charlie, your
work is the only one that uses DIO both ways to discover the route. This is
P2P-RPL uses DIO in one way and DAO the other way, does not work as well
in presence of asymmetrical links.
* Pascal/Dominique: discussion on the causes for asymmetry.
* this draft defines new RREQ/RREP option. Imported from 6997
* new target option.
* had discussion on pairing of InstanceIDs (one for each direction).
<< missed part of it>>>> * to be done
* citing 6997 cannot be normative, because it's experimental.
* InstanceID conflicts
* import black-hole link detection of OADV?
* Rahul: you said asymmetrical link detection is out of scope.
* Charlie: could make it in scope
* Rahul: the probing of links for asymmetry should not be in scope
* Charlie: the metric should be there
* Pascal: doesn't seem we need to do anything. Building another DAG, using
DIO. If a link is asymmetrical, flooding will not happen, that's it. *
Peter: would like this document to be completed. Have this discussion on
the mailing and get to a conclusion in the next few weeks.
[10:38] Route invalidation, experiment report (Rahul)
* remember NPDAO sent downstream
* DCO and NPDAO operating at same time in the network.
* report link sent on the mailing list a month and half ago
* two topologies, 50 and 100 nodes. All nodes are started at same time.
* much less stale entries with DCO than with NPDAO.
* control overhead better for DCO as well.
* analysis of what happens on parent switching (identical in Contiki and
RIOT). Send NPDAO immediately, schedule a new DAO for later. Hence route
downtime. * Pascal: Contiki and RIOT implementations are not RPL. Don't
state the quality of RPL based on these implementations. * Rahul: with DCO,
.... * Pascal: you may be sending two DAOs, one gets slowed down, your DCO
gets earlier. Don't be too quick in sending the uplink * Pascal: another
point: traditional in LS to cleanup the bad state left over on mobility.
From hearsay, proven to be complex. Should research on this. * Pascal: bad
history of doing this in other routing protocols. * Alvaro: in other
protocols, do flush. Problem is flushing for somebody else that's no longer
there. State expires. Connectivity fails. * Alvaro: there has been
proposals on proxying, nobody very happy with this. * Pascal: keep a note
that we should experiment with this before standard RFC. I feel this is
safe, but needs a check * Rahul: still kept the bit .... * Rahul: next steps
* text changes (Destination Cleanup Object), but no semantic change for
a long time. * would like to WGLC this
* Peter: also wants this
* Peter: perf report in appendix?
* Peter: if you have publication elsewhere, you can also refer to it.
* Pascal: Cisco and Huawei both have IPR on this.
* Rahul has invited Pascal to join the work on this.
[10:56] Root initiated routing state in RPL (Pascal)
* two implementations under way. One by Huwaei, one
* invited Huawei (whom?) and Matt Gillmore to this draft.
* not much progress recently
* Need to discuss size of MoP, 3 bits. AODV uses a new MOP as well. We'll
be short on bits pretty soon. * Charlie: discussion also holds for
AODV-RPL. Should it use new MOP or new message numbers? * Pascal: 8 MOP
values. 4 consumed in the base spec. 1 is experimental, can be claimed
back. Leaving 5. * Remaining questions
* how is the topology known to the root? non-storing, DAOs tell the
DODAG. storing, not much. * how are node capabilities know to the
root? extend the DAO to include things such as memory size? * Rahul: *
Pascal: constrained nodes usually don't do storing mode. If you do
storing mode, do it well. If node reparents, need to be able to
reconstruct state. * mixed modes? * loop avoidance
* Peter: could you reduce document to non-storing mode and avoid all the
storing-mode related problems? * Pascal: answer is no. Initial motivation
was to build networks with long lines of nodes, want to compress this line
with local storing mode. Send in non-storing mode only to the beginning of
the line. * Rahul: loop avoidance will be updated in this draft
[11:08] Status of draft-ietf-roll-dis-modifications-00
* interest for this work re-iterated on the mailing list.
* Dominique and Cenk will allocate resource to work on this by the summer
* Pascal willing to help
* discussion whether this draft should just provide the flags and options
or should also recommend the use of each mode and option for different
real-world situations * Pascal: we've had these discussions in hallways on
multiple instances since Maastricht. * not much resource available to that.
* Pascal: could target the experimental track and publish quickly *
Dominique: will revive this discussion on the mailing list and move forward.
[11:23] meeting closed