Subject: [Roll] [roll] #54: Clarification on multicast

From: "roll issue tracker" <[email-masked]>
Date: Thu, 17 Jun 2010 05:52:34 -0000

#54: Clarification on multicast
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |       Owner:  pthubert@…        
     Type:  defect              |      Status:  new               
 Priority:  trivial             |   Milestone:                    
Component:  rpl                 |     Version:                    
 Severity:  Active WG Document  |    Keywords:                    
--------------------------------+-------------------------------------------
 Starting a new ticket on Multicast operations.
 There are two items here:
 1) Solution for multicast forward on in a non storing node network (=> not
 a routing issue, outside of the scope of the ROLL WG)
 2) A few clarifications have been requested:
 A few comments/questions:
 a. It might be useful to have a few words stating whether this solution
 would work in a large LLN – I,e when the members of multicast group is
 spread across the large LLN
 b. The section says that the router ‘should prune’ duplicate registration
 messages (DAO) – but it does not say more detail about it -I,e is it up to
 the implementation that pruning would be done based on some rules?

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/54>
roll <http://tools.ietf.org/wg/roll/>

---

From: JP Vasseur <[email-masked]>
Date: Thu, 17 Jun 2010 08:06:46 +0200

Dear all,

I closed the old ticket and opened a new fresher one.

There was one comment that I removed:

c. Is multicast support mandatory if someone implements the RPL draft?  
- if not, is it okay to simulate multicast packet distribution using  
unicast messaging in a small/simple LLN ?

The answer is: look at the normative language. This is what tells you  
what to implement to be compliant with the RFC. Of course, commercial  
implementation may decide to implement some parts of the ID, but this  
is not an IETF issue. Back to the second part of your question, yes  
some implementation to send multiple unicast packets, which may be OK  
in small networks"

We will close this one for revision -10.

JP.

Begin forwarded message:

> From: "roll issue tracker" <[email-masked]>
> Date: June 17, 2010 7:52:34 AM CEDT
> To: [email-masked], [email-masked]
> Cc: [email-masked]
> Subject: [Roll] [roll] #54: Clarification on multicast
> Reply-To: [email-masked]
>
> -------------------------------- 
> +-------------------------------------------
> -------------------------------- 
> +-------------------------------------------
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 Jun 2010 08:45:50 +0200

In addition, I have asked what are the multicast capabilities of the
link layer on which RPL is supposed to run.  This is an issue, should be
clarified.

For example, if the link layer offers link-layer addresses which are
compatible with IPv6 link-local multicast addresses then RPL should take
advantage of them - read: use RPL IP dst addresses derived from the
link-layer multicast addresses.  If not such offering, then RPL should
be less likely to send to ff02::2, because the link-layer wouldn't
support it.  This is but an example.

MANET defines such an address - it should be reused here, it's obvious.

Besides, the use of link-local scoped addresses means there's only one
hop, thus multi-hop routing makes little sense, _if_ the link-layer
provides such multicast support.

Alex

> Type:  defect              |      Status:  new Priority:  trivial |
> Milestone: Component:  rpl                 |     Version: Severity:
> Active WG Document  |    Keywords:
> There are two items here: 1) Solution for multicast forward on in a
> non storing node network (=>  not a routing issue, outside of the
> scope of the ROLL WG) 2) A few clarifications have been requested: A
> few comments/questions: a. It might be useful to have a few words
> stating whether this solution would work in a large LLN – I,e when
> the members of multicast group is spread across the large LLN b. The
> section says that the router ‘should prune’ duplicate registration
> messages (DAO) – but it does not say more detail about it -I,e is it
> up to the implementation that pruning would be done based on some
> rules?
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 Jun 2010 08:47:16 +0200

Le 17/06/2010 08:06, JP Vasseur a écrit :
> c. Is multicast support mandatory if someone implements the RPL draft? -
> if not, is it okay to simulate multicast packet distribution using
> The answer is: look at the normative language.

Sorry which spec?  Would be please suggest which normative language of 
which link layer thank you.

Some link layers do offer multicast support (IEEE) some others don't 
(old RS-232).

On which is RPL going to run?

Alex

  This is what tells you
> implementation may decide to implement some parts of the ID, but this is
> not an IETF issue. Back to the second part of your question, yes some
> implementation to send multiple unicast packets, which may be OK in
> small networks"
>
>> *From: *"roll issue tracker" <[email-masked]
>> <mailto:[email-masked]>>
>> *Date: *June 17, 2010 7:52:34 AM CEDT
>> *To: [email-masked] <mailto:[email-masked]>, [email-masked]
>> <mailto:[email-masked]>
>> *Cc: [email-masked] <mailto:[email-masked]>
>> *Subject: **[Roll] [roll] #54: Clarification on multicast*
>> *Reply-To: [email-masked] <mailto:[email-masked]>
>>
>> [email-masked] <mailto:[email-masked]>

---

From: JP Vasseur <[email-masked]>
Date: Thu, 17 Jun 2010 09:50:11 +0200

On Jun 17, 2010, at 8:47 AM, Alexandru Petrescu wrote:

> Sorry which spec?

The RPL specification. RFC2119 is used to specify what MUST, MAY or  
SHOULD be
supported.

> Would be please suggest which normative language of which link layer  
> thank you.

We do not. Remember, RPL is an network layer routing protocol. As  
such, it does NOT
mandate the use of any specific link layer.

> On which is RPL going to run?

On many ... again RPL is not tied to any of them. If there is a need  
for an adaptation layer
to carry IPv6 over a next generation PLC link for example, it will be  
specified somewhere
else, not in ROLL: our charter is to provide a routing (L3) solution.

Thanks.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 Jun 2010 11:07:27 +0200

Le 17/06/2010 09:50, JP Vasseur a écrit :
>>> c. Is multicast support mandatory if someone implements the RPL
>>> draft? - if not, is it okay to simulate multicast packet
>>> distribution using unicast messaging in a small/simple LLN ?
>>>
> SHOULD be supported.
>> Would be please suggest which normative language of which link
>> layer thank you.
>
> such, it does NOT mandate the use of any specific link layer.

Well, RPL does mandate the use of ff02::1 dst address.  Is this
address supported by "any" specific link layer?  Is "any" link layer
providing a mapping function between the link-layer multicast address
and the IP multicast address?

I think some link layers do some others don't.  For those who don't - it
makes no sense for RPL to require the use of ff02::1.

For some (Ethernet), it is necessary to make a join operation, with MLD
- otherwise it's not working.  Thus, RPL should say so.  Absence of
saying so means underspecification.

BEsides - why does the RPL require the use of ff02::1 (all-routers
link-local scope) and not ff05::1 (all-routers site-local scope)?  The
IPsec discussion mentioned that a single operator may manage all nodes -
thus a single site would be more appropriate... site-local scope.

Why does not RPL use the address ff02::6d ("LL MANET routers"?)  It
would make much sense in re-using existing developments, learning from
others' findings, putting less stress on IANA, and more.

I could raise many similar multicast issues, but most boil down to one
question: which link-layer(s) is RPL supposed to run on?  "Any" is as if
"none" was said.

>> Some link layers do offer multicast support (IEEE) some others
>> don't (old RS-232).
>>
> for an adaptation layer to carry IPv6 over a next generation PLC
> link for example, it will be specified somewhere else, not in ROLL:

Ok, I didn't mean to require an adaptation layer, just to make sure what
RPL says is appropriate to what some link layers have to offer.  There
may be a risk in RPL assuming some support (specifically multicast)
which the link layer may not offer.  To alleviate this, it is sufficient
for RPL to say, e.g., to use multicast dst addresses only when such
support is available.

Some recent email discussion said "use unicast" in these cases - but
how?  Would that mandatory ff02::1 multicast address be replaced by
several unicast addresses?  How?  Simultaneously?  In which order?

(I will not write a draft about this).

Alex

> charter is to provide a routing (L3) solution.
>
> Thanks.
>
> JP.
>
>> Alex
>>
>> This is what tells you
>>> what to implement to be compliant with the RFC. Of course,
>>> commercial implementation may decide to implement some parts of
>>> the ID, but this is not an IETF issue. Back to the second part of
>>> your question, yes some implementation to send multiple unicast
>>> packets, which may be OK in small networks"
>>>
>>>> <mailto:[email-masked]>> *Date: *June 17, 2010 7:52:34 AM
>>>> CEDT *To: [email-masked] <mailto:[email-masked]>,
>>>> [email-masked] <mailto:[email-masked]> *Cc: [email-masked]
>>>> <mailto:[email-masked]> *Subject: **[Roll] [roll] #54:
>>>> Clarification on multicast* *Reply-To: [email-masked]
>>>> <mailto:[email-masked]>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Reporter: jpv@… | Owner: pthubert@… Type: defect | Status: new
>>>> Priority: trivial | Milestone: Component: rpl | Version:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Starting a new ticket on Multicast operations. There are two
>>>> items here: 1) Solution for multicast forward on in a non
>>>> storing node network (=> not a routing issue, outside of the
>>>> scope of the ROLL WG) 2) A few clarifications have been
>>>> requested: A few comments/questions: a. It might be useful to
>>>> have a few words stating whether this solution would work in a
>>>> large LLN – I,e when the members of multicast group is spread
>>>> across the large LLN b. The section says that the router
>>>> ‘should prune’ duplicate registration messages (DAO) – but it
>>>> does not say more detail about it -I,e is it up to the
>>>> implementation that pruning would be done based on some rules?
>>>>
>>>> -- Ticket URL:
>>>> <http://trac.tools.ietf.org/wg/roll/trac/ticket/54> roll
>>>> <http://tools.ietf.org/wg/roll/>
>>>>
>>>> _______________________________________________ Roll mailing
>>>> list [email-masked] <mailto:[email-masked]>
>>> _______________________________________________ Roll mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>
>>
>> _______________________________________________ Roll mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: Henning Rogge <[email-masked]>
Date: Thu, 17 Jun 2010 11:12:19 +0200

On Thu June 17 2010 11:07:27 Alexandru Petrescu wrote:
> Le 17/06/2010 09:50, JP V> BEsides - why does the RPL require the use of 
ff02::1 (all-routers
> thus a single site would be more appropriate... site-local scope.
Are you sure that RPL use the LL-multicast for addressing ALL RPL nodes in the 
tree and not the one-hop neighbors ? For one-hop neighbors a linklocal-
multicast is correct.
 
> others' findings, putting less stress on IANA, and more.
ff02::6d should do fine for RPL I think.

Henning Rogge
-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 Jun 2010 13:27:25 +0200

Le 17/06/2010 11:12, Henning Rogge a écrit :
>> link-local scope) and not ff05::1 (all-routers site-local scope)?
>> The IPsec discussion mentioned that a single operator may manage
>> all nodes - thus a single site would be more appropriate...
>> site-local scope.
>
> Are you sure that RPL use the LL-multicast for addressing ALL RPL
> nodes in the tree and not the one-hop neighbors ?

I think RPL requires ff02 throughout the document, I am not sure whether
there's a tree of links, or everything is a single link. (were it a tree
there'd be several links, several interfaces per node).

draft says:
"Nodes advertise their presence, affiliation with a DODAG, routing
        cost, and related metrics by sending link-local multicast DIO
        messages."

Is that on a single link?  To all the tree?  Is the entire tree a single
link?

"   A RPL Control Message has the scope of a link.  The source address
     is a link local address.  The destination address is either all
     routers multicast address (FF02::2) or a link local address."

Ok, ff02::2. Better say "all routers multicast address with link-local
scope" instead of simply "all routers multicast address".

"1.  A node MAY multicast a DAO message to the link-local scope all-
         nodes multicast address FF02::1."

Hm? So sometimes a DAO is not an RPL Control Message? (because ff02::1
for DAO is not ff02::2 for RPL Control Message).

Which do you mean?  ff02::1 or ff02::2?  Is RPL run on Hosts?  Routers?
  Nodes?  (remark ff02::1 is all _nodes_ be them Hosts or Routers).

> For one-hop neighbors a linklocal- multicast is correct.

Yes, I agree.  Is the RPL topology made of several links or a single link?

>>  would make much sense in re-using existing developments, learning
>>  from others' findings, putting less stress on IANA, and more.
>

It would make sense to reuse MANET constants.

Alex

---

From: JP Vasseur <[email-masked]>
Date: Thu, 17 Jun 2010 13:35:28 +0200

short answer (more later ...) RPL networks are potentially made of a  
number of links
sometimes of different nature too.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 17 Jun 2010 15:32:57 +0200

Hi Alex:

RPL operates hop by hop and builds the subnet, so it can not use FF05 that expects that the subnet is built in the first place. OTOH, your question makes sense to me in that we could wonder why we use FF02::1 as opposed to FF02::all_RPL_nodes. 

