Subject: [Roll] New Text for the Charter

From: JP Vasseur <[email-masked]>
Date: Mon, 16 Feb 2009 13:32:07 +0100

With all agreed changes ...

Description of Working Group:
Low power and Lossy networks (LLNs) are made up of many
embedded devices with limited power, memory, and processing resources.  
They are
interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth,
Low Power WiFi, wired or other low power PLC (Powerline Communication)  
links. LLNs are transitioning to an end-to-end IP-based
  solution to avoid the problem of non-interoperable networks
interconnected by protocol translation gateways and proxies.

Generally speaking, LLNs have at least five distinguishing  
characteristics:
-       LLNs operate with a hard, very small bound on state,
-       In most cases, LLN optimize for energy saving,
-       Typical traffic patterns are not simply unicast flows (e.g. in  
some environments most if not all traffic can be point to multipoint),
-       In most cases, LLNs will be employed over link layers with  
restricted frame-sizes, thus a routing protocol for LLNs should be  
specifically adapted for such link layers.
-       LLN routing protocols have to be very careful when trading off  
efficiency for generality; many LLN nodes do not have resources to  
waste.

These specific properties cause LLNs to have specific routing  
requirements. As shown in a protocol survey existing routing protocols  
(in their current form) such as OSPF, IS-IS, AODV, and OLSR, do not  
meet these specific routing requirements.

The Working Group is focused on routing issues for LLN.

There is a wide scope of application areas for LLNs, including
  industrial monitoring, building automation (HVAC, lighting, access
control, fire), connected homes, healthcare, environmental monitoring,
urban sensor networks (e.g. Smart Grid), assets tracking.
The Working Group focuses on routing solutions for a subset of
these: industrial, connected home, building and urban
  sensor networks for which routing requirements have been specified.  
These application-specific routing requirement documents will be used  
for protocol design.

The Working Group focuses only on IPv6 routing architectural
  framework for these application scenarios. The Framework will take  
into consideration various
  aspects including high reliability in the presence of time varying  
loss
  characteristics and connectivity while permitting low-power operation
  with very modest memory and CPU pressure in networks potentially
comprising a very large number (several thousands) of nodes.

The Working Group will pay particular attention to routing security and
manageability (e.g., self routing configuration) issues. It will also  
need to
  consider the transport characteristic the routing protocol messages  
will
  experience. Mechanisms that protect an LLN from congestion collapse or
  that establish some degree of fairness between concurrent  
communication
sessions are out of scope of the Working Group. It is expected that
  upper-layer applications utilizing LLNs define appropriate mechanisms.

Work Items:

- Specification of routing metrics used in path calculation. This
includes static and dynamic link/node attributes required for routing in
LLNs.

- Provide an architectural framework for routing and path selection at
  Layer 3 (Routing for LLN Architecture) that addresses such issues as
whether LLN routing protocols require a distributed and/or centralized
  path computation models, whether additional hierarchy is necessary and
how it is applied. Manageability will be considered with each approach,
  along with various trade-offs for maintaining low power operation,
  including the presence of non-trivial loss and networks with a very
  large number of nodes.

- Produce a routing security framework for routing in LLNs.
- Protocol work: In light of the application specific routing  
requirements, the Working Group will either specify a new protocol and/ 
or will select an existing routing protocol (with the appropriate  
extensions in cooperation with the relevant Working Group).
- Documentation of applicability statement of ROLL routing protocols.
Goals and Milestones:
Done   Submit Routing requirements for Industrial applications to the  
IESG to be considered as an Informational RFC.
Done Submit  Routing requirements for Connected Home networks  
applications to the IESG to be considered as an Informational RFC.
Done   Submit Routing requirements for Building applications to the  
IESG to be considered as an Informational RFC.
Done  Submit Routing requirements for Urban networks applications to  
the IESG to be considered as an Informational RFC.
July 2009    Submit Routing metrics for LLNs document to the IESG to  
be considered as a Proposed Standard.
* Feb 2009   Submit Protocol Survey to the IESG to be considered as an  
Informational RFC.
April 2009   Submit Security Framework to the IESG to be considered as  
an Informational RFC
May 2009     Submit the Routing for LLNs Architecture document to the  
IESG as an Informational RFC.
July 2009    Submit first draft of ROLL routing protocol specification  
as Proposed Standard.
Nov 2009     Submit first draft of the MIB module of the ROLL routing  
protocol specification.
Feb 2010     Submit the ROLL routing protocol specification to the  
IESG as Proposed Standard.
March 2010     Submit the MIB module of the ROLL routing protocol  
specification to the IESG as Proposed Standard.
April 2010     Evaluate WG progress, recharter or close.

