Subject: [Roll] DAG ID - Do we really need 128 bits to identify a DAG

From: Robert Assimiti <[email-masked]>
Date: Thu, 14 Jan 2010 15:44:48 -0500

Going through draft-ietf-roll-rpl-05 I have noticed that the DAGID is an 128-bit unsigned int.

The scope of the DAGID is a DAG instance within an LLN. The DAGID could be global IPv6 address of the DAG root.

Do we really need 128-bits (transferred over lossy links) just to indentify a parameter with such limited scope?

IMHO, we either increase the scope (global) or decrease the length.

Am I missing something here?

Robert Assimiti
Executive Staff Engineer
Office: [678]-202-6859
Mobile: [404]-578-0205
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, January 14, 2010 1:11 PM
To: [email-masked]
Subject: Roll Digest, Vol 24, Issue 7

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: Nodes Mobility Support in RPL (Leila Ben Saad)
   2. Re: Nodes Mobility Support in RPL (Alexandru Petrescu)
   3. Re: RPL Simulation ([email-masked])

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

Message: 1
Date: Thu, 14 Jan 2010 08:11:45 +0100
From: Leila Ben Saad <[email-masked]>
Subject: Re: [Roll] Nodes Mobility Support in RPL
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
        format="flowed"

I mean by my question if RPL is able to support the case where DAG
roots are mobile nodes ? The example of this can be a wireless sensor
network with mobile sinks where the sinks move to different locations
of the network in order to balance the energy consumption of the fixed
sensor nodes and improve the network lifetime.

Alexandru Petrescu <[email-masked]> a ?crit :

> As a pre-requisite, I would consider looking at the RoLL
requirements
> documents and search for 'mobil' and find some use cases which were
used
> as motivators for RoLL.  But during the subsequent RoLL work, the
> mobility aspects were not hugely important.
>
> Le 06/01/2010 15:52, Leila Ben Saad a ?crit :
>> Dear WG,
>>
>> Is RPL able to support the mobility of DAG roots ?
>
> Well I guess DAG roots could move around a little bit and stay
within
> the link-layer's reachability range (e.g. 10meters).  If this is
> considered 'mobility' then automatically RPL does support it I
believe.
>
> On another hand, if we consider 'mobility' to involve a change of
the
> address assigned to a node then I don't think RPL has much support
for
> it.  I am not sure this is needed either in RPL.
>
>> Because if we move DAG roots frequently, the topology will be
>> modified, new DODAGS must be constructed, more DIO messages will
be
>> sent which can can diminish the energy of nodes and limit their
>> lifetime.
>>
>> Has RPL been already evaluated in network with mobile nodes ?
>
> I don't know.  Do you mean a Mobile Node as in Mobile IPv6?  Or
just
> entities which could be mobile?  I.e. is a DAG Root a Mobile Node?
Or
> are only the nodes within the RoLL network (not the DAG Root)
mobile nodes?

>
> Just some comments,
>
> Alex
>
>>
>> Thanks,
>>
>> Leila Ben Saad PhD Student ENS Lyon France
>>
>>
>>
>>
>> _______________________________________________ Roll mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>
>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

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

Message: 2
Date: Thu, 14 Jan 2010 12:07:20 +0100
From: Alexandru Petrescu <[email-masked]>
Subject: Re: [Roll] Nodes Mobility Support in RPL
To: Leila Ben Saad <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Le 14/01/2010 08:11, Leila Ben Saad a ?crit :
> I mean by my question if RPL is able to support the case where DAG
> roots are mobile nodes ? The example of this can be a wireless sensor
> network with mobile sinks where the sinks move to different
> locations

How far is the new location of the mobile sink?  If it is within the
range of the link layer capabilities (e.g. 10meters for a PAN like
Bluetooth) then I guess RPL-to-be supports it.

If on the other hand the mobile sink moves further than the range of the
link-layer then some big changes must happen in addressing and routing
for RPL-to-be in order to support this kind of mobility.

Just some thoughts,

Alex

> of the network in order to balance the energy consumption of the
> fixed sensor nodes and improve the network lifetime.
>
>
> Alexandru Petrescu <[email-masked]> a ?crit :
>
>> As a pre-requisite, I would consider looking at the RoLL
> requirements
>> documents and search for 'mobil' and find some use cases which
>> were
> used
>> as motivators for RoLL. But during the subsequent RoLL work, the
>> mobility aspects were not hugely important.
>>
>> Le 06/01/2010 15:52, Leila Ben Saad a ?crit :
>>> Dear WG,
>>>
>>> Is RPL able to support the mobility of DAG roots ?
>>
>> Well I guess DAG roots could move around a little bit and stay
> within
>> the link-layer's reachability range (e.g. 10meters). If this is
>> considered 'mobility' then automatically RPL does support it I
> believe.
>>
>> On another hand, if we consider 'mobility' to involve a change of
> the
>> address assigned to a node then I don't think RPL has much support
> for
>> it. I am not sure this is needed either in RPL.
>>
>>> Because if we move DAG roots frequently, the topology will be
>>> modified, new DODAGS must be constructed, more DIO messages will
> be
>>> sent which can can diminish the energy of nodes and limit their
>>> lifetime.
>>>
>>> Has RPL been already evaluated in network with mobile nodes ?
>>
>> I don't know. Do you mean a Mobile Node as in Mobile IPv6? Or
> just
>> entities which could be mobile? I.e. is a DAG Root a Mobile Node?
> Or
>> are only the nodes within the RoLL network (not the DAG Root)
> mobile nodes?
>
>
>
>>
>> Just some comments,
>>
>> Alex
>>
>>>
>>> Thanks,
>>>
>>> Leila Ben Saad PhD Student ENS Lyon France
>>>
>>>
>>>
>>>
>>> _______________________________________________ Roll mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>>
>>
>>
>> _______________________________________________ Roll mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>
>
>
> _______________________________________________ Roll mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

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

Message: 3
Date: Thu, 14 Jan 2010 12:10:38 -0600
From: [email-masked]
Subject: Re: [Roll] RPL Simulation
To: Joydeep Tripathi <[email-masked]>
Cc: ROLL WG <[email-masked]>
Message-ID:
        <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Hi Joydeep,

Mukul's been doing some simulations for my company for the past 3 years.
He has a good handle on the commercial building performance requirements.
It would be good for you to run those he notes below.  It might be
advantageous then for you two to share the results to better correlate the
simulations.

I would also look at the latency for P2P messages when the packet(s) need
to traverse the DAG all the way up to the LBR and back down to the
destination node.  Of course, this is now a function on DAG depth.  Also
since all our messages require ACK, the additional latency of the ACK
having to return possibly through a different set of nodes yet via the
LBR.  That would be the worst case scenario.  If other nodes could short
circuit the packets through a shorter path, that would on;y help.

Since Building systems are real-time (smoke/fire detection, turning on
lights, etc) latency is a big issue.  Moving the packet up and down the
DAG is reasonably deterministic and should be primarily a function of the
DAG depth.  However, what will really affect the system performance is
'DAG Repair'.  I have no sense how long a packet in transit would have to
wait if the DAG was under repair.  Since we require ACKs of every message,
the source node would time-out and retry a few times (usually 3).  After
that, the source node would have to fall into some 'failsoft' mode
depending on the type of data it was trying to access.  This is not a good
situation.  The source node can only assume that its data is inaccessible,
not just held up in transit.  The fail-soft mode will have large
hysteresis since it can't be constantly dithering between modes.  This
will all be logged to the operator which is a bad thing!!!  That was what
was nice about an AODV concept, because even route repair was fairly
deterministic.

So... if your simulation could measure packet latency as a function of DAG
repair severity, that would be terrific.

Hope this makes sense.

Jerry

Mukul Goyal <[email-masked]>
01/13/2010 10:17 AM

To
Joydeep Tripathi <[email-masked]>
cc
ROLL WG <[email-masked]>, Jerald P Martocci <[email-masked]>
Subject
Re: [Roll] RPL Simulation

Joydeep

Here are a few suggestions for your simulations:

1. Simulate a 100 node and a 1000 node topology operating under a single
DAG

2. Simulate both scenarios: optimal DAG routes (ie the path through the
DAG from a source to a destination passes through their closest common
ancestor) and DAG routes through root (all DAG paths have to go through
the DAG root).

3. Study the stretch factor (increase in length/cost of routes over the
DAG versus the length/cost of ideal routes) for given number of flows:
100, 1000, 10000 and possibly n*(n-1) flows (where n is the number of
nodes in the topology:
a) the scenario you suggested: Choose 20% flows over 2 hop neighbors, 10%
flows over longer paths.
b) randomly selected source and destinations (in n*(n-1) case, from each
possible source node to each possible destination node).

4. In addition to the stretch factor, calculate/simulate the traffic loads
as well as packet loss/delay along the DAG links. Compare these values
against values with ideal P2P routing.

Thanks
Mukul
----- Original Message -----
From: "Joydeep Tripathi" <[email-masked]>
To: "Jerald P Martocci" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>
Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada Central
Subject: [Roll] RPL Simulation

Hi,

In the next revision, we are also planning to implement a typical
building routing scenario, where 60-70% of the P2P traffic are
confined within 1 hop physical distance and, 20% of the P2P traffic
are to a 2 -hop distance destination, and observe the performance of
RPL against the ideal shortest route. Also, please let us know if
there is any other scenario or traffic pattern you want to be
implemented.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/roll/attachments/20100114/fb190fb9/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 12611 bytes
Desc: not available
Url : <http://www.ietf.org/mail-archive/web/roll/attachments/20100114/fb190fb9/attachment.jpeg>

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

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

End of Roll Digest, Vol 24, Issue 7
***********************************

This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 18 Jan 2010 09:32:53 +0100

Hi Robert:

This and many other things could and should be compressed. For instance
the DAO, the source route info in particular but also the way we pack
DAO together, and a number of other fields. At the moment we are looking
at making the protocol sane and secure, and then we'll focus on making
the PDU shorter.

Have a great year!

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Assimiti
Sent: jeudi 14 janvier 2010 21:45
To: [email-masked]
Subject: [Roll] DAG ID - Do we really need 128 bits to identify a DAG

Going through draft-ietf-roll-rpl-05 I have noticed that the DAGID is an
128-bit unsigned int.

The scope of the DAGID is a DAG instance within an LLN. The DAGID could
be global IPv6 address of the DAG root.

Do we really need 128-bits (transferred over lossy links) just to
indentify a parameter with such limited scope?

Robert Assimiti
Executive Staff Engineer
Office: [678]-202-6859
Mobile: [404]-578-0205

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, January 14, 2010 1:11 PM
To: [email-masked]
Subject: Roll Digest, Vol 24, Issue 7

Today's Topics:

Message: 1

requirements
used
within
believe.
the
for
be
just
Or
mobile nodes?

Message: 2

Just some thoughts,

Alex

Message: 3

Hi Joydeep,

Mukul's been doing some simulations for my company for the past 3 years.
He has a good handle on the commercial building performance
requirements.
It would be good for you to run those he notes below.  It might be
advantageous then for you two to share the results to better correlate
the
simulations.

I would also look at the latency for P2P messages when the packet(s)
need

Since Building systems are real-time (smoke/fire detection, turning on
lights, etc) latency is a big issue.  Moving the packet up and down the
DAG is reasonably deterministic and should be primarily a function of
the
DAG depth.  However, what will really affect the system performance is
'DAG Repair'.  I have no sense how long a packet in transit would have
to
wait if the DAG was under repair.  Since we require ACKs of every
message,
the source node would time-out and retry a few times (usually 3).  After
that, the source node would have to fall into some 'failsoft' mode
depending on the type of data it was trying to access.  This is not a
good
situation.  The source node can only assume that its data is
inaccessible,
not just held up in transit.  The fail-soft mode will have large
hysteresis since it can't be constantly dithering between modes.  This
will all be logged to the operator which is a bad thing!!!  That was
what
was nice about an AODV concept, because even route repair was fairly
deterministic.

So... if your simulation could measure packet latency as a function of
DAG
repair severity, that would be terrific.

Hope this makes sense.

Jerry

To

Joydeep

a) the scenario you suggested: Choose 20% flows over 2 hop neighbors,
10%

4. In addition to the stretch factor, calculate/simulate the traffic
loads
as well as packet loss/delay along the DAG links. Compare these values
against values with ideal P2P routing.

Thanks
Mukul
----- Original Message -----
From: "Joydeep Tripathi" <[email-masked]>
To: "Jerald P Martocci" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>
Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada
Central

Hi,

Thanks,
Joydeep

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/roll/attachments/20100114/fb190fb9
/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 12611 bytes
Desc: not available
Url :
<http://www.ietf.org/mail-archive/web/roll/attachments/20100114/fb190fb9
/attachment.jpeg>

This e-mail (including any attachments to it) is confidential,
proprietary, legally privileged, subject to copyright and is sent for
the personal attention of the intended recipient only. If you have
received this e-mail in error, please reply to advise us immediately,
delete it and destroy any printed copies of it. You are notified that
reading, disclosing, copying, distributing or taking any action in
reliance on the contents of this information is strictly prohibited. No
employee is authorized to conclude any binding agreement on behalf of
NIVIS LLC with another party by e-mail without express written
confirmation by an officer of the company. Although we have taken
reasonable precautions to ensure no viruses are present in this e-mail,
we cannot accept responsibility for any loss or damage arising from the
viruses in this e-mail or attachments.
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll