Subject: Re: [Roll] Roll Digest, Vol 25, Issue 46

From: [email-masked]
Date: Thu, 25 Feb 2010 08:43:26 -0500

Now that the IPR issues is being worked on and moving forward, when are we
going to address the other two key technical issues with ROLL:

1) Point to point routing efficiency

2) Point to Multi-point

Thanks,

Michael Cowan

Elster Solutions, LLC
Principle Systems Engineer/
Demand Response Project Manager
Email:    [email-masked]
Phone:   919-250-5482
Cell:        919-901-9126
Fax:         919-250-5439

208 South Rogers Lane
Raleigh, NC 27610

This email (and any attachments) is confidential and privilege information
of Elster Solutions, LLC

  From:       [email-masked]                                                                                                 
                                                                                                                                    
  To:         [email-masked]                                                                                                         
                                                                                                                                    
  Date:       02/25/2010 04:51 AM                                                                                                   
                                                                                                                                    
  Subject:    Roll Digest, Vol 25, Issue 46                                                                                         
                                                                                                                                    
  Sent by:    [email-masked]                                                                                                 

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

https://www.ietf.org/mailman/listinfo/roll

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send Roll mailing list submissions to
		 [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
		 https://www.ietf.org/mailman/listinfo/roll
or, via email, send a message with subject or body 'help' to
		 [email-masked]

You can reach the person managing the list at
		 [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Roll digest..."

Today's Topics:

   1. Re: Posting of IPR Disclosure related to Cisco's Statement of
      IPR relating to draft-ietf-roll-rpl-06 (Sung Lee)
   2. Re: Questions on DAO operations (Pascal Thubert (pthubert))
   3. Re: Our revised IPR declaration on ROLL (Zach Shelby)
   4. Re: Questions on DAO operations (Jonathan Hui)
   5. Re: Questions on DAO operations (Anders Brandt)

----------------------------------------------------------------------

Message: 1
Date: Wed, 24 Feb 2010 21:34:01 -0500
From: Sung Lee <[email-masked]>
Subject: Re: [Roll] Posting of IPR Disclosure related to Cisco's
		 Statement of IPR relating to draft-ietf-roll-rpl-06
To: "Salazar, Ruben" <[email-masked]>
Cc: [email-masked], "Dan Lang \(dlang\)" <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Pascal,

I too agree with Ruben that this is a great move in the right direction.
Following Dan's recommendation, I will forward this recent decision from
Cisco to our legal.

Best regards,
Sung

Salazar, Ruben wrote:
> Pascal, et al.
> This is definitely a great move in the right direction.
> We feel much better with the new IPR statement from Cisco.
> Regards
>
> Ruben Salazar, PhD
> Director of Research  and Technology
> Landys+Gyr EMS
> Office: 678 258 3165
> Cellular: 678 438 0063
> [email-masked]
> www.landisgyr.com
> manage energy better
>
>
>
>
> Ruben Salazar
> Director of Technology
> Landis+Gyr
> Energy Management Solutions
> Office: +1 678 258 3165
> Fax: +1 678 258 1550
> [email-masked]
> www.landisgyr.com
> manage energy better
> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: Tuesday, February 23, 2010 12:21 PM
> To: Roger Alexander; [email-masked]; Salazar, Ruben; Sung Lee; Emmanuel
Baccelli
> Cc: [email-masked]; Dan Lang (dlang)
> Subject: FW: Posting of IPR Disclosure related to Cisco's Statement of
IPR relating to draft-ietf-roll-rpl-06
>
> Hi Roger, Ruben, Sung, Emmanuel, Don, and all concerned with the Cisco
> IPR debate:
>
> It is my understanding that this new declaration implements Roger's
> suggested compromise regarding Sung and Ruben's concerns, also relayed
> by Emmanuel.
>
> For reference:
> Roger suggested:
> http://www.ietf.org/mail-archive/web/roll/current/msg03045.html
> Sung said:
> http://www.ietf.org/mail-archive/web/roll/current/msg03034.html
> Emmanuel said:
> http://www.ietf.org/mail-archive/web/roll/current/msg03063.html
> Ruben said:
> http://www.ietf.org/mail-archive/web/roll/current/msg03026.html
>
> With this new IPR declaration, Cisco retains its defensive right in the
> context of RPL implementations *only*. By the new terms Cisco will not
> "walk freely anywhere" in someone else's "property". And the answer to
> Sung's question about "infringing patents NOT related to RPL" is now a
> NO. Simply, Cisco opens its IPR on RPL to anyone that reciprocally does
> the exact same, which seems quite fair to me. For all I know, this is a
> major and somewhat exceptional step that should be recognized as such.
> And alternate terms based on RAND are still available to anyone who
> would prefer that way.
>
> Sadly, I'll still refrain from detailing which exact pieces RPL I
> personally think are covered by this IPR. I think it is pretty clear by
> now that this would not have a lot of value since 1) I'm not a lawyer,
> and 2) even less your own lawyer. Also the logic of claims somewhat
> escapes me, in particular when it comes to coverage. All I know is that
> the disclosures I was involved with detail ways to build trees and DAGs,
> propagate metrics and paint unicast and multicast routes along the DAGs,
> compress and expands routing headers, all things that are somewhat
> similar to RPL operations.
>
> I sincerely hope that this declaration will allow us to reach a positive
> consensus on the current poll about Cisco's IPR and move forward with
> RPL as soon as possible. Please let us know.
>
> Pascal
>
>
> -----Original Message-----
> From: IETF Secretariat [mailto:[email-masked]]
> Sent: Tuesday, February 23, 2010 5:18 PM
> To: Pascal Thubert (pthubert); [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Posting of IPR Disclosure related to Cisco's Statement of IPR
> relating to draft-ietf-roll-rpl-06
>
> Dear Pascal Thubert, Tim Winter, ROLL Team:
>
> An IPR disclosure that pertains to your Internet-Draft entitled "RPL:
> IPv6 Routing Protocol for Low power and Lossy Networks"
> (draft-ietf-roll-rpl) was submitted to the IETF Secretariat on
> 2010-02-23 and has been posted on the "IETF Page of Intellectual
> Property Rights Disclosures"
> (https://datatracker.ietf.org/ipr/1270/). The title of the IPR
> disclosure is "Cisco's Statement of IPR relating to
> draft-ietf-roll-rpl-06."
>
> The IETF Secretariat
>
>
>
>

------------------------------

Message: 2
Date: Thu, 25 Feb 2010 08:08:43 +0100
From: "Pascal Thubert (pthubert)" <[email-masked]>
Subject: Re: [Roll] Questions on DAO operations
To: "Jonathan Hui" <[email-masked]>, "Philip Levis"
		 <[email-masked]>
Cc: ROLL WG <[email-masked]>
Message-ID:

<[email-masked]>
Content-Type: text/plain;		 charset="us-ascii"

Hi Phil:

I globally agree with you.

I think we are pretty ripe WRT to the case where source routing is not
used. We have mechanisms that loads nodes send up their DAOs when then
like, and gather DAOs from their subDAG when they like. What's missing
there is more of a matter of recommending when those mechanisms are to
be used.

When it comes to source route, there are a lot more questions:

- should the record route mechanism be part of the DAO as it is today or
should it be part of the traffic as Richard suggested. There are
pro/cons for both approaches and we really need to discuss that in this
list.
-(as you say) optimization for the case where only the root store
states. Right now, we have an S bit mechanism that is not really spelled
out in the spec. This mechanism has assumptions that are not obvious. We
need to agree on it.
- what routing header will be used? How to compress them? This question
is holding 6LoWPAN HC at the moment.

I think we should have a number of threads to examine all of these
questions.

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Hui
Sent: Wednesday, February 24, 2010 4:22 AM
To: Philip Levis
Cc: ROLL WG
Subject: Re: [Roll] Questions on DAO operations

On Feb 23, 2010, at 6:54 PM, Philip Levis wrote:

> On Feb 23, 2010, at 6:41 PM, Jonathan Hui wrote:
>
>> On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote:
>>
>> One of the main purposes of including ranks towards downwards
>> destinations in a DAO is so that a node receiving two DAOs for the
>> same downwards destination can use rank to make a more intelligent
>> decision if the rank differs (i.e. preferring the one with lesser
>> rank).
>
> Let's back up -- the purpose is clear but how it achieves that purpose

> isn't. How is this value computed/filled in? Should -07 specify this?
> Is it correct that DAO Rank is the rank advertised in DIOs? Does that
> mean that a node sending DAOs to multiple DAO parents may specify
> different DAO Rank values. How does this work for aggregated prefixes?

I think it's clear that the DAO mechanism is not nearly as fleshed out
as the DIO mechanism.  The text is intentionally vague (notice all the
'may' text around it) about what the DAO Rank field can contain - it is
simply a place-holder acknowledging the fact that we may want to convey
some notion of cost towards the destination.  DAO aggregation is
something we haven't even discussed yet.

But even before that, we need to back up even further and analyze
whether the basic DAO mechanism fits our needs.  There is concern from
the ROLL WG (including myself) on how DAOs are sent or triggered -
specifically in cases where a network only caches a subset of the DAO
information being sent around.  The main challenge is that the WG would
like to see a solution that allows both networks where all nodes
maintain downward routes and networks where only the root maintains
downward routes.  Some would even like to see networks that where only
some nodes maintain some subset of downward routes.  Unfortunately,
there's some added complexity in requiring an implementation to support
these different modes (e.g. nodes always have to maintain state to know
when to trigger DAOs from their children).  There's certainly a number
of dependencies that are not so obvious at first blush (e.g. a single
DAG parent change could cause DAOs to be sent by every node in that
sub-DAG).

--
Jonathan Hui

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

------------------------------

Message: 3
Date: Wed, 24 Feb 2010 22:13:19 +0200
From: Zach Shelby <[email-masked]>
Subject: Re: [Roll] Our revised IPR declaration on ROLL
To: Dan Lang <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

Dan,

Excellent! I'd like to thank Cisco for the excellent work listening to
feedback from all involved and finding a very good compromise!

Zach

On Feb 23, 2010, at 17:50 , Dan Lang wrote:

>
> Hi,  I wanted to provide a little commentary on the revised licensing
commitment language that was just distributed on the mailer.  We believe
that it will satisfy the concerns as we understand them and allow the WG to
move to the next step.  Again, the proviso for the commentary is that it is
not intended as an interpretation or legal advice and you should seek your
own legal counsel.
>
> Essentially, our new statement, like the old, promises to not assert our
essential patents against functionality that implements ROLL, once
standardized.  The difference is that whereas the old statement suspended,
at our option,  this commitment in response  to any patent assertion
against Cisco or Cisco products, the new statement only potentially
suspends our commitment as to those who assert their essential patents
against Cisco or CIsco products for implementing ROLL.
>
> Dan Lang
> Director, Intellectual Property
> Cisco Systems, Inc.
>
>
>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

--
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain
legally privileged information. If you are not the intended recipient,
please contact the sender and delete the e-mail from your system without
producing, distributing or retaining copies thereof.

------------------------------

Message: 4
Date: Wed, 24 Feb 2010 23:36:09 -0800
From: Jonathan Hui <[email-masked]>
Subject: Re: [Roll] Questions on DAO operations
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: ROLL WG <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

Hi Pascal,

On Feb 24, 2010, at 11:08 PM, Pascal Thubert (pthubert) wrote:

> I globally agree with you.
>
> I think we are pretty ripe WRT to the case where source routing is not
> used. We have mechanisms that loads nodes send up their DAOs when then
> like, and gather DAOs from their subDAG when they like. What's missing
> there is more of a matter of recommending when those mechanisms are to
> be used.

I think there are still some concerns on the lack of compactness for
the messages - that certainly is the case within the 6lowpan WG.
Communicating and storing full IPv6 addresses is fine in the generic
case, but there has to be a more efficient way.

> When it comes to source route, there are a lot more questions:
>
> - should the record route mechanism be part of the DAO as it is
> today or
> should it be part of the traffic as Richard suggested. There are
> pro/cons for both approaches and we really need to discuss that in
> this
> list.
> -(as you say) optimization for the case where only the root store
> states. Right now, we have an S bit mechanism that is not really
> spelled
> out in the spec. This mechanism has assumptions that are not
> obvious. We
> need to agree on it.
> - what routing header will be used? How to compress them? This
> question
> is holding 6LoWPAN HC at the moment.
>
> I think we should have a number of threads to examine all of these
> questions.

Yes, I agree these are all issues.  I think Richard actually suggested
that record-routes are unnecessary if only the root caches downward
routing information, though record-routes can be useful in some
situations (e.g. on-demand route discovery).

A topic that seems to come up every so often is when/where the use of
labels show up.  That could change our thinking and/or perception.

What really worries me is the hidden complexities that result from
needing to support both simultaneously.  I agree that piece-wise
source-routes and being able to operate networks where nodes have
widely varying capabilities can take on different responsibilities,
but we need to be careful that doing so does not grow beyond our state/
communication complexity goals.

Looking forward to talking through these issues in depth.

--
Jonathan Hui

> Pascal
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> Jonathan Hui
> Sent: Wednesday, February 24, 2010 4:22 AM
> To: Philip Levis
> Cc: ROLL WG
> Subject: Re: [Roll] Questions on DAO operations
>
>
> On Feb 23, 2010, at 6:54 PM, Philip Levis wrote:
>
>> On Feb 23, 2010, at 6:41 PM, Jonathan Hui wrote:
>>
>>> On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote:
>>>
>>> One of the main purposes of including ranks towards downwards
>>> destinations in a DAO is so that a node receiving two DAOs for the
>>> same downwards destination can use rank to make a more intelligent
>>> decision if the rank differs (i.e. preferring the one with lesser
>>> rank).
>>
>> Let's back up -- the purpose is clear but how it achieves that
>> purpose
>
>> isn't. How is this value computed/filled in? Should -07 specify this?
>> Is it correct that DAO Rank is the rank advertised in DIOs? Does that
>> mean that a node sending DAOs to multiple DAO parents may specify
>> different DAO Rank values. How does this work for aggregated
>> prefixes?
>
> I think it's clear that the DAO mechanism is not nearly as fleshed out
> as the DIO mechanism.  The text is intentionally vague (notice all the
> 'may' text around it) about what the DAO Rank field can contain - it
> is
> simply a place-holder acknowledging the fact that we may want to
> convey
> some notion of cost towards the destination.  DAO aggregation is
> something we haven't even discussed yet.
>
> But even before that, we need to back up even further and analyze
> whether the basic DAO mechanism fits our needs.  There is concern from
> the ROLL WG (including myself) on how DAOs are sent or triggered -
> specifically in cases where a network only caches a subset of the DAO
> information being sent around.  The main challenge is that the WG
> would
> like to see a solution that allows both networks where all nodes
> maintain downward routes and networks where only the root maintains
> downward routes.  Some would even like to see networks that where only
> some nodes maintain some subset of downward routes.  Unfortunately,
> there's some added complexity in requiring an implementation to
> support
> these different modes (e.g. nodes always have to maintain state to
> know
> when to trigger DAOs from their children).  There's certainly a number
> of dependencies that are not so obvious at first blush (e.g. a single
> DAG parent change could cause DAOs to be sent by every node in that
> sub-DAG).
>
> --
> Jonathan Hui
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

------------------------------

Message: 5
Date: Thu, 25 Feb 2010 10:50:56 +0100
From: "Anders Brandt" <[email-masked]>
Subject: Re: [Roll] Questions on DAO operations
To: "Pascal Thubert (pthubert)" <[email-masked]>
Cc: ROLL WG <[email-masked]>
Message-ID:

<[email-masked]>
Content-Type: text/plain;		 charset="us-ascii"

Hi Pascal

Thanks for taking time to explain your thoughts on DAO.
Unfortunately, I did not really get the idea of your slide deck!

You have Dest sending a RR stack back to C>B>A - but is A then
sending this to child which then sends it to Parent?
Is the distinction that Parent and Child are stateful routers
while A,B,C,Dest can only forward source routed packets?
Maybe some different colors or shapes could help clarify this ;-)

Finally another small clarification:

> Note finally for the gory side of it that A, B, and C etc...
> are not link local addresses.  They have to be global or ULA,
> because they can be used multihop. An implementation might

I agree in this but should RPL do an effort on definition and
compression of such source route stacks?
My point is that you will need to do the same source routing for
actually carrying real traffic along the same route.
As far as I understand IPv6 deprecated source routing as it was
originally defined, so how would you source route IPv6 packets
across a 6lowPan/RPL network?

Thanks,
  Anders

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Pascal Thubert (pthubert)
> Sent: Wednesday, February 24, 2010 17:51
> To: Jonathan Hui; JeongGil Ko (John)
> Cc: ROLL WG
> Subject: Re: [Roll] Questions on DAO operations
>
> Hi John and Jonathan.
>
> I think Question 2 deserves a few more words:
>
> the short answer
> ---------------------
> The point is that the record route in the DAO is for the
> (sole) use of the recorder, when the RR stack has become a
> routing header in a packet on the way back to Destination.
> The packet will have to go between the recorder and loose
> Source Record Route next_hop in the DAO stack, and the
> question is whether the routing info to get there will have
> to be picked from the routing header in the packet, or can be
> found in the routing table of the recorder.
> The IP next-hop to get to the LSRR next-hop is definitively
> the source of the DAO, that's what the DAO is all about. So
> the question is whether the recorder has a route to the LSRR
> next-hop via the source of the packet or not.
> If not, then the recorder needs to insert the next-hop
> information it will need as the new LSRR next-hop on top of
> the LSRR stack.
>
> The long answer
> -------------------
> requires an example, illustrated in the slides attached.
>
> Let us consider a DAO that is originated from Dest. No one
> below Parent decided to cache the specific source route A->B->C->Dest.
>
> Because nodes do not cache everything, it is acceptable,
> though, that DAO routing states are installed all the way
> between child and A. The result is that there's no need to
> additional source route to reach A from child inside <cloud>.
>
> We'll see how that works by forwarding the DAO up one more
> time, child to parent, and see what happens whether the
> parent has a DAO route to A via Child or not.
>
> Childs sends this to parent:
> IP header:
> Source IP = Child
> Dest IP = Parent
> DAO:
> dest = Dest
> Stack = A, B, C
>
>
> Case 1: Parent does a route look up for A, and that does
> resolves via child. Either parent is missing a routing state,
> or its routing state is obsolete. Parent updates the Stack
> that is now Child, A, B, C.
> Case 1a) If parent decides to cache for Dest, then it stores
> Dest via Child, A, B, C.
>                  Parent forwards the DAO to its ancestor as:
>
> 		 IP header:
> 		 Source IP = parent
> 		 Dest IP = Ancestor
> 		 DAO:
> 		 dest = Dest
> 		 Stack = <empty>
>
> 		 The result is that packets to Dest should come back
> without a routing header, with the IP header destination set to Dest.
>                 When Parent forwards a packet to Dest, it
> changes the destination to child, and inserts a RH A, B, C,
> Dest. and proceeds forwarding the packet.
> 		 Child being connected, the lookup resolved immediately
> and the packet is passed to child.
>
> Case 1b) If parent decides not to cache for Dest, then it
> forwards to its own ancestor
> 		 IP header:
> 		 Source IP = parent
> 		 Dest IP = Ancestor
> 		 DAO:
> 		 dest = Dest
> 		 Stack = child, A, B, C
>
> 		 The result is that packets to Dest should come back
> with a routing header child, A, B, C, and with the IP header
> destination set to parent or child, depending on whether
> ancestor has a route to child via parent or not.
>                 If Parent is the destination of the packet,
> then it consumes the next entry in the RH, thus setting child
> as the destination in the IP header, and proceeds forwarding
> the packet.
> 		 In any case, child being connected, the lookup is
> resolved immediately and the packet is passed to child.
>
>
> Case 2: Parent does a route look up for A, and that resolves
> via child.
> Great, we have a routing state that's consistent.
> Case 2a) If parent decides to cache for Dest, then it stores
> Dest via A, B, C.
>                  Parent forwards the DAO to its ancestor as:
>
> 		 IP header:
> 		 Source IP = parent
> 		 Dest IP = Ancestor
> 		 DAO:
> 		 dest = Dest
> 		 Stack = <empty>
>
> 		 The result is that packets to Dest should come back
> without a routing header, with the IP header destination set to Dest
>                 When Parent forwards a packet to Dest, it
> changes the destination to A , and inserts a RH B, C, Dest ,
> and proceeds forwarding the packet now destined to A.
> 		 A route lookup of A resolves in child (as verified
> above), so the packet can be passed to child.
>
> Case 2b) If parent decides not to cache for Dest, then it
> forwards to its own ancestor
> 		 IP header:
> 		 Source IP = parent
> 		 Dest IP = Ancestor
> 		 DAO:
> 		 dest = Dest
> 		 Stack = A, B, C
>
> 		 The result is that packets to Dest should come back
> with a routing header A, B, C, and with the IP header
> destination set to parent or child, depending on whether
> ancestor has a route to child via parent or not.
>                 Parent being the destination of the packet,
> to it consumes the next entry in the RH, iow sets A as the
> destination, and proceeds forwarding the packet now destined to A.
> 		 A route lookup of A resolves in child (as verified
> above), so the packet can be passed to child.
>
> Note finally for the gory side of it that A, B, and C etc...
> are not link local addresses.  They have to be global or ULA,
> because they can be used multihop. An implementation might
> decide to store the connected routes via the link locals, and
> the global of the children via the link local of the children.
> If that's so "Parent does a route look up for A, and that
> does resolves via child" must be understood as lookup for A
> and lookup for child both resolve in the same address, that
> is child's link local address.
>
> This looks a bit complex said that way. I hope the slideware
> attached helps.
>
> Cheers,
>
> Pascal
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jonathan Hui
> Sent: Wednesday, February 24, 2010 3:42 AM
> To: JeongGil Ko (John)
> Cc: ROLL WG
> Subject: Re: [Roll] Questions on DAO operations
>
>
> Hi John,
>
> On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote:
>
> > I was reading through the downwards route section in draft
> 6 (section
> > 6) and had a few questions in mind.
> >
> > 1. How is the DAO rank (in Figure 11) computed and what
> does this rank
>
> > value represent? By having this rank value, does it mean that all
> > nodes keep a rank for the DODAG (constructed using DIO
> > exchanges) separately and also maintain rank values for each
> > 'downwards tree' that it participates in (for example if I have two
> > nodes that rely on me to receive downwards packets, I would be
> > maintaining one DODAG rank and two separate rank values for each of
> > the two nodes)? Is this to assure that the downwards
> packets will make
>
> > 'forward' progress? Why can't this be achieved with the DODAG rank
> > values?
>
> One of the main purposes of including ranks towards downwards
> destinations in a DAO is so that a node receiving two DAOs
> for the same downwards destination can use rank to make a
> more intelligent decision if the rank differs (i.e.
> preferring the one with lesser rank).
>
> > 2. In 6.2.5.1.2 of draft version 6, it states that a non-storing
> > forwarding node will append, on the DAO packet, the address of the
> > 'child' to the RRstack. Why should we add the address of
> the child and
>
> > not the node that is forwarding the packet itself? Is there an
> > intuition behind this design? If there is a reason for this design,
> > how would I retrieve the IP address of the previous hop
> (for sure it
> > is not included in the IP address fields unless I am the
> first hop of
> > the node)?
>
> The IP address of the forwarding node is included in the IP
> header - it would be redundant to include the forwarding
> node's address in the RRstack as well.
>
> --
> Jonathan Hui
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

------------------------------

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

End of Roll Digest, Vol 25, Issue 46
************************************

______________________________________________________________________
This email has been spam and virus checked by Elster IT Services.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 25 Feb 2010 17:14:31 +0100

Hi Michael:

Maybe it is unclear but Point to multipoint is already addressed.

In short, the tree of preferred DAO parents is used as an internal mcast
tree. Listeners registrations are propagated as DAOs. Upon a DAO with a
mcast destination, the router installs a route in the mrib and forwards
the DAO up. Upon a packet to a mcast destination, the router forwards to
packet to its parent and all entries in the mrib, except the node that
passed the packet in the first place.  It is up to the root to advertise
all the listeners to the external infrastructure by proxying the DAO for
multicast groups into MLD.

The long answer is here:
http://tools.ietf.org/html/draft-ietf-roll-rpl-06#section-8  . Obviously
help for improvements is welcome.

Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, February 25, 2010 2:43 PM
To: [email-masked]; [email-masked]
Subject: Re: [Roll] Roll Digest, Vol 25, Issue 46

Now that the IPR issues is being worked on and moving forward, when are
we
going to address the other two key technical issues with ROLL:

2) Point to Multi-point

Thanks,

Michael Cowan

Elster Solutions, LLC

208 South Rogers Lane
Raleigh, NC 27610

This email (and any attachments) is confidential and privilege
information
of Elster Solutions, LLC

  To:         [email-masked]

Today's Topics:

Message: 1

Pascal,

Best regards,
Sung

Baccelli

Message: 2

Hi Phil:

Pascal

-----Original Message-----

--
Jonathan Hui

Message: 3

Dan,

Zach

commitment language that was just distributed on the mailer.  We believe
that it will satisfy the concerns as we understand them and allow the WG
to
move to the next step.  Again, the proviso for the commentary is that it
is
not intended as an interpretation or legal advice and you should seek
your
own legal counsel.
standardized.  The difference is that whereas the old statement
suspended,

--
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded
Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

Message: 4

Hi Pascal,

--
Jonathan Hui

Message: 5

Hi Pascal

Thanks,
  Anders

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 25 Feb 2010 10:13:40 -0800

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pascal Thubert (pthubert)
Sent: Thursday, February 25, 2010 8:15 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Roll] Roll Digest, Vol 25, Issue 46

Hi Michael:

The long answer is here:

Cheers,

Pascal

-----Original Message-----

2) Point to Multi-point

Thanks,

Michael Cowan

Elster Solutions, LLC

208 South Rogers Lane
Raleigh, NC 27610

 

  To:         [email-masked]

Today's Topics:

Message: 1

Pascal,

Best regards,
Sung

Baccelli

Message: 2

Hi Phil:

Pascal

-----Original Message-----

--
Jonathan Hui

Message: 3

Dan,

Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

Message: 4

Hi Pascal,

--
Jonathan Hui

Message: 5

Hi Pascal

Thanks,
  Anders

---

From: Tim Winter <[email-masked]>
Date: Sun, 28 Feb 2010 19:30:19 -0500

Hi Don,

> header sizes to see if this will actually work for our application.

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