Re: [Roll] Roll Digest, Vol 25, Issue 46 (follow up on point to point routing into a DAG where the destination is at lower rank)

Hi Tim and Don:

I'm so sorry I failed to answer earlier.

Don: Tim is correct throughout. If your use case permits to store DAO
states and the associated routes, you should never see a routing header
with RPL as it stands. We need to improve our language on source route.
In short, support would be mandatory but usage a case by case deployment
decision, with probably some heuristics in the implementations to decide
when to use  it, for which destinations, etc. 

Tim: About you first point on RH in the infrastructure. You're correct
with the current model where the RPL routes are redistributed (hopefully
in an aggregated fashion) by the roots; but when we couple RPL with
mobility that might not be so anymore, in particular if mobile addresses
are injected in RPL, or if the RPL mesh is built off ULAs. That day, I
expect a routing header in the infra to get from afar to the root using
infrastructure routing and then from the root to device, using RPL
routing. You'll find information on how that could work in
http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header. 

Cheers,

Pascal

-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Tim Winter
Sent: Monday, March 01, 2010 1:30 AM
To: d.sturek@att.net
Cc: ROLL WG
Subject: Re: [Roll] Roll Digest, Vol 25, Issue 46 (follow up on point to
point routing into a DAG where the destination is at lower rank)

Hi Don,

Don Sturek wrote:
> Hi Pascal,
> 
> One additional question:  If I am routing from outside the DAG to a
device
> in the DAG at a rank that is not the DAG root, is source routing
required?
> I had thought with the right selection of RA/RS and storage within the
> devices in the DAG it was possible to support this scenario without
source
> routing.  Could you or someone in the DT answer this?
> 
> The issue is if source routing is required, we need to carefully
review the
> header sizes to see if this will actually work for our application.
> 
> Thanks,
> 
> Don

Generally the idea is that traffic originating from outside the RPL
domain and headed
for a LLN destination inside the RPL domain would never need source
routing on the
outside of the RPL domain.  When the traffic crosses into the RPL domain
it may or
may not need source routing as per the capabilities of the
implementation.

In the case where the nodes in the LLN store DAO state, as per the HW
selection made
by the implementation, then it may be possible that the traffic can
traverse down the
DODAG to the destination using only hop-by-hop routing state and without
any
additional modification to the traffic.

In the case where not all of the nodes in the LLN are able to store DAO
state,
intermediate nodes will usually need to add source routing information
to the traffic
at the borders of the non-storing regions that the traffic must
traverse.  In the
case where only the DAG root is capable of storing any DAO state, then
the source
routing information would be added at the DAG root as the traffic enters
the RPL domain.

The design decisions made in RPL thus far try to take into account the
capabilities
of both storing and non-storing nodes.

The exact mechanism to bind source routing information on to the data
traffic is
still to be determined.  Related mechanisms such as address compression
and/or the
use of tags/labels to mitigate the impact on header sizes have also been
suggested by
various members of the WG.

Regards,

-Tim
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll