Subject: [Roll] Fwd: I-D Action:draft-iwao-roll-dadr-00.txt

From: Sung Lee <[email-masked]>
Date: Tue, 07 Jul 2009 21:19:15 -0400

Dear ROLL WG,

We, Fujitsu, have real experience of building an Ad-hoc network system
with over 1000 nodes using proposed protocol, and we want to contribute
to designing a new protocol within ROLL-WG.

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-iwao-roll-dadr-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

I asked ROLL-WG chairs to give us some presentation time for next IETF
meeting. I hope we will have a good discussion.

I would appreciate your comments.

Thanks in advance and best regards,

Sung Lee
Fujitsu Laboratories of America, Inc
 
[email-masked] wrote:
> Message: 3
> Date: Mon, 6 Jul 2009 10:33:55 +0200
> From: JP Vasseur <[email-masked]>
> Subject: [Roll] Fwd: I-D Action:draft-iwao-roll-dadr-00.txt
> To: ROLL WG <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"; Format="flowed";
> 	DelSp="yes"
>
> At the agenda of the ROLL WG meeting.
>
> Begin forwarded message:
>
>   
>> From: [email-masked]
>> Date: July 6, 2009 4:45:01 AM CEDT
>> To: [email-masked]
>> Subject: I-D Action:draft-iwao-roll-dadr-00.txt
>> Reply-To: [email-masked]
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>> 	Title           : Distributed Autonomous Depth-first Routing
>> Protocol in LLN
>> 	Author(s)       : T. Iwao
>> 	Filename        : draft-iwao-roll-dadr-00.txt
>> 	Pages           : 24
>> 	Date            : 2009-07-05
>>
>> This document is a proposal of the distributed autonomous depth-first
>>
>>  routing (DADR) protocol which is quite different from conventional
>>
>>  algorithms such as AODV and OLSR. It proposes a traversable algorithm
>>
>>  which can determine a direct path between the global source and the
>>
>>  global destination in a low power and lossy network (LLN). We propose
>>
>>  the DADR algorithm whose characteristics work well in LLNs with more
>>
>>  than 10^4 nodes. This algorithm selects a direct path between the
>>
>>  global source and the global destination based on a routing-cost-
>>
>>  function which identifies path-candidates with good communication
>>
>>  quality between each pair of nodes on the path. This protocol does
>>
>>  not need to configure the equipment such as setting IP addresses, and
>>
>>  thisresults in saving cost and time in deploying, establishing and
>>
>>  operating a large scale network.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  Iwao, et al.
>>
>>
>>  Expires January 2, 2010
>>
>>
>>
>>
>>  [page 2]
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  Internet-Draft
>>
>>
>>
>>  DADR Protocol
>>
>>
>>
>>
>>
>>
>> July 2009
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-iwao-roll-dadr-00.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>     
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-archive/web/roll/attachments/20090706/309a3bba/attachment.htm>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: text/plain<br>content-id: &lt
> Size: 0 bytes
> Desc: not available
> Url : <http://www.ietf.org/mail-archive/web/roll/attachments/20090706/309a3bba/attachment.bin>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-archive/web/roll/attachments/20090706/309a3bba/attachment-0001.htm>
>
> ------------------------------
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>
> End of Roll Digest, Vol 18, Issue 26
> ************************************
>

---

From: "Goindi, Manhar" <[email-masked]>
Date: Wed, 8 Jul 2009 15:07:59 +1000

Hi,

Thanks for sharing the DADR protocol.  I have been able to scan through
it & have some basic questions:

1.  How is the path cost value computed?  How does the originating node
have the path cost value for the entire path?  Is this done at the time
of route discovery?
2.  How does route discovery actually take place?  Can it be illustrated
with the help of Hello Messages?
3.  How do we control the flooding of Hello messages as against the
breadth-first search protocol?
4.  What decides between Figure 1 & Figure 2 that time synchronization
is successful?  Does it carry any significance for the originator of
Time Synchronization to be aware of the outcome of Time Synchronization
initiated by it (I think it may not as time synchronization is quite a
decentralized function)?
5.  DFS mechanism depends on a Tree-like structure for route discovery.
Is this what is being proposed for path information maintenance?  Is
there any concept of Parent, Sibling, Child, depth etc. between nodes?
(The draft is very open and does not deal with any specific
recommendation).

Please let me know - if there is someplace I can find answers to these
questions as this may still be evolving as a standard.

Thanks & Best Regards,
Manhar Goindi

Manhar Goindi
Technical Expert
Landis+Gyr
Phone: +91 120 3352149
[email-masked]
http://www.landisgyr.com/

Manage Energy Better

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sung Lee
Sent: Wednesday, July 08, 2009 6:49 AM
To: [email-masked]
Subject: [Roll] Fwd: I-D Action:draft-iwao-roll-dadr-00.txt

Dear ROLL WG,

Sung Lee
 
[email-masked] wrote:
> URL:
<http://www.ietf.org/mail-archive/web/roll/attachments/20090706/309a3bba
/attachment.htm>
> Url :
<http://www.ietf.org/mail-archive/web/roll/attachments/20090706/309a3bba
/attachment.bin>
> URL:
<http://www.ietf.org/mail-archive/web/roll/attachments/20090706/309a3bba
/attachment-0001.htm>

PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: Sung Lee <[email-masked]>
Date: Wed, 15 Jul 2009 23:45:29 -0400

Hi Manhar,

Thanks for your interest and questions.
My apologies for a slow response - I did take a few days off and am just 
getting back to work.
Please see inline for my response.
Hope that my response adequately answers your questions.

Best regards,
Sung

> have the path cost value for the entire path?  Is this done at the time

DADR is flexible in that the path cost computation can be adjusted to 
fit one's needs. It can be as simple as hop count, for example. The cost 
of the entire path does not need to be known. Once again, depending on 
the network characteristics and requirements, the entire path cost could 
be computed or estimated, if desired.

> with the help of Hello Messages?

Could you describe your definition of "route discovery"?
If you mean the construction of route table, DADR roughly constructs 
routes using Hello Messages (destinations and routing table information 
are shared to next hop neighbors which in turn will be propagated to the 
entire network).
Please note that the route tables need not be complete or loop free.
The final route is learned as packets are transmitted through the network.
When a loop is detected, the node will try an alternate route or 
backtrack to the "parent" node (that sent the message).

> breadth-first search protocol?

DADR does not employ the flooding method. It uses a periodic 
transmission of Hello messages. The period of Hello message transmission 
can be configurable.

> initiated by it (I think it may not as time synchronization is quite a

We need to update the figures.  The Gateway/NTP node usually
triggers a synchronization message.   Figure 1 will represent an
incorrect procedure where only the present time is propogated.   Figure
2 will represent the proposed scheme where both the original
synchronization time and the current time are propogated, resulting in
desired network synchronization.

Manhar, you are correct that the originator of Time Synch does not care 
about the outcome of time synch.

> (The draft is very open and does not deal with any specific

Hello messages are used to maintain a rough routing information. 
However, DADR does not require a strict tree like structure or a loop 
free structure. We do not have sibling concept. Parent and child 
information is only existing during the transmission of data packet as a 
node keeps track of where the packet came from (for backtracking purpose 
in the case of unsuccessful delivery).

Thanks and best regards,
Sung

>>>  algorithms such as AODV and OLSR. It proposes a traversable
>>>       
> algorithm
>   
>>>  global destination in a low power and lossy network (LLN). We
>>>       
> propose
>   
>>>  not need to configure the equipment such as setting IP addresses,
>>>       
> and
>