[RSN] Re: WG Review: Routing Over Low power and Lossy networks (roll)

[JP Vasseur <[e-mail]>]

Hi Ian,


> From: Ian Chakeres <[e-mail]>
> Date: Mon, 21 Jan 2008 15:35:11 +0530
> To: <[e-mail]>
> Cc: Ross Callon <[e-mail]>, David Ward <[e-mail]>, JP
> Vasseur <[e-mail]>, <[e-mail]>
> Subject: Re: WG Review: Routing Over Low power and Lossy networks (roll)
> 
> I support the formation of the WG, but I have several comments about
> the charter and milestones.

Thanks for the support, see in line,

> 
> I've placed the comments inline, and my final comment is explicitly
> identified by "=LAST COMMENT=".
> 
> Ian Chakeres
> 
> On Jan 16, 2008 2:45 AM, IESG Secretary <[e-mail]> wrote:
>> A new IETF working group has been proposed in the Routing Area.
>> The IESG has not made any determination as yet. The following draft
>> charter was submitted, and is provided for informational purposes only.
>> Please send your comments to the IESG mailing list ([e-mail]) by
>> January 22nd.
>> 
>> +++
>> 
>> Routing Over Low power and Lossy networks (roll)
>> ==================================================
>> 
>> Current Status: Proposed Working Group
>> 
>> Chairs:
>> TBD
>> 
>> Routing Area Director(s):
>> Ross Callon <[e-mail]>
>> David Ward <[e-mail]>
>> 
>> 
>> Description of Working Group
>> 
>> Low power and Lossy networks (LLNs) are typically composed of many
>> embedded devices with limited power, memory, and processing resources
>> interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth,
>> Low Power WiFi. 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. In addition, LLNs have specific
>> routing requirements that may not be met by existing routing protocols,
>> such as OSPF, IS-IS, AODV and OLSR. For example path selection must be
>> designed to take into consideration the specific power capabilities,
>> attributes and functional characteristics of the links and nodes in the
>> network.
>> 
>> There is a wide scope of application areas for LLNs, including industrial
>> monitoring, building automation (HVAC, lighting, access control, fire),
>> connected home, healthcare, environmental monitoring, urban sensor
>> networks
>> sensor networks, assets tracking, refrigeration. The Working Group will
>> only focus on routing solutions for a subset of these. It will focus on
>> industrial, connected home/building and urban sensor networks and it will
>> determine the routing requirements for these scenarios.
>> 
>> The Working Group will provide an IPv6 only routing architectural
>> framework
>> for these application scenarios. Given the transition of this technology
>> at
>> this time it is believed that an IPv4 solution is not necessary. 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.
> 
> Are these devices - nodes or routers? I suspect they are intended to
> be routing sensor nodes, so this should probably say routers.

These nodes are usually both "hosts" (e.g. sensor,actuators) (which may have
to be taken into account by the constrained routing function) and routers,
thus the use of the generic term "node".

> 
> I think it would be best to leave the size of the network out of the
> charter. The WG documents could elaborate on the size of the network
> as well as whether it is organized into a flat or hierarchical routing
> structure. That said, scalability may be one of the factors that
> influences the routing protocol design.
> 

Yes and this is why it should explicitly be spelled out in the charter, this
is one of the key aspects/characteristics of these networks.

> One other architectural issue that has been brought up in discussion
> on-list is whether "sleeping" routers will be explicitly considered.
> From the charter text, I do not get the impression that routers will
> only sometimes be available. If sleeping routers are part of the core
> architecture, I think they should be mentioned in the charter text.

They are not. We're not working on DTNs.

> 
>> The Working Group will explore aspects of mobility within a single LLN
>> (if any)
>> in the routing requirement creation.
> 
> LLN is a class of networks, not a particular instance or boundary. I
> would recommend using a term like routing area or routing region -
> where all routing devices collaborate using the same protocol.


This may create confusion though ... Single LLN means "Not across The
Internet".

> 
>> The Working Group will pay particular attention to routing security and
>> manageability (e.g., self 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 applications utilizing LLNs define
>> appropriate mechanisms.
>> 
>> Work Items:
>> 
>> - Produce routing requirements documents for Industrial, Connected
>> Home, Building and urban sensor networks. Each document will describe the
>> use
>> case and the associated routing protocol requirements. The documents will
>> progress in collaboration with the 6lowpan Working Group (INT area).
>> 
>> - Survey the applicability of existing protocols to LLNs. The aim of this
>> document will be to analyze the scaling and characteristics of existing
>> protocols and identify whether or not they meet the routing requirements
>> of the applications identified above. Existing IGPs, MANET, NEMO, DTN
>> routing protocols will be part of evaluation.
>> 
>> - 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.
>> 
>> Goals And Milestones:
>> 
>> July 2008 Submit Routing requirements for Industrial applications to the
>> IESG to be considered as an Informational RFC.
>> 
>> July 2008 Submit Routing requirements for Connected Home networks
>> applications
>> to the IESG to be considered as an Informational RFC.
>> 
>> July 2008 Submit Routing requirements for Building applications to the
>> IESG to be considered as an Informational RFC.
>> 
>> July 2008 Submit Routing requirements for Urban networks applications
>> to the IESG to be considered as an Informational RFC.
> 
> I personally do not think these documents should become Informational RFCs.
> 
> I would rather see a single "ROLL problem statement document" emerge.
> The problem statement should elaborate on the device and network
> constraints, and typical operating conditions.

There was a large consensus to adopt an application driven routing
requirements approach, which has proven to be successful in several other
WGs and is particularly useful in this context. Each representative scenario
(or class of scenario) has its own set of requirements of different nature.
We may have to have different solutions (to be determined by the WG if
formed) for different set of applications thus the need for separate
documents, as agreed by the community on the RSN Mailing List.
>

> 
>> November 2008: Submit Routing metrics for LLNs document to the IESG to be
>> considered as a Proposed Standard.
> 
> I think this document could be an informational RFC, but not proposed
> standard. When the proposed node/link/path metrics are applied to a
> specific PS routing protocol, then maybe that document could be
> considered for proposed standard.
> 
>> February 2009: Submit Protocol Survey to the IESG to be considered as
>> an Informational RFC.
> 
> I am very concerned about this document. The areas that this document
> proposes to cover are huge. There have been 1000s of papers published
> on these topics; and there are also so many variants of the popular
> protocols that these cannot be covered adequately.
> 

This is why we adopted an application-driven approach here.

> Instead of the existing document content proposal, I would instead
> propose that this document make recommendations on the approach(es)
> this WG group believes are most appropriate for LLN. For example, link
> state vs distance vector.

The aim of the protocol survey as explained above in the charter is not to
make an exhaustive/generic routing protocol survey but to survey the
existing protocol(s) and determine whether one/several existing protocols
satisfy the requirements spelled in the application specific requirement
documents. If so, we're done. If not, the WG would have to work with
existing WG(s) to enhance their routing protocol or the WG will recharter.
Note that we'll pay a particular attention to have a short/concise and
conclusive document here.

Thanks.

JP.

> 
> =LAST COMMENT=
> 
> 
> 
> 
> 
>> 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.
>> 
>> June 2009: Recharter.
>> 
>> _______________________________________________
>> IETF-Announce mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/ietf-announce
>> 



_______________________________________________
RSN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rsn