Subject: [Roll] When source routing fails...

From: Jonathan Hui <[email-masked]>
Date: Fri, 19 Mar 2010 11:15:25 -0700

ROLL WG,

RPL-07 currently supports routers that do not maintain downward  
routing state.  To route through these 'non-storing' nodes, it is  
expected that an ancestor node will maintain state about the downward  
routing topology and utilize source routing.

When routing information no longer correctly reflects changes in link  
connectivity, a storing node may attempt to utilize a path that can no  
longer reach the intended destination.  With source routing, the  
delivery failure may occur several hops away, or more generally  
anywhere between the storing node and the destination.  RPL-07  
currently does not make any attempt to specify what actions a non- 
storing node should take when using source route information fails.

A few obvious actions are:

1) Drop the packet and nothing else.  This is the most simple option  
and has the benefit that routing failures do not generate any extra  
traffic.  Route repair timescales are dependent on control traffic  
rather than data traffic.

2) Drop the packet and send back an ICMPv6 error or RPL message  
indicating where the route failed.  Allows quick notification to a  
storing node that route information is invalid.  Route repair  
timescales are dependent on data traffic rather than control traffic.   
While this generates extra control traffic on link failures, the error/ 
repair messages can be small and constant size.  Rate limiting can be  
used to bound error/repair message generation.

3) Backtrack by returning the packet towards the root and indicating  
where the route failed.  Implements a form of depth-first search and  
gives the data packet another chance to reach its destination.  Allows  
quick notification to a storing node that route information is  
invalid.  Route repair on timescales are dependent on data traffic  
rather than control traffic.  While this does not generate any extra  
control traffic per-se, data packets that experience source route  
failures can remain "live" within the network for extended periods of  
time. If these data packets or failures occur repeatedly, channel  
utilization can increase unexpectedly while data packets traverse up  
and down the DAG.

On a separate dimension, it is important to note that the above  
options are not mutually exclusive and we have the following options:

1) Specify only a single action when source route failures occur.

2) Provide an option that can select which action to take on a per- 
instance, per-dag, or per-packet basis.  The per-packet option may be  
specified as part of the source route information or based on the  
payload (e.g. simply drop ICMPv6 errors but backtrack UDP datagrams).

What are other people's thoughts?  Are there additional pros/cons of  
the options above?  Are there other options that we should consider?

--
Jonathan Hui

---

From: Michael Richardson <[email-masked]>
Date: Fri, 19 Mar 2010 15:14:20 -0400

>>>>> "Jonathan" == Jonathan Hui <[email-masked]> writes:
    Jonathan> ROLL WG,

    Jonathan> RPL-07 currently supports routers that do not maintain
    Jonathan> downward routing state.  To route through these
    Jonathan> 'non-storing' nodes, it is expected that an ancestor node
    Jonathan> will maintain state about the downward routing topology
    Jonathan> and utilize source routing.

...

    Jonathan> A few obvious actions are:

    Jonathan> 1) Drop the packet and nothing else.  This is the most
    Jonathan> simple option and has the benefit that routing failures do
    Jonathan> not generate any extra traffic.  Route repair timescales
    Jonathan> are dependent on control traffic rather than data traffic.

    Jonathan> 2) Drop the packet and send back an ICMPv6 error or RPL
    Jonathan> message indicating where the route failed.  Allows quick
    Jonathan> notification to a storing node that route information is
    Jonathan> invalid.  Route repair timescales are dependent on data
    Jonathan> traffic rather than control traffic.  While this generates
    Jonathan> extra control traffic on link failures, the error/ repair
    Jonathan> messages can be small and constant size.  Rate limiting
    Jonathan> can be used to bound error/repair message generation.

I'd like to make this a bit more fine-grained.

1a) drop the packet, do nothing else. (non-ordinary router behaviour)
1b) drop the packet, send ICMPv6 error message (normal router behaviour)

2) drop the packet, send RPL message (extra-ordinary RPL router mode)

3) backtrack mechanism, that I think is interesting, but I choose not
   to discuss right now.

As you note:

My vote is to send an RPL message --- such as a DAO -- which one would
send anyway (advance the timer, but rate limit it).  Send extra info in
it.

    Jonathan> On a separate dimension, it is important to note that the
    Jonathan> above options are not mutually exclusive and we have the
    Jonathan> following options:

    Jonathan> 1) Specify only a single action when source route failures
    Jonathan> occur.

    Jonathan> 2) Provide an option that can select which action to take
    Jonathan> on a per- instance, per-dag, or per-packet basis.  The
    Jonathan> per-packet option may be specified as part of the source
    Jonathan> route information or based on the payload (e.g. simply
    Jonathan> drop ICMPv6 errors but backtrack UDP datagrams).

Some of this is really a local decision.
Some of it is not.

    Jonathan> What are other people's thoughts?  Are there additional
    Jonathan> pros/cons of the options above?  Are there other options
    Jonathan> that we should consider?

I dislike magic local knobs.
I also dislike extra options in the processing.
I especially dislike options in the packet forwarding path.

SO:
  Not per-packet.
  Not per-dag.
  MAY per-instance.

-- 
]       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: "Don Sturek" <[email-masked]>
Date: Fri, 19 Mar 2010 17:23:53 -0700

Hi Jonathan,

For unreachable destinations, action 2 is best (Drop the packet and send
back an ICMPv6 error or RPL message indicating where the route failed).  I
would prefer selection of a single action since this reduces options and
complexity.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Hui
Sent: Friday, March 19, 2010 11:15 AM
To: ROLL WG
Subject: [Roll] When source routing fails...

ROLL WG,

--
Jonathan Hui

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 21 Mar 2010 18:50:46 +0100

Hi Jonathan:

I'm with Don on this.

Robert has recently expressed the concern that we'll need to inform the
root on some events and this is probably such an event.

With the current spec the cache with the obsolete source route info is
not necessarily the root. So we end up with the requirement to be able
to send an exception back up the DAG, either to an ancestor or the root
itself.

If what we are doing with this event is really RPL specific, then maybe
it's better to have our own message as opposed to consumed ICMP space.

What do you think?

Pascal

> Don Sturek
> Sent: Friday, March 19, 2010 5:24 PM
> To: 'Jonathan Hui'; 'ROLL WG'
> Subject: Re: [Roll] When source routing fails...
> 
> Hi Jonathan,
> 
> For unreachable destinations, action 2 is best (Drop the packet and
send back
> an ICMPv6 error or RPL message indicating where the route failed).  I
would
> prefer selection of a single action since this reduces options and
complexity.
> RPL-07 currently supports routers that do not maintain downward
routing
> state.  To route through these 'non-storing' nodes, it is expected
that an
> ancestor node will maintain state about the downward routing topology
and
> utilize source routing.
longer
> reach the intended destination.  With source routing, the delivery
failure may
> occur several hops away, or more generally anywhere between the
storing
> node and the destination.  RPL-07 currently does not make any attempt
to
> specify what actions a non- storing node should take when using source
> route information fails.
> 
and has
> the benefit that routing failures do not generate any extra traffic.
Route
> repair timescales are dependent on control traffic rather than data
traffic.
> 2) Drop the packet and send back an ICMPv6 error or RPL message
indicating
> where the route failed.  Allows quick notification to a storing node
that route
> information is invalid.  Route repair
> While this generates extra control traffic on link failures, the
error/ repair
> messages can be small and constant size.  Rate limiting can be used to
bound
> error/repair message generation.
> 
where
> the route failed.  Implements a form of depth-first search and gives
the data
> packet another chance to reach its destination.  Allows quick
notification to a
> storing node that route information is invalid.  Route repair on
timescales are
> dependent on data traffic rather than control traffic.  While this
does not
> generate any extra control traffic per-se, data packets that
experience
> source route failures can remain "live" within the network for
extended
> periods of time. If these data packets or failures occur repeatedly,
channel
> utilization can increase unexpectedly while data packets traverse up
and
> down the DAG.
options are
> not mutually exclusive and we have the following options:
> 
instance,
> per-dag, or per-packet basis.  The per-packet option may be specified
as part
> of the source route information or based on the payload (e.g. simply
drop
> ICMPv6 errors but backtrack UDP datagrams).
> 
the
> options above?  Are there other options that we should consider?
> 
> --
> Jonathan Hui
>