If that's your bottom line, then I do agree with you, we shoud request a all_rpl_nodes to IANA...

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexandru Petrescu
> Sent: Thursday, June 17, 2010 11:07 AM
> To: JP Vasseur
> Cc: [email-masked]
> Subject: Re: [Roll] Fwd: [roll] #54: Clarification on multicast
> 
> Well, RPL does mandate the use of ff02::1 dst address.  Is this address
> supported by "any" specific link layer?  Is "any" link layer providing a mapping
> function between the link-layer multicast address and the IP multicast
> address?
> 
> I think some link layers do some others don't.  For those who don't - it makes
> no sense for RPL to require the use of ff02::1.
> 
> - otherwise it's not working.  Thus, RPL should say so.  Absence of saying so
> means underspecification.
> 
> BEsides - why does the RPL require the use of ff02::1 (all-routers link-local
> scope) and not ff05::1 (all-routers site-local scope)?  The IPsec discussion
> mentioned that a single operator may manage all nodes - thus a single site
> would be more appropriate... site-local scope.
> 
> Why does not RPL use the address ff02::6d ("LL MANET routers"?)  It would
> make much sense in re-using existing developments, learning from others'
> findings, putting less stress on IANA, and more.
> 
> question: which link-layer(s) is RPL supposed to run on?  "Any" is as if "none"
> was said.
> 
> > for an adaptation layer to carry IPv6 over a next generation PLC link
> > for example, it will be specified somewhere else, not in ROLL:
> 
> Ok, I didn't mean to require an adaptation layer, just to make sure what RPL
> says is appropriate to what some link layers have to offer.  There may be a
> risk in RPL assuming some support (specifically multicast) which the link layer
> may not offer.  To alleviate this, it is sufficient for RPL to say, e.g., to use
> multicast dst addresses only when such support is available.
> 
> Some recent email discussion said "use unicast" in these cases - but how?
> Would that mandatory ff02::1 multicast address be replaced by several
> unicast addresses?  How?  Simultaneously?  In which order?
> 
> >>> commercial implementation may decide to implement some parts of the
> >>> ID, but this is not an IETF issue. Back to the second part of your
> >>> question, yes some implementation to send multiple unicast packets,
> >>> which may be OK in small networks"
> >>>
> >>>> <mailto:[email-masked]>> *Date: *June 17, 2010 7:52:34 AM CEDT
> >>>> <mailto:[email-masked]> *Cc: [email-masked] <mailto:[email-masked]>
> >>>> *Subject: **[Roll] [roll] #54:
> --------------------------------+---------------------------------------
> --------------------------------+----
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Reporter: jpv@... | Owner: pthubert@... Type: defect | Status: new
> --------------------------------+---------------------------------------
> --------------------------------+----
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Starting a new ticket on Multicast operations. There are two items
> >>>> here: 1) Solution for multicast forward on in a non storing node
> >>>> network (=> not a routing issue, outside of the scope of the ROLL
> >>>> WG) 2) A few clarifications have been
> >>>> requested: A few comments/questions: a. It might be useful to have
> >>>> a few words stating whether this solution would work in a large LLN
> >>>> - I,e when the members of multicast group is spread across the
> >>>> large LLN b. The section says that the router 'should prune'
> >>>> duplicate registration messages (DAO) - but it does not say more
> >>>> detail about it -I,e is it up to the implementation that pruning
> >>>> would be done based on some rules?
> >>>>
> >>>> -- Ticket URL:
> list

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 17 Jun 2010 15:36:04 +0200

Hi Henning:

Hope you're doing good these days;

I'm afraid MANET is a little vague. We cant to pinpoint nodes that support our protocol. No point in sending DIS or DIO to an OSLRv2 node. 

As Alex pointed out, we probably need our own value to alert only RPL nodes.

What do you think? 

Pascal

> Sent: Thursday, June 17, 2010 11:12 AM
> To: [email-masked]
> > IPsec discussion mentioned that a single operator may manage all nodes
> > - thus a single site would be more appropriate... site-local scope.
> Are you sure that RPL use the LL-multicast for addressing ALL RPL nodes in
> the tree and not the one-hop neighbors ? For one-hop neighbors a linklocal-
> multicast is correct.
> 
> Kommunikationssysteme (KOM) Neuenahrer Straße 20, 53343 Wachtberg,
> Germany

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 Jun 2010 15:44:52 +0200

Le 17/06/2010 15:32, Pascal Thubert (pthubert) a écrit :
> Hi Alex:
>
> RPL operates hop by hop and builds the subnet

If there's a single subnet then there's no hop-by-hop - everything is a
single link, all within 1 IP hop reach of each other.  Arguably - yes.

> so it can not use FF05 that expects that the subnet is built in the
> first place.

Hmmm... how about maintenance (presence, affiliation, routing costs)
packets to a tree already built, like simply renewing existing
information?  That could be sent to a site-local address.

> OTOH, your question makes sense to me in that we could wonder why we
>  use FF02::1 as opposed to FF02::all_RPL_nodes.

WEll I wouldn't go as far as requesting another multicast group address
from IANA when the MANET group is already there.  We could reuse the
MANET address.

> request a all_rpl_nodes to IANA...

It wasn't my bottom line.   How about reusing stuff (the MANET address),
asking people how to use their stuff (the IPsec AH), instead of
designing new things.

Alex

>
> Pascal
>
>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>> Sent: Thursday, June 17, 2010 11:07 AM To: JP Vasseur Cc:
>> [email-masked] Subject: Re: [Roll] Fwd: [roll] #54: Clarification
>> on multicast
>>
>>>>> c. Is multicast support mandatory if someone implements the
>>>>> RPL draft? - if not, is it okay to simulate multicast packet
>>> The RPL specification. RFC2119 is used to specify what MUST, MAY
>>> or SHOULD be supported.
>>>
>> address supported by "any" specific link layer?  Is "any" link
>> layer providing a mapping function between the link-layer
>> multicast address and the IP multicast address?
>>
>> I think some link layers do some others don't.  For those who
>> don't - it makes no sense for RPL to require the use of ff02::1.
>>
>> For some (Ethernet), it is necessary to make a join operation,
>> with MLD - otherwise it's not working.  Thus, RPL should say so.
>> Absence of saying so means underspecification.
>>
>> I could raise many similar multicast issues, but most boil down to
>> one question: which link-layer(s) is RPL supposed to run on? "Any"
>> is as if "none" was said.
>>
>>> On many ... again RPL is not tied to any of them. If there is a
>>> need for an adaptation layer to carry IPv6 over a next
>>> generation PLC link for example, it will be specified somewhere
>>> else, not in ROLL:
>>
>> Ok, I didn't mean to require an adaptation layer, just to make
>> sure what RPL says is appropriate to what some link layers have to
>>  offer.  There may be a risk in RPL assuming some support
>> (specifically multicast) which the link layer may not offer.  To
>> alleviate this, it is sufficient for RPL to say, e.g., to use
>> Some recent email discussion said "use unicast" in these cases -
>> but how? Would that mandatory ff02::1 multicast address be
>> replaced by several unicast addresses?  How?  Simultaneously?  In
>> which order?
>>
>>>>> commercial implementation may decide to implement some parts
>>>>> of the ID, but this is not an IETF issue. Back to the second
>>>>> part of your question, yes some implementation to send
>>>>> multiple unicast packets, which may be OK in small networks"
>>>>>
>>>>>> *From: *"roll issue tracker"<[email-masked]
>>>>>> <mailto:[email-masked]>>  *Date: *June 17, 2010
>>>>>> 7:52:34 AM CEDT *To:
>>>>>> [email-masked]<mailto:[email-masked]>,
>> [email-masked]
>>>>>> <mailto:[email-masked]>  *Cc:
>>>>>> [email-masked]<mailto:[email-masked]> *Subject: **[Roll]
>>>>>> [roll] #54: Clarification on multicast* *Reply-To:
>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Reporter: jpv@... | Owner: pthubert@... Type: defect |
>>>>>> Status: new Priority: trivial | Milestone: Component: rpl
>>>>>> | Version: Severity: Active WG Document | Keywords:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Starting a new ticket on Multicast operations. There are
>>>>>> two items here: 1) Solution for multicast forward on in a
>>>>>> non storing node network (=>  not a routing issue, outside
>>>>>> of the scope of the ROLL WG) 2) A few clarifications have
>>>>>> been requested: A few comments/questions: a. It might be
>>>>>> useful to have a few words stating whether this solution
>>>>>> would work in a large LLN - I,e when the members of
>>>>>> multicast group is spread across the large LLN b. The
>>>>>> section says that the router 'should prune' duplicate
>>>>>> registration messages (DAO) - but it does not say more
>>>>>> detail about it -I,e is it up to the implementation that
>>>>>> pruning would be done based on some rules?
>>>>>>
>>>>>> -- Ticket URL:
>>>>>> [email-masked]<mailto:[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 Jun 2010 15:49:27 +0200

Le 17/06/2010 13:35, JP Vasseur a écrit :
>  number of links sometimes of different nature too.

JP - thank you for the short answer.  It is good to know that RPL is
inteded to run on links of potentially very different nature.

I think it is good to take the time (as long as that may be) and clarify
the nature of the links and see how the multicast addresses used by RPL
could be specified coherently within the RPL spec.

Alex

>>>> link-local scope) and not ff05::1 (all-routers site-local
>>>> scope)? The IPsec discussion mentioned that a single operator
>>>> may manage all nodes - thus a single site would be more
>>>> appropriate... site-local scope.
>>>
>>> Are you sure that RPL use the LL-multicast for addressing ALL
>>> RPL nodes in the tree and not the one-hop neighbors ?
>>
>> I think RPL requires ff02 throughout the document, I am not sure
>> whether there's a tree of links, or everything is a single link.
>> (were it a tree there'd be several links, several interfaces per
>> node).
>>
>> draft says: "Nodes advertise their presence, affiliation with a
>> DODAG, routing cost, and related metrics by sending link-local
>> multicast DIO messages."
>>
>> Is that on a single link? To all the tree? Is the entire tree a
>> single link?
>>
>> " A RPL Control Message has the scope of a link. The source
>> address is a link local address. The destination address is either
>> all routers multicast address (FF02::2) or a link local address."
>>
>> Ok, ff02::2. Better say "all routers multicast address with
>> link-local scope" instead of simply "all routers multicast
>> address".
>>
>> "1. A node MAY multicast a DAO message to the link-local scope
>> all- nodes multicast address FF02::1."
>>
>> Hm? So sometimes a DAO is not an RPL Control Message? (because
>> ff02::1 for DAO is not ff02::2 for RPL Control Message).
>>
>> Which do you mean? ff02::1 or ff02::2? Is RPL run on Hosts?
>> Routers? Nodes? (remark ff02::1 is all _nodes_ be them Hosts or
>> Routers).
>>
>>>> Why does not RPL use the address ff02::6d ("LL MANET routers"?)
>>>> It would make much sense in re-using existing developments,
>>>> learning from others' findings, putting less stress on IANA,
>>>> and more.
>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 Jun 2010 16:25:48 +0200

Le 17/06/2010 15:36, Pascal Thubert (pthubert) a écrit :
> I'm afraid MANET is a little vague.

IMHO, some MANET protocols deal with topologies as vague as RPL does.  I
am looking for structure in the topology.  Most deployments use very
structured topologies with precise ideas on the link layers.

When these very protocols are tried in practice they are exercised with
very precise topologies... except that afterwards we don't mention
them... leaving all vague, talking arbitrary movements, universal
support.  In this context it's hard to reach agreement.

> We cant to pinpoint nodes that support our protocol. No point in
> sending DIS or DIO to an OSLRv2 node.
>

(Short clarification: I suggest coherence in the use of multicast
addresses.  I am not sure we need to request IANA address for RPL nodes
(you seem to imply so).)

Alex

>> [mailto:[email-masked]] On Behalf Of Henning Rogge Sent:
>> Thursday, June 17, 2010 11:12 AM To: [email-masked] Subject: Re:
>> [Roll] Fwd: [roll] #54: Clarification on multicast
>>
>>> scope)? The IPsec discussion mentioned that a single operator may
>>> manage all nodes - thus a single site would be more
>> nodes in the tree and not the one-hop neighbors ? For one-hop
>> neighbors a linklocal- multicast is correct.
>>
>>> learning from others' findings, putting less stress on IANA, and
>>> more.
>> Henning Rogge -- Diplom-Informatiker Henning Rogge ,
>> Fraunhofer-Institut für Kommunikation, Informationsverarbeitung
>> und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Straße
>> 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961,   Fax +49
>> 228 9435 685 mailto:[email-masked]
>> http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D
>> 4487 C67C 55EC CFE0

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 17 Jun 2010 17:15:38 +0200

Hi Alex:

The whole point is to send a packet to nodes that can understand it, isn't it?
If so, RPL nodes that do not support AODV do not need to receive AODV packets, and conversely AODV nodes do not need to receive RPL packets.

I do not see the protocols as mutually exclusive in a given topology, so we'd avoid a useless mix... It's not as is IANA was short in mcast suffixes anyway.

Pascal

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Thursday, June 17, 2010 3:45 PM
> To: Pascal Thubert (pthubert)
> Cc: JP Vasseur; [email-masked]
> If there's a single subnet then there's no hop-by-hop - everything is a single
> link, all within 1 IP hop reach of each other.  Arguably - yes.
> 
> packets to a tree already built, like simply renewing existing information?
> That could be sent to a site-local address.
> 
> WEll I wouldn't go as far as requesting another multicast group address from
> IANA when the MANET group is already there.  We could reuse the MANET
> address.
> 
> asking people how to use their stuff (the IPsec AH), instead of designing new
> things.
> 
> Alex
> 
> >
> > Pascal
> >
> >
> >> [email-masked] Subject: Re: [Roll] Fwd: [roll] #54: Clarification on
> >> multicast
> >>
> >> I think some link layers do some others don't.  For those who don't -
> >> it makes no sense for RPL to require the use of ff02::1.
> >>
> >> For some (Ethernet), it is necessary to make a join operation, with
> >> MLD - otherwise it's not working.  Thus, RPL should say so.
> >> The IPsec discussion mentioned that a single operator may manage all
> >> nodes - thus a single site would be more appropriate...
> >> site-local scope.
> >>
> >> Ok, I didn't mean to require an adaptation layer, just to make sure
> >> what RPL says is appropriate to what some link layers have to  offer.
> >> There may be a risk in RPL assuming some support (specifically
> >> multicast) which the link layer may not offer.  To alleviate this, it
> >> is sufficient for RPL to say, e.g., to use multicast dst addresses
> >> only when such support is available.
> >>
> >>>>>> [email-masked]<mailto:[email-masked]> *Subject: **[Roll] [roll]
> >>>>>> #54: Clarification on multicast* *Reply-To:
> >> --------------------------------+------------------------------------
> >> --------------------------------+---
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> --------------------------------+------------------------------------
> >> --------------------------------+---
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>>>>> items here: 1) Solution for multicast forward on in a non storing
> >>>>>> node network (=>  not a routing issue, outside of the scope of
> >>>>>> the ROLL WG) 2) A few clarifications have been requested: A few
> >>>>>> comments/questions: a. It might be useful to have a few words
> >>>>>> stating whether this solution would work in a large LLN - I,e
> >>>>>> when the members of multicast group is spread across the large
> >>>>>> LLN b. The section says that the router 'should prune' duplicate
> >>>>>> registration messages (DAO) - but it does not say more detail
> >>>>>> about it -I,e is it up to the implementation that pruning would
> >>>>>> be done based on some rules?
> >>>>>>
> >>>>>> -- Ticket URL:

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 17 Jun 2010 17:27:34 +0200

Hi Alex,

> If so, RPL nodes that do not support AODV do not need to receive AODV packets, and conversely AODV nodes do not need to receive RPL packets.

That is not very likely, because AODV runs on IPv4 only ;-)
But seriously, I agree with Pascal that it would be useful to have an
IANA-allocated multicast address for RPL routers (in particular for
such mixed environments, as mentioned my Pascal)

Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 17 Jun 2010 17:29:37 +0200

Hi Alex,

On Thu, Jun 17, 2010 at 4:25 PM, Alexandru Petrescu
<[email-masked]> wrote:
>> [..]

What do you mean by "vague",  "precise" or "structured" topologies?
Which protocols are you talking about? I do not think that we have to
explicitly mention any link-layer in RPL (the same reasons as in MANET
apply, where we had long discussion about this topic).

> [...]

Ulrich

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 Jun 2010 17:32:36 +0200

Le 17/06/2010 17:15, Pascal Thubert (pthubert) a écrit :
> Hi Alex:
>
> The whole point is to send a packet to nodes that can understand it,
>  isn't it? If so, RPL nodes that do not support AODV do not need to
> receive AODV packets, and conversely AODV nodes do not need to
> receive RPL packets.

Sounds right, except that's a "MANET" address not an "AODV" address.
MANET people could agree that AODV, OLSR and presumably more to use that
MANET address... it would make sense for RPL to join the agreement.

> I do not see the protocols as mutually exclusive in a given topology,
> so we'd avoid a useless mix... It's not as is IANA was short in mcast
> suffixes anyway.

Would this creep in new features we actually don't want.

WOuld this request to IANA lengthen the process.

Would other people need this new IANA request.

Would implementers think what.

I will stop talking about this and simply suggest that clarification is
needed with respect to multicast use in RPL.  To address this issue my
suggestion IMHO is to first use the ff02::1 'all-nodes' throughout the
document (eliminate ff02::2 from RPL) and get feedback from
implementation and from WG.  Depending on that feedback see what's next.
  Could be a direction of advancement.

Alex

>
> Pascal
>
>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Thursday, June 17, 2010
>> 3:45 PM To: Pascal Thubert (pthubert) Cc: JP Vasseur; [email-masked]
>> If there's a single subnet then there's no hop-by-hop - everything
>>  is a single link, all within 1 IP hop reach of each other.
>> Arguably - yes.
>>
>>> so it can not use FF05 that expects that the subnet is built in
>>> the first place.
>>
>> Hmmm... how about maintenance (presence, affiliation, routing
>> costs) packets to a tree already built, like simply renewing
>> existing information? That could be sent to a site-local address.
>>
>>> OTOH, your question makes sense to me in that we could wonder why
>>> we use FF02::1 as opposed to FF02::all_RPL_nodes.
>>
>> WEll I wouldn't go as far as requesting another multicast group
>> address from IANA when the MANET group is already there.  We could
>>  reuse the MANET address.
>>
>> It wasn't my bottom line.   How about reusing stuff (the MANET
>> address), asking people how to use their stuff (the IPsec AH),
>> instead of designing new things.
>>
>> Alex
>>
>>>
>>> Pascal
>>>
>>>
>>>> [email-masked] Subject: Re: [Roll] Fwd: [roll] #54:
>>>> Clarification on multicast
>>>>
>>>>>>> c. Is multicast support mandatory if someone implements
>>>>>>> the RPL draft? - if not, is it okay to simulate multicast
>>>>>>> packet distribution using unicast messaging in a
>>>>>>> small/simple LLN ?
>>>>>>>
>>>>> The RPL specification. RFC2119 is used to specify what MUST,
>>>>>  MAY or SHOULD be supported.
>>>>>
>>>>>> Would be please suggest which normative language of which
>>>>>> link layer thank you.
>>>>>
>>>>> We do not. Remember, RPL is an network layer routing
>>>>> protocol. As such, it does NOT mandate the use of any
>>>>> specific link layer.
>>>>
>>>> Well, RPL does mandate the use of ff02::1 dst address.  Is
>>>> this address supported by "any" specific link layer?  Is "any"
>>>> link layer providing a mapping function between the link-layer
>>>>  with MLD - otherwise it's not working.  Thus, RPL should say
>>>> so. Absence of saying so means underspecification.
>>>>
>>>> BEsides - why does the RPL require the use of ff02::1
>>>> (all-routers link-local scope) and not ff05::1 (all-routers
>>>> site-local scope)? The IPsec discussion mentioned that a single
>>>> operator may manage all nodes - thus a single site would be
>>>> more appropriate... site-local scope.
>>>>
>>>> I could raise many similar multicast issues, but most boil down
>>>> to one question: which link-layer(s) is RPL supposed to run on?
>>>> "Any" is as if "none" was said.
>>>>
>>>>>> Some link layers do offer multicast support (IEEE) some
>>>>>> others don't (old RS-232).
>>>>>>
>>>>> On many ... again RPL is not tied to any of them. If there is
>>>>> a need for an adaptation layer to carry IPv6 over a next
>>>>> generation PLC link for example, it will be specified
>>>>> somewhere else, not in ROLL:
>>>>
>>>>  sure what RPL says is appropriate to what some link layers
>>>> have to  offer. There may be a risk in RPL assuming some
>>>> support (specifically multicast) which the link layer may not
>>>> offer. To alleviate this, it is sufficient for RPL to say,
>>>> e.g., to use multicast dst addresses only when such support is
>>>>  available.
>>>>
>>>> Some recent email discussion said "use unicast" in these cases
>>>>  - but how? Would that mandatory ff02::1 multicast address be
>>>> replaced by several unicast addresses?  How?  Simultaneously?
>>>> In which order?
>>>>
>>>>>>> what to implement to be compliant with the RFC. Of
>>>>>>> course, commercial implementation may decide to implement
>>>>>>> some parts of the ID, but this is not an IETF issue. Back
>>>>>>> to the second part of your question, yes some
>>>>>>> implementation to send multiple unicast packets, which
>>>>>>> may be OK in small networks"
>>>>>>>
>>>>>>>> [email-masked]<mailto:[email-masked]>  *Subject:
>>>>>>>> **[Roll] [roll] #54: Clarification on multicast*
>>>>>>>> *Reply-To: [email-masked]<mailto:[email-masked]>
>>>>>>>>
>>>>>>>> Status: new Priority: trivial | Milestone: Component:
>>>>>>>> rpl | Version: Severity: Active WG Document |
>>>>>>>> Keywords:
>>>>>>>>
>>>>>>>> Starting a new ticket on Multicast operations. There
>>>>>>>> are two items here: 1) Solution for multicast forward
>>>>>>>> on in a non storing node network (=>   not a routing
>>>>>>>> issue, outside of the scope of the ROLL WG) 2) A few
>>>>>>>> clarifications have been requested: A few
>>>>>>>> comments/questions: a. It might be useful to have a few
>>>>>>>> words stating whether this solution would work in a
>>>>>>>> large LLN - I,e when the members of multicast group is
>>>>>>>> spread across the large LLN b. The section says that
>>>>>>>> the router 'should prune' duplicate registration
>>>>>>>> messages (DAO) - but it does not say more detail about
>>>>>>>>  it -I,e is it up to the implementation that pruning
>>>>>>>> <http://trac.tools.ietf.org/wg/roll/trac/ticket/54>

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 17 Jun 2010 17:45:47 +0200

Hi Alex,

> MANET address... it would make sense for RPL to join the agreement.

OLSR and AODV do not use the LL-MANET-Routers address (also, they do
not support IPv6). OLSRv2 and DYMO do use the address, but they both
use the same packet format (RFC5444) and the same neighbor discovery
(NHDP). As such, they can parse the messages correctly, and use the
same information from NHDP, even in mixed environments. RPL could not
even parse an RFC5444-formatted message (and vice verse).

Ulrich

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 Jun 2010 17:47:52 +0200

Hi Ulrich,

Le 17/06/2010 17:29, Ulrich Herberg a écrit :
>> IMHO, some MANET protocols deal with topologies as vague as RPL
>> does.  I am looking for structure in the topology.  Most
>> deployments use very structured topologies with precise ideas on
>> the link layers.
>>
>> When these very protocols are tried in practice they are exercised
>> with very precise topologies... except that afterwards we don't
>> mention them... leaving all vague, talking arbitrary movements,
>> universal support.  In this context it's hard to reach agreement.
>

Vague - I mean that the topologies on which MANET protocols run are
unknown, or little known, vaguely known.

Structured topologies: are the topologies on which we know more than
just vagueness, for example we identified specific roles for routers and
specific movement patterns, and we also identified the existing IPv6
protocols running already on these topologies prior to deploying MANET
(e.g. prior to deploying OLSR we identified how ND is already there,
what it does and how e.g. link-local addresses are used).

Unstructured topology: we believe nothing is there running, we need to
reinvent Internet because nothing is really applicable to my
unstructured and vaguely defined topology of link layers.

> Which protocols are you talking about?

For example the discussion applies to OLSR and ND.

> I do not think that we have to explicitly mention any link-layer in
> RPL (the same reasons as in MANET apply, where we had long
> discussion about this topic).

I think we should say clearly in the RPL document what are the
characteristics of the link layers on which RPL is supposed to run.  The
multicast feature of the link layer is an example.

Another: it may be very well the case that one particular link layer
which is the basis for much thrust behind RPL is actually already
offering much of the 'routing' capabilities which RPL strives to deliver.

It may very well be the case that the results of RPL discussions are
reused in other IEEE documents for completely different goals than the
original intention of the discussion here in this WG.

That about vagueness, rant off.

Alex

---

From: Henning Rogge <[email-masked]>
Date: Thu, 17 Jun 2010 17:55:59 +0200

Am Donnerstag 17 Juni 2010, 17:45:47 schrieb Ulrich Herberg:
> OLSR and AODV do not use the LL-MANET-Routers address
You can use the LL-MANET-multicast IP with OLSR. No problem with this.

> (also, they do not support IPv6).
OLSR supports both IPv4 and IPv6 (but not both at the same time).

> OLSRv2 and DYMO do use the address, but they both
packetbb-messages (rfc5444) are limited to a certain UDP port or IP protocol 
number. So it would be no problem to use different protocols with the same 
multicast, just use a different port/ip-protocol number.

Henning Rogge

-- 
1) You can't win.
2) You can't break even.
3) You can't leave the game.
— The Laws of Thermodynamics, summarized

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Thu, 17 Jun 2010 12:48:15 -0700

Hi JP,

Thanks for addressing the multicast comments. Please see below in-line.

From: [email-masked] [mailto:[email-masked]] On Behalf Of JP
Vasseur
Sent: Wednesday, June 16, 2010 11:07 PM
To: ROLL WG
Subject: [Roll] Fwd: [roll] #54: Clarification on multicast

Dear all,

c. Is multicast support mandatory if someone implements the RPL draft? - if
not, is it okay to simulate multicast packet distribution using unicast
messaging in a small/simple LLN ?

The answer is: look at the normative language. This is what tells you what
to implement to be compliant with the RFC. Of course, commercial
implementation may decide to implement some parts of the ID, but this is not
an IETF issue.

[SC>]  The reason I asked this question is for interoperability of the
implementations among vendors. I suppose multicast feature in RPL is
optional and not a MUST - right?

 Back to the second part of your question, yes some implementation to send
multiple unicast packets, which may be OK in small networks"

[SC>] Yes, agree. Thanks.

-Samita

Begin forwarded message:

Cc: [email-masked]

Reply-To: [email-masked]

#54: Clarification on multicast
--------------------------------+-------------------------------------------
Reporter:  jpv@.               |       Owner:  pthubert@.        
    Type:  defect              |      Status:  new               
Priority:  trivial             |   Milestone:                    
Component:  rpl                 |     Version:                    
Severity:  Active WG Document  |    Keywords:                    
--------------------------------+-------------------------------------------
Starting a new ticket on Multicast operations.
There are two items here:
1) Solution for multicast forward on in a non storing node network (=> not
a routing issue, outside of the scope of the ROLL WG)
2) A few clarifications have been requested:
A few comments/questions:
a. It might be useful to have a few words stating whether this solution
would work in a large LLN - I,e when the members of multicast group is
spread across the large LLN
b. The section says that the router 'should prune' duplicate registration
messages (DAO) - but it does not say more detail about it -I,e is it up to
the implementation that pruning would be done based on some rules?

---

From: Henning Rogge <[email-masked]>
Date: Fri, 18 Jun 2010 07:47:38 +0200

> Hope you're doing good these days;
Yes, I am. :)

> I'm afraid MANET is a little vague. We cant to pinpoint nodes that support
> our protocol. No point in sending DIS or DIO to an OSLRv2 node.
> 
> What do you think?

I think all routing mesh protocols (including olsr, ripple, aodv) start with 
sending linklocal broadcasts/multicasts. Stations not equipped with the 
correct protocol will ignore this message because they do not handle the 
corresponding port or ip-protocol number. So you would never send RPL unicast 
messages to this nodes.

Henning Rogge

---

From: JP Vasseur <[email-masked]>
Date: Fri, 18 Jun 2010 08:23:31 +0200

Hi,

On Jun 17, 2010, at 9:48 PM, Samita Chakrabarti wrote:

> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of JP Vasseur
> The answer is: look at the normative language. This is what tells  
> you what to implement to be compliant with the RFC. Of course,  
> ID, but this is not an IETF issue.
> [SC>]  The reason I asked this question is for interoperability of  
> the implementations among vendors. I suppose multicast feature in  
> RPL is optional and not a MUST – right?

The implementation specifies how to propagate multicast address, an  
implementation may choose not to implement this part indeed.

>
>  Back to the second part of your question, yes some implementation  
> to send multiple unicast packets, which may be OK in small networks"

Thanks.

JP.

> up to

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 18 Jun 2010 10:13:49 +0200

Hi Henning:

Sure. And the whole point of defining multicast addresses like 224.0.0.5 for IPv4 or FF02::5 for IPv6 for OSPF is that this happens at the lowest level possible (like a NIC card). 

All:

The poll on the table is for RPL messages to be sent to:

- all nodes		[RFC4291]
- all routers		[RFC4291]
- LL MANET nodes 	[RFC5498]
- LL RPL nodes 		[that we need to request to IANA] 

You'll note that RFC 3111 alone reserves 1000 mcast addresses and it's not like there's a shortage for new assignment.

Votes?

Pascal

