Re: [Roll] proposed amendments to ROLL charter

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Randy

Sure, Randy, but stale routes will send packets to black holes till they elapse, cutting some communication. This is not a big issue is most WSNs so we have not addressed it in the main spec.
One case I have in mind is multiple DODAGs. The root learns from some routing protocol over the backbone that a node moved to another DODAG.
But the root and all nodes down the path where that node used to be still have an DAO entry, for potentially a long time.
The root can discard its own state but it cannot cleanup down the dodag, leading to a local blackholing for packets issued in that affected zone.

Cheers,

Pascal

From: Roll [mailto:[e-mail]] On Behalf Of Turner, Randy
Sent: jeudi 2 avril 2015 18:17
To: Routing Over Low power and Lossy networks
Cc: Michael Richardson
Subject: Re: [Roll] proposed amendments to ROLL charter

Hi Pascal

Routing table entries usually have lifetimes. Wouldn't that clean up dead routes at the root?

Randy

On Apr 2, 2015, at 12:00 PM, Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>> wrote:
A few other things I'd like to see, Ines:

- One is a MOP based on BIER and/or Bloom filters, which is a way to compress BIER with a chance of false positive. Carsten has a draft that details the use of Bloom filters for source routing, but really both BIER and Bloom can apply to either storing and non-storing.
- Work on mixed storing and non-storing, and all sort of optimization for the storing mode. I'm aware of feasible solutions in that space that really should be shared and made available to all.
- Work on additional capabilities that we did not initially include in the spec:
- The capability to kill a route from the root, e.g. if a DAO state is installed and should be cleaned up, e.g. if the root realizes that the node is no more there or there is a duplication or what-else.
- The capability to trigger a DAO from the root if a target is expected to be present in the network but there is no DAO state (maybe to save resources)
- The capability to request the triggering of a new iteration of a DODAG from a RPL node or a controlling element.

Thanks for asking :)

Pascal

From: Roll [mailto:[e-mail]] On Behalf Of Ines Robles
Sent: mardi 31 mars 2015 16:10
To: Routing Over Low power and Lossy networks
Cc: Michael Richardson
Subject: Re: [Roll] proposed amendments to ROLL charter

Hi Pascal,

Thank you very much for your comments, we are going to include them in our meeting.

To all, There are additional topics that you would like to include in the charter? Please justify.

Thank you very much,

Michael and Ines

2015-03-31 13:49 GMT+03:00 Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>:
Hello Michael (and all):

I fully support the additions. Since you are at it, I would like to explore a deeper realignment.

ROLL is now in charge of the maintenance of RPL, isn't it?
- I think that this should be a work item in the charter.
- this should replace elements that were or are being delivered such as metrics, security, and RPL itself

And if that's so, wouldn't it make sense to study how RPL works outside LLNs and in mixed environments?
- I'd like to see work on RPL over foo where foo is Ethernet or Wi-Fi. Applicability of RPL in various environments outside LLN would be of interest, e.g. to build a Wi-Fi mesh or an unmanaged network. It seems that a DT will form at HOMENET to select a routing protocol, and an applicability statement of RPL for that case would be a good read if we can produce it in time.
- From our experience of actually doing RPL over Ethernet, it is mostly a matter of *not* using the packet artifacts, probably not using the stretch in local repair, and reacting immediately to changes in link state. This is a very small spec indeed, mostly guidance on what to use and what not to use from RFC 6550, how to tune some parameters, which OF to use and how.
- The work should also detail the mode where there is a backbone and a virtual root. I think that the current charter does not cover work outside LLN but considering that we are the group that knows RPL best, that work should happen here.

What do you think?

Pascal


> -----Original Message-----
> From: Roll [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Michael Richardson
> Sent: lundi 23 mars 2015 19:41
> To: [e-mail]<mailto:[e-mail]>
> Subject: [Roll] proposed amendments to ROLL charter
>
>
> The following changes are proposed for the ROLL charter to include the work to
> profile 6553/6554/IPIP, and to compress it.
>
> To the pre-amble:
>
> After:
>  - 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.
>
> Add:
> +- LLN routing protocols have to be very careful when trading off
> +efficiency
> +  for generality; many LLN nodes do not have resources to waste.
>
> After:
>  The solution must include unicast and multicast considerations.
>
> Add:
> +The Working Group will document how non-control packets are routed when
> +they cross the LLN, and when they enter and exit the LLN: the
> +appropriate use of
> +RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how
> +routing loops are detected. In consultation with the 6lo WG, the
> +Working Group will design a method to these routing headers into a
> +single block.  The result will have a shared WGLC with 6lo.
>
> To  Work Items, add:
> +     - A document detailing when to use RFC6553, RFC6554 and IPIP
> +       encapsulation.
> +
> +     - A document detailing how to compress RFC6553, RFC6554 and IP headers
> +       in the 6lowPAN HC context.
>
>
> The resulting charter (after reformatting of some of the ugly text wrapping on
> the web site) is:
>
> ----
> 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.
>
> The Working Group will document how non-control packets are routed when
> they cross the LLN, and when they enter and exit the LLN: the appropriate use of
> RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing
> loops are detected. In consultation with the 6lo WG, the Working Group will
> design a method to these routing headers into a single block.  The result will
> have a shared WGLC with 6lo.
>
> 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.
>
>      - A document detailing when to use RFC6553, RFC6554 and IPIP
>        encapsulation.
>
>      - A document detailing how to compress RFC6553, RFC6554 and IP headers
>        in the 6lowPAN HC context.
>
>
>
> $Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $
>
>
>
> --
> Michael Richardson <[e-mail]<mailto:[e-mail]>>, Sandelman Software Works
> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll


P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.