Subject: RE: [manet] discussion on the routing protocol at Link Layer

From: "Yang, Lily L" <[email-masked]>
Date: Wed, 19 Mar 2003 11:20:34 -0800

Guoxiang --
This certainly sounds interesting. Most of the existing routing protocols
for MENET are done at one layer up but we also believe there are certain
advantages of doing this at the data link layer. 
Do you have a more complete documentation on this that you can share with
us? 

Lily

-----Original Message-----
From: lu guoxiang [mailto:[email-masked]]
Sent: Monday, March 17, 2003 5:36 PM
To: [email-masked]
Subject: [manet] discussion on the routing protocol at Link Layer

hi all,

i am implementing a bridging method by which the data forwarding function is

realised at the data link layer. i would like to hear your comment on the 
pros and cons of this protocol.

first of all, the nodes will form clusters and the bridges which are used to

communicate neighboring clusters are selected.

and, it is a reactive routing protocol. b4 sending data to dst, the src will

multicast a "Request_MAC" message that asking the mac address of the dst. 
only the bridges elected are resposible to forwarding the "Request_Mac" 
message.
when dst recv the "Request_Mac", it will unitcast a reply back with its MAC 
address. this process is like AODV except for the addtional MAC address of 
the dst. same as the AODV, during the request and reply process, all the 
intermediate nodes that either receive request or reply know the way to the 
src or dst or both.

after the src get dst's MAC address, it will unicast the data pkt to the 
dst. when a intermediate node recv a data pkt, it will check whether it has 
the route or not. if it has, just forward the pkt to the dst. otherwise, it 
will multicast the pkt to bridges.

the intermediate nodes, which relay the data pkt, actually do the routing at

the datalink layer. it won't pass the pkt to the network layer, cause it 
knows the dst's mac addr as well as next hop's mac addr. by doing this, we 
can reduce some processing time.

and by the cluster formation, we the "Request_MAC" message are not blindly 
flooded. thus, we can reduce the routing load.

ok, it is just a brief description on my routing protocol. your valuable 
comments on it are greatly appreciated.

cheers,
guoxiang

_________________________________________________________________
Take a break! Find destinations on MSN Travel. http://www.msn.com.sg/travel/

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Mineo Takai <[email-masked]>
Date: Wed, 19 Mar 2003 11:43:32 -0800

Hi,

DBS (Dynamic Backbone Subnets) by NRL is one of such routing mechanisms 
at the data link layer. They presented a tutorial at the IEEE 802 
Plenary Meeting this month.

http://www.ieee802.org/meeting/meeting_files/DBS%20AP-AP%20Routing.pdf

Mineo

---

From: Manish Karir <[email-masked]>
Date: Wed, 19 Mar 2003 15:15:47 -0500

I think LUNAR did something along those lines as well...:

http://www.docs.uu.se/docs/research/projects/selnet/lunar/

manish

---

From: Michael Neufeld <[email-masked]>
Date: Wed, 19 Mar 2003 13:46:21 -0700

While they aren't explicitly "ad hoc" routing protocols, SmartBridge 
(http://citeseer.nj.nec.com/rodeheffer00smartbridge.html) and STAR 
Bridge (can't find the website right now) both do layer 2 bridging with 
an eye towards scalability.

-Mike

Manish Karir wrote:
>> advantages of doing this at the data link layer. Do you have a more 
>> complete documentation on this that you can share with
>> us?
>> Lily
>>
>> realised at the data link layer. i would like to hear your comment on 
>> the pros and cons of this protocol.
>>
>> multicast a "Request_MAC" message that asking the mac address of the 
>> dst. only the bridges elected are resposible to forwarding the 
>> "Request_Mac" message.
>> when dst recv the "Request_Mac", it will unitcast a reply back with 
>> its MAC address. this process is like AODV except for the addtional 
>> MAC address of the dst. same as the AODV, during the request and reply 
>> process, all the intermediate nodes that either receive request or 
>> reply know the way to the src or dst or both.
>>
>> after the src get dst's MAC address, it will unicast the data pkt to 
>> the dst. when a intermediate node recv a data pkt, it will check 
>> whether it has the route or not. if it has, just forward the pkt to 
>> the dst. otherwise, it will multicast the pkt to bridges.
>>
>> the datalink layer. it won't pass the pkt to the network layer, cause 
>> it knows the dst's mac addr as well as next hop's mac addr. by doing 
>> this, we can reduce some processing time.
>>
>> and by the cluster formation, we the "Request_MAC" message are not 
>> blindly flooded. thus, we can reduce the routing load.
>>
>> ok, it is just a brief description on my routing protocol. your 
>> valuable comments on it are greatly appreciated.
>>
>> cheers,
>> guoxiang
> 
>

---

From: Joe Macker <[email-masked]>
Date: Wed, 19 Mar 2003 16:10:08 -0500

HIPERLAN 1, also was a such a technique  at a lower layer and OLSR is loosely based upon that work.  There are also many other historical subnet approaches.  MANET is chartered to work IP layer solutions.

-Joe