PS: I marked * the Milestones that will be "This Week" and before  
submitting to the IESG for re-chartering.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2009 14:36:07 +0100

JP Vasseur a écrit :
> Description of Working Group: Low power and Lossy networks (LLNs) are
> made up of many embedded devices with limited power, memory, and
> processing resources. They are interconnected by a variety of links,
> such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low
> power PLC (Powerline Communication) links.

I disagree saying "low power PLC links".

Alex

---

From: "Daniel Smolinski" <[email-masked]>
Date: Mon, 16 Feb 2009 14:39:04 +0100

While we cannot agree on the low-power part of PLC, maybe we can agree to:

.. such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other lossy
links, e.g. PLC.

Regards,
Daniel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexandru Petrescu
Sent: Montag, 16. Februar 2009 14:36
To: JP Vasseur
Cc: ROLL WG
Subject: Re: [Roll] low power PLC (Was: New Text for the Charter)

Alex

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

Renesas Technology Europe GmbH
Sitz: Ratingen, Amtsgericht Duesseldorf, HRB 44903
Geschaeftsfuehrer: Peter Mies, Tsutomu Miki, Matthew Trowbridge, Holger Zielke

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2009 14:43:55 +0100

> .. such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other lossy

In principle yes, but it mixes link-layer specific technologies (15.4, 
wifi) with generic calls such as 'wired', lossy PLC.

And I'm not sure why Low Power WiFi deserves capitalization either.  Is 
it low-power WiFi instead?  Does this low-power WiFi technology have a 
specific name at IEEE?

Alex

---

From: [email-masked]
Date: Mon, 16 Feb 2009 16:30:18 -0600

Thanks for collating all the comments.  It was getting hard to follow the 
changes.  Unfortunately (for you), now I have more comments.  Interlaced 
below ...

JP Vasseur <[email-masked]> 
Sent by: [email-masked]
02/16/2009 06:32 AM

To
ROLL WG <[email-masked]>
cc

Subject
[Roll] New Text for the Charter

As best as I know, Bluetooth is a point-to-point protocol only.  Not sure 
if it's a good example of mesh networks.

Not sure what you mean by 'energy savings'.  In past email threads we've 
discussed the need to balance energy in LLNs  That is, use a node's 
available power as a input to the path cost.  This doesn't really 'save' 
energy, it either 'balances' or 'conserves' energy.  (NOTE: minor point, 
feel free to ignore).

Typically the term is 'asset tracking' rather than 'assets tracking'

Not sure I'd use the word 'pressure'. How 'bout 'resources'.

I'm not sure what provoked this change from the original version.  If I 
read this correctly, you believe that balancing communication or providing 
prioritized messaging (e.g. QoS) is outside the scope of the routing layer 
and in the province of the application.  That can't be.  Even if the 
source node's application could somehow regulate what and when messages 
get sent to the lower layers (unlikely); once the packet leaves the source 
node and starts its hopping, the routing layer on all intermediate nodes 
will have to handle the packet prioritization. 

Work Items:

---

From: "M. B. Anand" <[email-masked]>
Date: Mon, 16 Feb 2009 17:47:43 -0500

Jerry,
>
> */As best as I know, Bluetooth is a point-to-point protocol only.  Not 
> sure if it's a good example of mesh networks./*
It defines a PHY and MAC and an LLC(even there it is actually 
point-to-multipoint) and in that respect is as much suited for mesh as 
any other. We have examples of operating large mesh networks (10s of K) 
with it.

Regards,
Anand.

---

From: Kris Pister <[email-masked]>
Date: Mon, 16 Feb 2009 15:23:56 -0800

Anand - is it Bluetooth (the industrial Special Interest Group) that 
defines the phy/max/llc, or IEEE 802.15.1?
My understanding is that for our purposes, we'd use just what the IEEE 
standardized (phy/mac/llc) so that we could use plentiful low-cost 
radios, but not include the higher-layer stuff that the Bluetooth SIG 
specifies for applications.

yes/no/maybe?

ksjp

M. B. Anand wrote:
> Jerry,
>>
>> */As best as I know, Bluetooth is a point-to-point protocol only.  
>> Not sure if it's a good example of mesh networks./*
> any other. We have examples of operating large mesh networks (10s of 
> K) with it.
>
> Regards,
> Anand.

---

From: "M. B. Anand" <[email-masked]>
Date: Mon, 16 Feb 2009 19:13:55 -0500

Kris,
15.1 is Bluetooth 1.1 and it actually defines the same conformance as 
Bluetooth as a normative annex, and you do need to get 
Bluetooth-qualified in order to comply with this. You don't need all the 
application profiles to qualify but there is a minimal generic subset. 
So, the answer here is maybe, depending on what one needs for qualification.

Of course, Bluetooth itself is now at version 2.1 and draft 3.0, so for 
those, there is no equivalent IEEE.

Regards,
Anand.
>> point-to-multipoint) and in that respect is as much suited for mesh 
>> as any other. We have examples of operating large mesh networks (10s 
>> of K) with it.
>>
>> Regards,
>> Anand.

---

From: JP Vasseur <[email-masked]>
Date: Tue, 17 Feb 2009 09:07:00 +0100

Hello Jerry,

On Feb 16, 2009, at 11:30 PM, [email-masked] wrote:

>
> Thanks for collating all the comments.  It was getting hard to  
> follow the changes.  Unfortunately (for you), now I have more  
> comments.  Interlaced below ...
>

That was my fear ;-))) - In line,

> As best as I know, Bluetooth is a point-to-point protocol only.  Not  
> sure if it's a good example of mesh networks.

The meshing is at the Layer 3.

> Not sure what you mean by 'energy savings'.  In past email threads  
> we've discussed the need to balance energy in LLNs  That is, use a  
> node's available power as a input to the path cost.  This doesn't  
> really 'save' energy, it either 'balances' or 'conserves' energy.   
> (NOTE: minor point, feel free to ignore).

Thanks - If you balance energy, this is to "save" energy on some node.  
Let's keep that wording.

> Typically the term is 'asset tracking' rather than 'assets tracking'

Yes Thanks.

> I'm not sure what provoked this change from the original version.   
> If I read this correctly, you believe that balancing communication  
> or providing prioritized messaging (e.g. QoS) is outside the scope  
> of the routing layer and in the province of the application.  That  
> can't be.  Even if the source node's application could somehow  
> regulate what and when messages get sent to the lower layers  
> (unlikely); once the packet leaves the source node and starts its  
> hopping, the routing layer on all intermediate nodes will have to  
> handle the packet prioritization.

This has not been changed and was there from day one. I would insist  
to keep it since this is the result of discussion with other ADs to  
avoid ambiguity: Yes, application related issues are not in our scope.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 18 Feb 2009 10:24:17 -0000

> With all agreed changes ...

I'm not sure if this is too late or not. If it isn't too late,
here's my one comment. If it is, then OK, not in the charter,
but do you see it as (a), (b) or (c)?

Apart from timescale questions, the only issue I see, which
others have commented on, is that one of the five distinguishing
characteristics is that simple unicast flows are not typical,
but nothing is then said about this in the work items.

I think that the work items should clearly indicate whether
(a) unicast only [but that disagrees with the characteristics],
(b) unicast and multicast [significantly more work, and is this
a single routing protocol, as in the plan, or not?], or
(c) determining whether multicast is required is part of
the work [but that's not really consistent with the plan
as written].

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: [email-masked]
Date: Wed, 18 Feb 2009 08:15:10 -0600

Multicast  (actually broadcast) is a definite requirement in the 
commercial sector.  We use it for on-line discovery and binding to devices 
and objects.

"Dearlove, Christopher (UK)" <[email-masked]> 
Sent by: [email-masked]
02/18/2009 04:24 AM

To
"JP Vasseur" <[email-masked]>, "ROLL WG" <[email-masked]>
cc

Subject
Re: [Roll] New Text for the Charter

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 18 Feb 2009 16:17:19 +0100

Chris, Jerald,  you both bring up an important question that I hadn't  
fully realized: to which extend is the output of ROLL going to be an  
unicast routing protocol? Multicast routing protocol? Multicast  
transport protocol? Something else? All or some of the above?  
Neither? In one protocol?

I think that the charter might want to be a bit more specific on this  
matter.

I'd think that if ROLL wants to produce a single protocol doing both  
uni- and multicast routing, then this should be spelled out  
explicitly in the charter. If ROLL wants to produce both an unicast  
routing protocol and a multicast routing protocol, then this also  
should be spelled out explicitly in the charter.

(( This is in a way linked to the survey I-D draft-ietf-roll- 
protocols-survey, which evaluates unicast routing protocols and  
mechanisms only, with no mention of multicast or broadcast  
capabilities. If broad/multicast is such a definite requirement, then  
it might have been easier to dismiss all unicast routing protocols by  
stating that "they ain't doing multicasting", i.e. on functional  
grounds. ))

Cheers,

Thomas

On Feb 18, 2009, at 15:15 PM, [email-masked] wrote:

> commercial sector.  We use it for on-line discovery and binding to  
> devices and objects.
>
>
>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 18 Feb 2009 16:22:25 -0000

In my (a) to (c) I didn't consider multicast only as an option.
Logically I should have done, though I doubt it will be the case.
There are some uses for unicast.

 

________________________________

From: Thomas Heide Clausen [mailto:[email-masked]] 
Sent: 18 February 2009 15:17
To: [email-masked]
Cc: Dearlove, Christopher (UK); ROLL WG
Subject: Re: [Roll] New Text for the Charter

*** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
Keep this in mind if you answer this message. 
	
Chris, Jerald,  you both bring up an important question that I hadn't
fully realized: to which extend is the output of ROLL going to be an
unicast routing protocol? Multicast routing protocol? Multicast
transport protocol? Something else? All or some of the above? Neither?
In one protocol? 

I'd think that if ROLL wants to produce a single protocol doing both
uni- and multicast routing, then this should be spelled out explicitly
in the charter. If ROLL wants to produce both an unicast routing
protocol and a multicast routing protocol, then this also should be
spelled out explicitly in the charter.

(( This is in a way linked to the survey I-D
draft-ietf-roll-protocols-survey, which evaluates unicast routing
protocols and mechanisms only, with no mention of multicast or broadcast
capabilities. If broad/multicast is such a definite requirement, then it
might have been easier to dismiss all unicast routing protocols by
stating that "they ain't doing multicasting", i.e. on functional
grounds. ))

Cheers,

Thomas

	

02/18/2009 04:24 AM 

To
	
Subject

	

	

********************************************************************
	This email and any attachments are confidential to the intended
	recipient and may also be privileged. If you are not the
intended
	recipient please delete it from your system and notify the
sender.
	You should not copy it or use it for any purpose nor disclose or
	distribute its contents to any other person.

---

From: Philip Levis <[email-masked]>
Date: Wed, 18 Feb 2009 09:56:32 -0800

Comment follows.

On Feb 18, 2009, at 7:17 AM, Thomas Heide Clausen wrote:

> Chris, Jerald,  you both bring up an important question that I  
> hadn't fully realized: to which extend is the output of ROLL going  
> to be an unicast routing protocol? Multicast routing protocol?  
> Multicast transport protocol? Something else? All or some of the  
> above? Neither? In one protocol?
>
> I think that the charter might want to be a bit more specific on  
> this matter.
>

Thomas, I have to disagree on this point. I think that this decision,  
in and of itself, is protocol design. It would be a real mistake to  
bind the WG to one approach or the other without any examination of  
the tradeoffs of each approach. But that examination is what the re- 
chartering is for.

For example, if the charter says "one protocol" but then this one  
protocol becomes clearly inferior to an approach with two protocols,  
we're in a bind. If the charter says "two protocols" but then there's  
a protocol that handles both seamlessly (and so has simpler code),  
we're in a bind.

Phil

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 18 Feb 2009 19:17:58 +0100

On Feb 18, 2009, at 18:56 PM, Philip Levis wrote:

>> I'd think that if ROLL wants to produce a single protocol doing  
>> both uni- and multicast routing, then this should be spelled out  
>> explicitly in the charter. If ROLL wants to produce both an  
>> unicast routing protocol and a multicast routing protocol, then  
>> this also should be spelled out explicitly in the charter.
>
> Thomas, I have to disagree on this point. I think that this  
> decision, in and of itself, is protocol design. It would be a real  
> mistake to bind the WG to one approach or the other without any  
> examination of the tradeoffs of each approach. But that examination  
> is what the re-chartering is for.
>
> protocol becomes clearly inferior to an approach with two  
> protocols, we're in a bind. If the charter says "two protocols" but  
> then there's a protocol that handles both seamlessly (and so has  
> simpler code), we're in a bind.
>
> Phil

Phil, I am actually not disagreeing with what you are saying  
regarding the protocol(s) that will result. However if the ROLL needs  
a solution for both unicast and multicast, then this should be stated  
clearly. As it is, it reads simply:

> -       Typical traffic patterns are not simply unicast flows,

Which I think is a bit too obscure a way of stating that the WG will  
be working on both unicast and multicast solutions.

Thomas

---

From: Philip Levis <[email-masked]>
Date: Wed, 18 Feb 2009 10:26:58 -0800

Comments inline.

On Feb 18, 2009, at 10:17 AM, Thomas Heide Clausen wrote:

> regarding the protocol(s) that will result. However if the ROLL  
> needs a solution for both unicast and multicast, then this should be  
> stated clearly. As it is, it reads simply:

Great!

> be working on both unicast and multicast solutions.

I thought the new text says

-       Typical traffic patterns are not simply unicast flows (e.g. in  
some environments most if not all traffic can be point to multipoint)

so it articulates this. How do you think it could be improved?

I think it might be important to separate the notion of "point to  
multipoint" from "multicast." Generally, IP mulitcast is handled by a  
node joining a multicast group. That is, the set of recipients is  
defined by which recipients join the group. In contrast, you'll notice  
that in some application docs the requirements are a bit different: a  
sender wants to deliver a message to a group of nodes, where the group  
is defined by the sender. Its seems very likely that multicast is a  
good way to achieve this, but we're then specifying the solution,  
rather than the requirement.

Does that make sense? It's a very fine line, trying to crisply define  
what the WG needs to accomplish without defining too tightly and  
excluding mechanisms that very useful.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Wed, 18 Feb 2009 19:40:31 +0100

On Feb 18, 2009, at 7:26 PM, Philip Levis wrote:

>>>> hadn't fully realized: to which extend is the output of ROLL  
>>>> going to be an unicast routing protocol? Multicast routing  
>>>> protocol? Multicast transport protocol? Something else? All or  
>>>> some of the above? Neither? In one protocol?
>>>>
>>> examination of the tradeoffs of each approach. But that  
>>> examination is what the re-chartering is for.
>>>
>>> protocols, we're in a bind. If the charter says "two protocols"  
>>> but then there's a protocol that handles both seamlessly (and so  
>>> has simpler code), we're in a bind.
>>>
>>> Phil
>>
>> needs a solution for both unicast and multicast, then this should  
>> be stated clearly. As it is, it reads simply:
>
> Great!
>
>>
>>
>> Which I think is a bit too obscure a way of stating that the WG  
>> will be working on both unicast and multicast solutions.
>
> -       Typical traffic patterns are not simply unicast flows (e.g.  
> in some environments most if not all traffic can be point to  
> multipoint)
>
> multipoint" from "multicast." Generally, IP mulitcast is handled by  
> a node joining a multicast group. That is, the set of recipients is  
> defined by which recipients join the group. In contrast, you'll  
> notice that in some application docs the requirements are a bit  
> different: a sender wants to deliver a message to a group of nodes,  
> where the group is defined by the sender. Its seems very likely that  
> multicast is a good way to achieve this, but we're then specifying  
> the solution, rather than the requirement.
>

