Subject: [Roll] New proposed charter for ROLL (to be approved by the IESG)

From: JP Vasseur <[email-masked]>
Date: Wed, 11 Mar 2009 20:28:30 +0100

Dear all,

First of all, I would like to thank you all for all the feed-backs.

We have overall an excellent consensus.

Some of you have expressed some concerns, thus we did make a few  
changes:
- Start with one protocol:

- Protocol work: The Working Group will consider specific routing  
requirements
from the four application documents collectively, and specify either a  
new protocol
or extend an existing routing protocol in cooperation with the  
relevant Working Group.
If requirements from the four target application areas cannot be met  
with a single
protocol, the WG may choose to specify or extend more than one  
protocol (this will
require a recharter of the WG).

- Clarifying the support of unicast and multicast

Please find the new proposed charter below, to be approved by the IESG.

Routing Over Low power and Lossy networks (roll)
==================================================
Last Modified: 2009-02-04

Current Status: Active Working Group

Additional information is available at tools.ietf.org/wg/roll

Chair(s):

JP Vasseur <[email-masked]>
David Culler <[email-masked]>

Routing Area Director(s):

Ross Callon <[email-masked]>
David Ward <[email-masked]>

Routing Area Advisor:
David Ward <[email-masked]>

Mailing Lists:

General Discussion: [email-masked]
To Subscribe: http://www.ietf.org/mailman/listinfo/roll
Archive: http://www.ietf.org/mail-archive/web/roll/

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 saving energy.
- Typical traffic patterns are not simply unicast flows (e.g. in some
cases
  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.

Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been
evaluated by the working group and have in their current form been  
found to
not satisfy all of 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), asset 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.
The solution must include unicast and multicast considerations.

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 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: The Working Group will consider specific routing  
requirements
from the four application documents collectively, and specify either a  
new protocol
or extend an existing routing protocol in cooperation with the  
relevant Working Group.
If requirements from the four target application areas cannot be met  
with a single
protocol, the WG may choose to specify or extend more than one  
protocol (this will
require a recharter of the WG).

- 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.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Mar 2009 22:01:20 +0100

JP Vasseur a écrit :
[...]
>  cases most if not all traffic can be point to multipoint).

I don't understand this logic because pt-to-mpt can be unicast:  several
simple unicast requests could be sent sequentially from pt to several
points.  If worried of packet duplication then use IP multicast.

I'd be more tempted to agree with something along these lines: "typical 
comm patterns (querying several sensors at once) need IP multicast 
delivery of the query; IP multicast delivery on links without link-layer 
multicast support risks being inefficient - neighbors hear packets not 
for them; for such links use IP point-to-_point_ links instead; this 
addressing architecture should be accommodated by all ROLL protocols". 
It hints to a tangible problem and solution.

                IP point-to-point link
              /------------------------(sensor)
   --------- /
  | Querier |--------------------------(sensor)
   --------- \
              \------------------------(sensor)

That's why I'm not sure what kind of work should be done about it.

Alex

---

From: JP Vasseur <[email-masked]>
Date: Wed, 11 Mar 2009 22:48:12 +0100

> points.  If worried of packet duplication then use IP multicast.

We all agree with you. This parts relates to LLN typical  
characteristics.

Thanks.

JP.

>
>
> I'd be more tempted to agree with something along these lines:  
> "typical comm patterns (querying several sensors at once) need IP  
> multicast delivery of the query; IP multicast delivery on links  
> without link-layer multicast support risks being inefficient -  
> neighbors hear packets not for them; for such links use IP point-to- 
> _point_ links instead; this addressing architecture should be  
> accommodated by all ROLL protocols". It hints to a tangible problem  
> and solution.
>
>               IP point-to-point link
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "David E. Culler" <[email-masked]>
Date: Wed, 11 Mar 2009 14:54:22 -0700

The roll of the charter is to define the problem areas that fall under 
the purview of a working group and to identify the items of work and the 
timeline that will be pursued in addressing those problems.  A detailed 
discussion of the means, alternatives, and performance tradeoffs in the 
implementation of particular features does not belong in such a document.

If you are interested in implementation of multicast on ieee 802.15.4 
links there is ample material available in the literature on that 
subject.  If you are interested in the compaction of multicast 
addresses, that is dealt in 6LoWPAN.

Alexandru Petrescu wrote:
> neighbors hear packets not for them; for such links use IP 
> point-to-_point_ links instead; this addressing architecture should be

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Mar 2009 23:05:27 +0100

JP Vasseur a écrit :
> We all agree with you. This parts relates to LLN typical characteristics.

LLN like 802.15.4 and family being pt-to-mpt means I don't understand 
how to put IP on it.  When I doubt I use IP ptp links - it works, worked 
in the past.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Mar 2009 23:52:39 +0100

Generic charter, accommodating as much work as possible, generating
impetus - ok.

I'd simply like it clear.  Reading point-to-multipoint isn't
clear to MHO:

-contrasting pt-to-mpt to 'unicast' is first sign of unclearness.
-saying 'traffic patterns' leads think you mean application layer,
  actually.

[...]
>  cases most if not all traffic can be point to multipoint).

If "traffic" is pt-to-mpt does that mean application-layer traffic?  We
wouldn't design an application-layer protocol, and couldn't care less of
it being pt-to-mpt or many-to-many.

So one is tempted to better say "IP pt-to-mpt" which is 'IP multicast', 
really.

'not simply unicast flows' - so immediately think it's 'multicast', or 
'anycast'.  But not pt-to-mpt.

I believe 'unicast' to be when both src and dst are unicast addresses. 
You may think otherwise...

David E. Culler a écrit :
> The roll of the charter is to define the problem areas that fall 
> under the purview of a working group and to identify the items of 
> work and the timeline that will be pursued in addressing those 
> problems.  A detailed discussion of the means, alternatives, and 
> performance tradeoffs in the implementation of particular features 
> does not belong in such a document.
> 
> subject.

Where do you think I should look better than an RFC?  One surely
wouldn't appreciate a ROLL protocol RFC about which later people will
say go better read the literature...

(Currently the IPV6-over-802154 RFC says "multicast is not supported
  natively in IEEE 802.15.4.")

> If you are interested in the compaction of multicast addresses, that
>  is dealt in 6LoWPAN.

Same length as unicast - why should I be interested in compacting IP
multicast addresses in particualr...

Alex

>> JP Vasseur a écrit : [...]
>>> - Typical traffic patterns are not simply unicast flows (e.g. in
>>>  some cases most if not all traffic can be point to multipoint).
>> 
>> I don't understand this logic because pt-to-mpt can be unicast: 
>> several simple unicast requests could be sent sequentially from pt
>>  to several points.  If worried of packet duplication then use IP 
>> multicast.
>> 
>> point-to-_point_ links instead; this addressing architecture should
>>  be accommodated by all ROLL protocols". It hints to a tangible 
>> problem and solution.
>> 
>> IP point-to-point link /------------------------(sensor) ---------
>>  / | Querier |--------------------------(sensor) --------- \ 
>> Alex _______________________________________________ Roll mailing 
>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 12 Mar 2009 09:33:46 +0100

Dear JP:

This clarification is exactly what I was asking for. Thanks for the
extra effort. I'm all for it now.

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jp Vasseur (jvasseur)
Sent: mercredi 11 mars 2009 20:29
To: ROLL WG
Subject: [Roll] New proposed charter for ROLL (to be approved by the
IESG)

Dear all,

or extend an existing routing protocol in cooperation with the relevant
Working Group. 

protocol, the WG may choose to specify or extend more than one protocol
(this will 

Chair(s):

Routing Area Advisor:

Mailing Lists:

evaluated by the working group and have in their current form been found
to 

Work Items:

- Provide an architectural framework for routing and path selection at 
 Layer 3 (Routing for LLN Architecture) that addresses such issues as 
 whether LLN routing require a distributed and/or centralized path
computation models, whether additional hierarchy is necessary and how it
is applied.

or extend an existing routing protocol in cooperation with the relevant
Working Group. 

protocol, the WG may choose to specify or extend more than one protocol
(this will 

Goals and Milestones:

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 12 Mar 2009 14:09:38 +0100

All,

This updated charter moves resolving one of my issues (the "multi- 
point" issue) into the rechartered working group as explicit parts of  
the work items. The updated charter likewise scopes down the protocol  
work with regards to considering the various routing requirements  
*collectively* and aim for *one* protocol (or, in case that's not  
possible, for rechartering).

Provided that we in the rechartered working group actually approach  
the work according to, and in the spirit of, the charter, this seems  
acceptable.

I'd like to express my thanks to the wg chairs and the various ADs  
who've been involved in the process of producing and revising this  
updated charter.

Thomas

On Mar 12, 2009, at 09:33 AM, Pascal Thubert (pthubert) wrote:

> extra effort. I’m all for it now.
>
>
>
> Pascal
>
> From: [email-masked] [mailto:[email-masked]] On  
> Behalf Of Jp Vasseur (jvasseur)
> Subject: [Roll] New proposed charter for ROLL (to be approved by  
> the IESG)
>
>
>
> Dear all,
>
>
>
> from the four application documents collectively, and specify  
> either a new protocol
>
> If requirements from the four target application areas cannot be  
> met with a single
>
> manageability (e.g., self routing configuration) issues. It will  
> also need
> to consider the transport characteristic the routing protocol  
> messages will
> computation models, whether additional hierarchy is necessary and  
> how it is applied.
>
> from the four application documents collectively, and specify  
> either a new protocol
>
> If requirements from the four target application areas cannot be  
> met with a single
>
> Done Submit Routing requirements for Building applications to the  
> IESG to

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 12 Mar 2009 13:32:22 -0000

>  Start with one protocol: 
 
Not something I've commented on, but sounds like a good idea. 

> Clarifying the support of unicast and multicast
 
Looks good to me.

********************************************************************
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: Emmanuel Baccelli <[email-masked]>
Date: Thu, 12 Mar 2009 16:38:13 +0100

Hi JP and all,
I believe we are stirring in the right direction. I had mainly two comments
about the previous version:

a) The blur around "multi-point".

It is now clearer that it is a must, and that it is separate from unicast. I
can live with the fact that the exact nature of the traffic patterns aimed
at will be defined for starters. I encourage as much as possible the WG to
define this in a separate document.

I still wonder, though,  whether or not there should be a separate work item
for unicast on one hand and for multicast on the otehr hand (usually these
are quite different protocols). I suppose that it is nevertheless not
impossible to count the two different components as a single solution/work
item.

b) The blur around "the set(s) of requirements".

It is now clearer that either (i) a unique set of requirements will be
factored out as soon as possible, or (ii) if this proves impossible,
rechartering will conclude the debates.

As everyone, I wish for (i). In the probable case where the set of
requirements differs from the union of all the requirements listed by the 4
existing requirement drafts, I ecourage the WG to also document this in a
separate doc.

So, in a nutshell, assuming I understood things correctly ;) this is an OK
plan as far as I am concerned. I also wanted to thank JP, David and the
concerned ADs for the hard work they had to put in latetly in this regard.

Cheers,
Emmanuel