Re: [Roll] updating DAO caches (was Re: Something to ADD)

["Pascal Thubert (pthubert)" <pthubert at cisco.com>]

Hi Roger:

The IPR can be very problematic. The IETF has rules about it. But if
some group outside 
the IETF and not playing by those rules is waiting for us to fall in
their trap then we 
should know about it.

Cisco has IPR that covers some of the RPL operations. We have published
a statement
here https://datatracker.ietf.org/ipr/1134/ and as you see it is
strictly defensive.

The bright side is that we also have IPR that enables to compress/expand
source route in
In IP/MANET world, and we have all the label switching art on our side
if we use labels.

If the draft goes in that direction, this IPR and art might supersede
the one you have 
in mind (non IP is that right?) though I could not infer the result of a
legal course. 

Are there some external  publications that we should know about?

Pascal

>-----Original Message-----
>From: roll-bounces at ietf.org [mailto:roll-bounces at ietf.org] On Behalf Of
Roger Alexander
>Sent: mercredi 18 novembre 2009 03:48
>To: Jonathan Hui
>Cc: roll at ietf.org
>Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD)
>
>Hi Jonathan,
>
>I do very much agree with the points you have made below. From the
>perspective of a network with only fully capable nodes I would like to
>see if there are ways for networks to operate with mixed capability
>nodes without undue overhead as also appears to be indicated in the
>type of approach discussed by Pascal. That should also allow RPL to be
>able to operate efficiently for networks where only the root maintains
>state.
>
>As I have indicated, the resulting source routing for networks that
>store DAOs only at the root must be an option not a base. In the AMI
>space, IPR lawsuits have been brought against many network companies
>that use source routing. As a company whose networks do not implement
>any form of source routing we would wish to ensure that we and others
>are free to preserve that operating capability even within the RPL
>framework. To ensure that networks that choose can also implement
>source routing, low-overhead coexistence should be the goal. Ideally,
>the ability to separate the protocol operation through distinct modes
>would be preferred though that may move the problem elsewhere.
>
>Roger
>
>On Nov 17, 2009, at 12:49 PM, Jonathan Hui <jhui at archrock.com> wrote:
>
>>
>> Hi Roger,
>>
>> On Nov 17, 2009, at 12:25 PM, Roger Alexander wrote:
>>
>>> The conclusions drawn are not entirely valid in part due to the
>>> particular example given. Quite often the examples used to
>>> demonstrate the protocol are of necessity simpler ones but may not
>>> capture the larger variety of connectivity seen particularly in
>>> larger multihop networks. I will try to make the case using a
>>> slightly more complex network graph which illustrate the benefit of
>>> intermediate state storage and how it might work without explicit
>>> indications of which note are maintaining state.
>>
>> A fair characterization is that the change in down route state must
>> be reflected up until there is a common ancestor that provides
>> connectivity both before and after the change in connectivity *and*
>> can store down routes.  In the example that Richard provided, A was
>> the common ancestor and it also happened to be the root.  But it is
>> also true that nodes within the sub-DAG of A must update their DAO
>> routing state to reflect the change in topology.  As Richard's
>> example points out, when you allow nodes to chose whether they can
>> store down route state, nodes within the sub-DAG must assume the
>> worst case and originate their own DAO messages in case nodes
>> between it and the common ancestors cannot maintain down routes.
>>
>> That said, the cost savings of having storage at intermediate nodes
>> depends mostly on the depth of the common ancestor - a common
>> ancestor with greater depth will result in less transmissions that
>> propagate information towards the root.  Of course, in the worst
>> case, the common ancestor will be the root.  An unfortunate edge
>> case with hierarchical structures is that the common ancestor of you
>> and your neighbor could be the root.
>>
>> I think it is fair to say that the current DAO caching capabilities
>> specified in the RPL doc need quite a bit more thought before I
>> would be comfortable with putting it into the base specification.
>> If there is a way to treat it as an optimization, I would prefer to
>> do so and work on that in a separate draft.
>>
>> --
>> Jonathan Hui
>>
>
>_______________________________________________
>Roll mailing list
>Roll at ietf.org
>https://www.ietf.org/mailman/listinfo/roll