Subject: CfP. ad hoc networking session at SCI 2001

From: Pietro Manzoni <[email-masked]>
Date: Tue, 14 Nov 2000 10:07:39 +0100

Announcement and Call
for Papers

Ad Hoc Networking
Session at:

The 5th World
Multi-Conference on Systemics, Cybernetics and Informatics SCI 2001

July 22-25, 2001

Orlando, Florida
USA

Sheraton World
Resort

http://www.iiis.org/sci/default.htm

We are interested in work-in-progress, experimental and systems-related
papers. Topics of interest include, but are not limited to:

Ad Hoc Routing Protocols

Ad Hoc Multicasting Protocols - Ad Hoc Transport Issues

Service Discovery Protocols

Media Access Techniques

Low Power Algorithms and Protocols

Ad Hoc Mobile Applications

Quality of Service Issues

SUBMISSIONS

Postscript copies of your submissions should be sent to:

Juan Carlos Cano ([email-masked]),
or

Pietro Manzoni ([email-masked])

All papers will be reviewed for technical merit.

IMPORTANT DATES

December 15, 2000: Submission of extended
abstracts (500-1500 words)or paper draft(2000-2500 words)

February 16, 2001: Acceptance
notifications

April 13, 2001: Submission of
camera/ready papers: hard copies and electronic versions

More complete call-for-paper can be found at:
http://www.iiis.org/sci/CallForPapers.htm

---

From: Lusheng Ji <[email-masked]>
Date: Wed, 15 Nov 2000 12:48:40 -0500 (EST)

Greetings.

While I was reading the MAODV draft (maodv-00.txt), found that
there might be a situation under which MAODV could not prevent
routing loops from forming.  The details is as follows.

MAODV orders all the nodes by hop counts to group leader.  During
tree link repairing, only those who are on tree and whose hop counts are
not greater than the hop count in RREQ (which is the repairing node's own
hop count to group leader) can reply the RREQ.  Of course, the group
sequence number is also taken into consideration for hop count
freshness.

At time T1:

  (L) ------ n1 ------- n2 ------ n3 ------ n4 ------ n5
  
(L) being the group leader, others are tree nodes.  A tree branch
exists as (L) <--- n1 <--- n2 <--- n3 <--- n4 <--- n5.  so n5
has hop count to group leader of 5 at this time.

At time T2:  

  (L) ------ n1 ------- n2
   .                    |
   .                    |
   .                    |
   n5 ------ n4 ------- n3

Now n5 and (L) have a link between them (not used by multicast tree).
After (L) sends out a new GRPH, n5 will update its "hop count
to group leader" to 1 and result in an inconsistency: n5 has a
very low hop count to group leader but actually in the multicast tree
it is far away from the leader.

if some link, say n2 -- n1 link, is broken, and n2 (which still has
hop count to leader as 2) tries to repair the link, n5 is qualified to
accept such repair join since its hop count is less than 2.  Then a
loop n5 -- n4 -- n3 -- n2 -- n5 may be formed. 

If I was reading the draft wrong, could someone please point it out
for me?  Thanks. 

Lusheng