> From: Henning Rogge [mailto:[email-masked]]
> Sent: Friday, June 18, 2010 7:48 AM
> > I'm afraid MANET is a little vague. We cant to pinpoint nodes that
> > support our protocol. No point in sending DIS or DIO to an OSLRv2 node.
> >
> > What do you think?
> 
> corresponding port or ip-protocol number. So you would never send RPL
> unicast messages to this nodes.
> 
> Henning Rogge
> 
> --

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 18 Jun 2010 10:53:58 +0200

Le 18/06/2010 10:13, Pascal Thubert (pthubert) a écrit :
> Hi Henning:
>
> Sure. And the whole point of defining multicast addresses like
> 224.0.0.5 for IPv4 or FF02::5 for IPv6 for OSPF is that this happens
> at the lowest level possible (like a NIC card).
>

?  These IP multicast addresses are defined in RFCs and implemented in
the stack or in the routing application.  The NIC cards often implement
the _link-layer_ multicast addresses, and there are mapping mechanisms
between the link-layer mc addresses and the IP mc addresses.

> The poll on the table is for RPL messages to be sent to:

I agree with this - all nodes - it means both Hosts and Routers.

> - all routers		[RFC4291]

Neutral.  I believe this "all routers" would be covered when we use "all
nodes".

> - LL MANET nodes 	[RFC5498]

Neutral.  I find value to reuse this MANET address, but maybe "all
nodes" is easier to reuse, because spread already on larger scale (more
implementations do "all nodes" than "MANET nodes").

> - LL RPL nodes 		[that we need to request to IANA]

I currently disagree with this because it would imply more work to IANA,
lengthen the process, more implementation effort constant files updated;
it would require new messages to be sent too (to join this new group),
whereas if we go with the existing "all-nodes" address the join
operation is happening already for other operations like ND.

FWIW.

Alex

>
> You'll note that RFC 3111 alone reserves 1000 mcast addresses and
> it's not like there's a shortage for new assignment.
>
> Votes?
>
> Pascal
>
>> -----Original Message----- From: Henning Rogge
>> [mailto:[email-masked]] Sent: Friday, June 18,
>> 2010 7:48 AM To: Pascal Thubert (pthubert) Cc: [email-masked]
>>> I'm afraid MANET is a little vague. We cant to pinpoint nodes
>>> that support our protocol. No point in sending DIS or DIO to an
>>> OSLRv2 node.
>>>
>>> What do you think?
>>
>> I think all routing mesh protocols (including olsr, ripple, aodv)
>> start with sending linklocal broadcasts/multicasts. Stations not
>> equipped with the correct protocol will ignore this message because
>> they do not handle the corresponding port or ip-protocol number. So
>> you would never send RPL unicast messages to this nodes.
>>
>> Henning Rogge
>>
>> -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
>> Germany Telefon +49 228 9435-961,   Fax +49 228 9435 685
>> mailto:[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Jun 2010 10:17:10 -0400

>>>>> "Pascal" == Pascal Thubert <(pthubert)" <[email-masked]>> writes:
    Pascal> Hi Henning:

    Pascal> Sure. And the whole point of defining multicast addresses like 224.0.0.5 for IPv4 or FF02::5 for IPv6 for OSPF is that this happens at the lowest level possible (like a NIC card). 

    Pascal> All:

    Pascal> The poll on the table is for RPL messages to be sent to:

    Pascal> - all nodes		[RFC4291]
    Pascal> - all routers		[RFC4291]
    Pascal> - LL MANET nodes 	[RFC5498]
    Pascal> - LL RPL nodes 		[that we need to request to IANA] 

    Pascal> You'll note that RFC 3111 alone reserves 1000 mcast
    Pascal> addresses and it's not like there's a shortage for new
    Pascal> assignment. 

I have been operating with an assumption since the begining that there
are host-only nodes that are logically on the LL network, but not
physically. That is, they do not have "radios", but are permanently
wired to some node that does have a radio. (My forklift example of a few
weeks ago)

If we send to all-nodes, then we wake up those nodes, so I am opposed to
doing that.

If someone can give an example of a MANET *node* which isn't also
listening as a router, then that would be great.  If there is a
situation where we believe that there will MANET nodes which do not
intend to participate as RPL nodes, then I guess that would argue for a
multicast group.

Let me also go the other way: is there some argument (such number of
common radio MAC devices) which are would fill their multicast filters
if we allocate another multicast group?

Given that we are not doing DAD or ND using the default rfc4861, do we
really need to listen on the all-nodes/all-routers groups?  

My preferences are therefore:
   a) get a new multicast group
   b) all-routers group
   c) LL MANET nodes

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 18 Jun 2010 16:25:44 +0200

On Jun 17, 2010, at 5:29 PM, Ulrich Herberg wrote:

>> does.  I
>> with

Agree.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 18 Jun 2010 17:41:04 +0200

Le 18/06/2010 16:25, JP Vasseur a écrit :
>>> When these very protocols are tried in practice they are
>>> exercised with very precise topologies... except that afterwards
>>> we don't mention them... leaving all vague, talking arbitrary
>>> movements, universal support. In this context it's hard to reach
>>> agreement.
>>
>>  Which protocols are you talking about? I do not think that we
>> have to explicitly mention any link-layer in RPL (the same reasons
>> as in MANET apply, where we had long discussion about this topic).
>
> Agree.

Well - we could mention in discussion the link layers of concern to RPL
and then we'll have different conclusions to write in the spec.

To avoid coming coming later saying RPL works only on Ethernet,
questioning why non-Ethernet users don't employ it.

This unfortunate situation was seen often in mobility groups: prototype
on Ethernet and wrongly assume everything else should work as on
Ethernet.  It's not the case: M2M cellular, zigbee, RS-232, USB all act
differently... making some Ethernet-guided core protocol concepts
superfluous: HA, AR, address-per-node, ND, more.

For example in RPL: if we rely on the use of link-layer multicast
addresses and later see that M2M cellular don't use them - our spec
request to use multicast address is completely superfluous on
point-to-point links.

Another RPL example: we rely on Tree links experience and talk
point-to-point and then go to M2M cellular and learn that point-to-point
is actually ppp protocol - no wonder it doesn't get implemented.

Please mention the link layers and their behaviours.

Alex