You stole my words .. fully agreeing.

> Does that make sense? It's a very fine line, trying to crisply  
> define what the WG needs to accomplish without defining too tightly  
> and excluding mechanisms that very useful.
>
> Phil
>

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Wed, 18 Feb 2009 21:47:07 -0800

This looks good.. 

Another point - Given all the discussions around the 'wording'
we should keep in mind that as the work
progress things will get fine tuned (happens in all working groups). 
So we should move on to the next stage as quickly as we can.

Chandra.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 19 Feb 2009 10:15:28 -0000

> so it articulates this. How do you think it could be improved?

By saying what you plan to do in the Work Items. This text is in
the description of the group, and isn't at all clear that it
specifies what the group will do.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 19 Feb 2009 12:20:45 +0100

Hi:

First I wish to concur with Phil and JP that we need to avoid the confusion between multipoint and multicast. I'll be elaborating a little bit on multicast and IPv6.

Link scope multicast (FF02:...)
-------------------------------

IPv6 relies on link scope multicast capabilities for a number of activities, such as ND. IPv6 does not expect that a Link scope multicast will ever be routed / relayed at layer 3. For instance ND actively checks against a change in the hop limit that is set to 255 for that purpose. Hello protocol uses FF02::5 with the expectation that only direct connectivity shows up. Etc...

Now the type of network we're looking at derives largely from the NBMA model, and NBMA does not provide native link layer multicast capability; moreover, in the P2MP case, FF02 would need routing and relaying to span the whole network, which is incompatible with how link scoped multicast is used in the first place. So for the purpose of IPv6 operation, a number of approaches have been proposed to emulate multicast and enable transparent IPv6 operations.

RFCs 2491/2022/2332: This is the generic model for large NBMA. Mars (RFC 2022) is an example of convergence protocol to emulate multicast transparently to ND and others.

RFC 3122: A new form of ND is introduced that does not need a link spanning multicast service. Can be coupled with the above id DAD is required. Secured and generalized in draft-thubert-3122bis.

6LoWPAN: A subcase of NBMA with a backbone link where FF02:: multicast actually works. An ND extension enables registration over the NBMA edge and proxy operation over the backbone. That same registration enables a service similar to MARS for the purpose of NS/DAD, but in a lot simpler and less generic fashion. For those link scope multicast that could not be avoided, such as some RAs, Trickle optimizes the dissemination of the information in the Low Power network.

It's unclear at this point how far ROLL can reuse that art and how efficient that would be; I certainly would not oppose to having an additional work item to study this specific issue and produce an informational draft. But it's not proven we have a specific problem with link scope multicast that prevents ROLL operation either.

L3 (routed) multicast, that is FF0x:... (x>2) 
---------------------------------------------

Multicast appears in the requirements document as the way to distribute to many small groups of nodes; seems ROLL could survive short term with multiple P2P even though it'd be inefficient in a deep ROLL network.

For all I've seen, that's mostly information and commands being pushed from the infrastructure into the ROLL network. The way I see it, we do not necessarily need a full fledged support of multicast, but rather a way to distribute data coming from the outside along trees that span the ROLL network from the network sinks. If the routing that we define provides such trees, then the logical structure can be economically reused for multicast distribution. MANEMO did just that, though I think we never published the draft that detailed the mcast NINA that carried MLD proxy registrations up the TD tree.

My take is that we'll need to be creative when we define the unicast routing to try and fulfill the multicast requirements we have for as little additional cost as we can... But I would keep the charter as it stands for that matter.

Pascal

>From: [email-masked] [mailto:[email-masked]] On Behalf Of JP Vasseur (jvasseur)
>Sent: mercredi 18 février 2009 19:41
>To: Philip Levis
>Cc: ROLL WG; Thomas Heide Clausen

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Feb 2009 12:49:03 +0100

Philip Levis a écrit :
>>> the tradeoffs of each approach. But that examination is what the 
>>> re-chartering is for.
>>>
>> Phil, I am actually not disagreeing with what you are saying regarding 
>> the protocol(s) that will result. However if the ROLL needs a solution 
>> for both unicast and multicast, then this should be stated clearly. As 
>> it is, it reads simply:
> 
> Great!
> 
>>
>>
> multipoint" from "multicast."

YEs, multicast makes me think of IP and/or link-layer multicast.

Point-to-multipoint makes me think of TE and MPLS.

I agree this could be better disambiguated.

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 19 Feb 2009 17:47:32 +0100

Pascal,

I agree with much of what you say, but notably except the last  
sentence of:

> My take is that we'll need to be creative when we define the  
> unicast routing to try and fulfill the multicast requirements we  
> have for as little additional cost as we can... But I would keep  
> the charter as it stands for that matter.

I think that if the "multicast"/"multipoint" requirement is to appear  
as an important design space constraint for ROLL protocols, then this  
should be made evident in the charter.

I also think that disambiguifying multicast/multipoint would be of  
value.

Thomas

On Feb 19, 2009, at 12:20 PM, Pascal Thubert (pthubert) wrote:

> Hi:
>
> First I wish to concur with Phil and JP that we need to avoid the  
> confusion between multipoint and multicast. I'll be elaborating a  
> little bit on multicast and IPv6.
>
> IPv6 relies on link scope multicast capabilities for a number of  
> activities, such as ND. IPv6 does not expect that a Link scope  
> multicast will ever be routed / relayed at layer 3. For instance ND  
> actively checks against a change in the hop limit that is set to  
> 255 for that purpose. Hello protocol uses FF02::5 with the  
> expectation that only direct connectivity shows up. Etc...
>
> Now the type of network we're looking at derives largely from the  
> NBMA model, and NBMA does not provide native link layer multicast  
> capability; moreover, in the P2MP case, FF02 would need routing and  
> relaying to span the whole network, which is incompatible with how  
> link scoped multicast is used in the first place. So for the  
> purpose of IPv6 operation, a number of approaches have been  
> proposed to emulate multicast and enable transparent IPv6 operations.
>
> RFCs 2491/2022/2332: This is the generic model for large NBMA. Mars  
> (RFC 2022) is an example of convergence protocol to emulate  
> multicast transparently to ND and others.
>
> RFC 3122: A new form of ND is introduced that does not need a link  
> spanning multicast service. Can be coupled with the above id DAD is  
> required. Secured and generalized in draft-thubert-3122bis.
>
> 6LoWPAN: A subcase of NBMA with a backbone link where FF02::  
> multicast actually works. An ND extension enables registration over  
> the NBMA edge and proxy operation over the backbone. That same  
> registration enables a service similar to MARS for the purpose of  
> NS/DAD, but in a lot simpler and less generic fashion. For those  
> link scope multicast that could not be avoided, such as some RAs,  
> Trickle optimizes the dissemination of the information in the Low  
> Power network.
>
> It's unclear at this point how far ROLL can reuse that art and how  
> efficient that would be; I certainly would not oppose to having an  
> additional work item to study this specific issue and produce an  
> informational draft. But it's not proven we have a specific problem  
> with link scope multicast that prevents ROLL operation either.
>
> Multicast appears in the requirements document as the way to  
> distribute to many small groups of nodes; seems ROLL could survive  
> short term with multiple P2P even though it'd be inefficient in a  
> deep ROLL network.
>
> For all I've seen, that's mostly information and commands being  
> pushed from the infrastructure into the ROLL network. The way I see  
> it, we do not necessarily need a full fledged support of multicast,  
> but rather a way to distribute data coming from the outside along  
> trees that span the ROLL network from the network sinks. If the  
> routing that we define provides such trees, then the logical  
> structure can be economically reused for multicast distribution.  
> MANEMO did just that, though I think we never published the draft  
> that detailed the mcast NINA that carried MLD proxy registrations  
> up the TD tree.
>
> My take is that we'll need to be creative when we define the  
> unicast routing to try and fulfill the multicast requirements we  
> have for as little additional cost as we can... But I would keep  
> the charter as it stands for that matter.
>
> Pascal
>