Subject: [Roll] Downward routes in RPL rev -09

From: Ralph Droms <[email-masked]>
Date: Sun, 27 Jun 2010 16:00:09 -0400

Some details of the transmission and use of DAOs in a non-storing mode
LLN are unclear to me...

1) How are DAO messages delivered from source to destination?  I read
list item 2 in section 8.7:

  2.  On receiving a unicast DAO, a node MUST forward the DAO upwards.
      This forwarding MAY use any parent in the parent set.

to mean that:

a) the sending node sets the IP destination address of the DAO
  to the address of one of its DAO parents
b) the receiving node, in turn, sends the DAO to one of its (the
  receiving node's) DAO parents

However, later in section 8.7, this text:

  Nodes aggregate DAOs by sending a single DAO with multiple RPL Target
  Options.

leads me to believe that the receiving node "consumes" the DAO
messages it receives (during the delay time specified in section 8.4)
and constructs a new DAO message that aggregates the information from
those received DAO messages.

2) Is the interpretation of RPL Target and Transit Information options
in a DAO of dependent on the order and context in which those options
appear?  That is, are a string of consecutive RPL Target options
considered a set of targets, for which a following string of Transit
Information options are considered to hold the set of parents?

3) In the first bullet list item of section 8.1, does "subset of its
parent set" mean "subset of its DODAG parent set"?

4) In section 8.3:

  1.  Each time a node generates a new DAO, the DAOSequence field MUST
      increment by at least one since the last generated DAO.

what does "generates a new DAO" mean?  How does this rule apply to 1),
above?

5) In section 8.3:

  2.  Each time a node link-local multicasts a DAO, the DAOSequence
      field MUST increment by one since the last link local multicast
      DAO.

why does this rule only apply to multicast?

---

From: Philip Levis <[email-masked]>
Date: Mon, 28 Jun 2010 18:13:57 -0700

> those received DAO messages.

The second conclusion is correct. The 2. bullet should probably read

2. On receiving a unicast DAO, a node MUST forward the updated downward
route information upwards. This forwarding MAY use any parent in the
parent set. The downward route information in the DAO MAY be aggregated
with other DAOs before being forwarded upwards.

Is that better?

> Information options are considered to hold the set of parents?

The pattern is

(Target, Transit+)+

> parent set" mean "subset of its DODAG parent set"?

Yes -- I think -10 reflects this.

> what does "generates a new DAO" mean?  How does this rule apply to 1),

"Generates a new DAO" means "send a DAO with different information."
E.g., different field values, options, option values, etc.
Retransmitting a DAO with the same information (e.g., due to the lack of
a DAO-Ack) does not require incrementing the sequence number. This is
for the case where the DAO parent received the message but the ack was
lost.

> why does this rule only apply to multicast?

Good question -- I don't know. It should not apply to unicast due to the ack mechanism. Pascal, Tim?

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 29 Jun 2010 18:21:27 +0200

Hi Ralph and Phil:

For 1) What about the following text:
"
DAO messages, like any other RPL message, are sent with a link scope.
This means that a DAO message is processed at each hop. In non-storing
mode, a DAO is passed to any selected parent by simply changing the
source and destination, and eventually regenerating some security
fields.
In storing mode, a DAO is absorbed and merged and the DAO information
already learnt from other DAOs, in particular in the form of a routing 
table. A storing node generates its own based on its own states
and asynchronously to DAO reception.			
"

> On receiving a unicast DAO, a node MUST forward the updated downward

Great text. I think we use the word "propagate" instead of forwarding.
Forwarding is already overused and is generally understood as the normal
Operation of a router that is not the destination of a packet. I think
we need
To be a little more specific on the storing vs. non storing operations.

When merging with the existing rules and the needed text on path
sequence,
 we end up with text in the normative section like:
"
On receiving a unicast DAO with new or updated information like
a more recent Path-Sequence than known so far, a node SHOULD schedule 
a DAO to propagate the updated downward route information upwards. 
A storing node SHOULD NOT send this DAO immediately but
 SHOULD delay sending the DAO in order to aggregate other 
DAO information. All states related to a same target with an
older Path-Sequence MUST be deprecated.
"

> (Target, Transit+)+
Maybe (Target+, Transit+)+ to add a node that has multiple addresses
like a router with more than one interface.

> Good question -- I don't know. It should not apply to unicast due to
the ack
> mechanism. Pascal, Tim?

This is at the core of what's to be reworded for -11. Fact is the text
really applied to what's now the path-sequence.

For the DAOSequence, all the node needs to know is a == comparison.  And
the text now says:
"
   o  The sending node MUST increment the DAOSequence with each DAO
      message it sends to a same DAO parent or multicast group.  The
      node MAY use a single local counter that is incremented with each
      DAO regardless of the destination.

"

What do you think?

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Philip Levis
> Sent: Tuesday, June 29, 2010 3:14 AM
> To: Ralph Droms
> Cc: [email-masked]
> Subject: Re: [Roll] Downward routes in RPL rev -09
> 
> Retransmitting a DAO with the same information (e.g., due to the lack
of a
> DAO-Ack) does not require incrementing the sequence number. This is
for
> the case where the DAO parent received the message but the ack was
lost.
> Good question -- I don't know. It should not apply to unicast due to
the ack
> mechanism. Pascal, Tim?
> 
> Phil
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Tue, 29 Jun 2010 12:33:57 -0700

> To be a little more specific on the storing vs. non storing  

I agree that forwarding is the wrong word. Propagate is fine.

> older Path-Sequence MUST be deprecated.

Please note that your text is functionally quite different from mine  
and what is in the draft currently. You are replacing MUSTs with  
SHOULDs, in ways that have pretty big implications for route  
maintenance (read: can cause downward routes to fail persistently).  
Is this intentional?

> like a router with more than one interface.

OK.

>       DAO regardless of the destination.

I don't think you've answered the question: you've suggested  
something quite different from what is in the draft. Among other  
things, you've precluded idempotent retransmissions in response to  
lost DAO-Acks.

Phil