>
> JP.
>
>>
>>
>>> [...]
>>
>>
>> Ulrich _______________________________________________ Roll
>> mailing list [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 18 Jun 2010 18:36:43 +0200

Le 18/06/2010 16:17, Michael Richardson a écrit :
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>
>
>>>>>> "Pascal" == Pascal
>>>>>> Thubert<(pthubert)"<[email-masked]>> writes:
> Pascal>  Hi Henning:
>
> Pascal>  Sure. And the whole point of defining multicast addresses
> like 224.0.0.5 for IPv4 or FF02::5 for IPv6 for OSPF is that this
> happens at the lowest level possible (like a NIC card).
>
> Pascal>  All:
>
> Pascal>  - all nodes		[RFC4291] Pascal>  - all routers		[RFC4291]
> Pascal>  - LL MANET nodes 	[RFC5498] Pascal>  - LL RPL nodes 		[that
> we need to request to IANA]
>
> Pascal>  You'll note that RFC 3111 alone reserves 1000 mcast Pascal>
> addresses and it's not like there's a shortage for new Pascal>
> assignment.
>
> I have been operating with an assumption since the begining that
> there are host-only nodes that are logically on the LL network, but
> not physically. That is, they do not have "radios", but are
> permanently wired to some node that does have a radio. (My forklift
> example of a few weeks ago)

This is an interesting assumption.  Old Host-IMP would be similar.

> If we send to all-nodes, then we wake up those nodes, so I am
> opposed to doing that.

Hm, I would consider the router be the "radio" part, and it would be
necessary to wake them up.  The Host part would be separated from the
Router, by a different link, with a different link scope, and hence the
link-locally addressed multicast message would traverse to wake them up.

Related, the risk of waking up entities not needing so could be
alleviated by the link layer filters: some link layers provide such
filters, and consider they've "joined" a scope only when they decided to
not be asleep.

In general, whenever using multicast I would wonder how these groups are
joined and left, by the nodes.  With Ethernet (which seems to be the
main experience here too) this happens with MLD messages, which is good.
  They are there and RPL shoudl reuse them.

On another hand - with USB (and WUSB I presume) there's no MLD
operation, no IPv6 over USB.  Thus I believe RPL should specify how to
join these groups, _before_ being able to send or receive messages from
them.  The same with M2M cellular.

I believe RPL spec should specify that it needs to join groups _before_
sending and receiving packets to these groups, specify how to  leave
these groups, and list informally the various means (MLD, filters,
other) to do so.

> listening as a router, then that would be great.

I wonder too.  In that case it would no longer be a node but a router
(not a host).  A node is typically understood to be both a router and a
host.  There is an RFC with terminology of "node", "router", "host".

> If there is a situation where we believe that there will MANET nodes
> which do not intend to participate as RPL nodes, then I guess that
> would argue for a multicast group.

You mean a specific RPL multicast group?

>  common radio MAC devices) which are would fill their multicast
> filters if we allocate another multicast group?

I agree with the question.  If the node has too little memory to manage 
so many memberships (3 already defined) then we should restrain from 
defining yet another group.

> Given that we are not doing DAD or ND using the default rfc4861, do
> we really need to listen on the all-nodes/all-routers groups?

These groups are not only for DAD/ND but also for autoconf - I want 
SLAAC to work.  There may be other protocols employing these all-nodes 
and all-routers groups.

Alex

> My preferences are therefore: a) get a new multicast group b)
> all-routers group c) LL MANET nodes
>
> - -- ]       He who is tired of Weird Al is tired of life! |
> firewalls  [ ]   Michael Richardson, Sandelman Software Works,
> Ottawa, ON    |net architect[ ] [email-masked]
> http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch
> the video<http://www.youtube.com/watch?v=kzx1ycLXQSE> then sign the
> petition.
>
>
> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBTBt/5YCLcPvd0N1lAQLabQf/QflTEKz43YoSudh35+5zOsuk3PzegPMA
> qk88OBPjascFSwkgApd95CgtKfaQ1TtNG0svcxjX2zM4WCXLXDs8Wp/hroSw6BsI
> mBiN1g7xjFEGLQ+onJ5w+jzZC7hu58pYyvzhi7yRhA6hATVEjJC7131s4eWarzx6
> Jg8VSROxtLlckxMY4gRJ8DDv22Jha2CKSeiLuYp2TpFX/AOabzmoR5RYoJCTlMHf
> 2JtxPFefQhP9BC1NM2FVRRig1Z7m1vtzpjseWAi3mjS971E+f0PABPSqx0xCUU5A
> JqHCtaxNAlF3iY+Qc5nTIxV/4X5JWdZrnuF/OPa4SJIEyAZGev8K1Q== =VMuw
> -----END PGP SIGNATURE-----

---

From: "roll issue tracker" <[email-masked]>
Date: Fri, 25 Jun 2010 09:24:38 -0000

#54: Clarification on multicast
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |        Owner:  pthubert@…        
     Type:  defect              |       Status:  closed            
 Priority:  trivial             |    Milestone:                    
Component:  rpl                 |      Version:                    
 Severity:  Active WG Document  |   Resolution:  fixed             
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by jpv@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Here is the new text (will be incorporated in revision -10):

 11.  Multicast Operation

    This section describes further the multicast routing operations over
    an IPv6 RPL network, and specifically how unicast DAOs can be used to
    relay group registrations up.  Wherever the following text mentions
    Multicast Listener Discovery (MLD), one can read MLDv1 ([RFC2710]) or
    MLDv2 ([RFC3810]).

    Nodes that support the RPL storing mode of operation SHOULD also
    support multicast DAO operations as described below.  Nodes that only
    support the non-storing mode are not expected to support this
    section.

    The multicast operation is controlled by the MOP field in the DIO.

       If the MOP field requires the multicast support, then a node that
       joins the RPL network as a router must operate as described below
       for multicast signalling and forwarding within the RPL network.  A
       node that does not support this feature can only join as a leaf.

       If the MOP field does not requiere the multicast support, then
       multicast is handled by some other way that is out of scope for
       this specification, like series of unicast copies or a flooding
       from the root.

    As is traditional, a listener uses a protocol such as MLD with a
    router to register to a multicast group.

    Along the path between the router and the DODAG root, MLD requests
    are mapped and transported as DAO messages within the RPL protocol;
    each hop coalesces the multiple requests for a same group as a single
    DAO message to the parent(s), in a fashion similar to proxy IGMP, but
    recursively between child router and parent up to the root.

    A router might select to pass a listener registration DAO message to
    its preferred parent only, in which case multicast packets coming
    back might be lost for all of its sub-DODAG if the transmission fails
    over that link.  Alternatively the router might select to copy
    additional parents as it would do for DAO messages advertising
    unicast destinations, in which case there might be duplicates that
    the router will need to prune.

    As a result, multicast routing states are installed in each router on
    the way from the listeners to the root, enabling the root to copy a
    multicast packet to all its children routers that had issued a DAO
    message including a DAO for that multicast group, as well as all the
    attached nodes that registered over MLD.

 Winter, et al.          Expires December 26, 2010              [Page 76]

 Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010

    For unicast traffic, it is expected that the grounded root of an
    DODAG terminates RPL and MAY redistribute the RPL routes over the
    external infrastructure using whatever routing protocol is used in
    the other routing domain.  For multicast traffic, the root MAY proxy
    MLD for all the nodes attached to the RPL domain (this would be
    needed if the multicast source is located in the external
    infrastructure).  For such a source, the packet will be replicated as
    it flows down the DODAG based on the multicast routing table entries
    installed from the DAO message.

    For a source inside the DODAG, the packet is passed to the preferred
    parents, and if that fails then to the alternates in the DODAG.  The
    packet is also copied to all the registered children, except for the
    one that passed the packet.  Finally, if there is a listener in the
    external infrastructure then the DODAG root has to further propagate
    the packet into the external infrastructure.

    As a result, the DODAG Root acts as an automatic proxy Rendezvous
    Point for the RPL network, and as source towards the Internet for all
    multicast flows started in the RPL LLN.  So regardless of whether the
    root is actually attached to the Internet, and regardless of whether
    the DODAG is grounded or floating, the root can serve inner multicast
    streams at all times.

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/54#comment:1>
roll <http://tools.ietf.org/wg/roll/>