Subject: Re: [manet] why IP address in ad hoc networks

From: "Alvin C Valera Alvin" <[email-masked]>
Date: Mon, 05 Aug 2002 15:41:06 +0800

On Fri, 2 Aug 2002, zb wrote:

>  1) whether the IP address can be replaced by another node ID or not

Yes, you need not use IP addresses in ad hoc networks. In fact, some protocols (such as DSDV, AODV or DSR) give you the freedom on this aspect (you can either use MAC or IP addresses in the routing tables)

I remember a paper from ISI regarding dynamic addressing. Nodes choose identifiers randomly. Of course, the problem is, it is possible that two or more nodes use the same address therefore creating some
complications.  
 
>  2) in which case it works and in which case it does not works

I'm sure as long as you have a consistent addressing scheme in your ad hoc network, it should work in all cases. Of course, when a packet needs to go out of the MANET (say, to the Internet), you need some address
translators or some other sort of address mapping.
 
>  3) the pros and cons use another node ID

Pros: 
- No need for address resolution (e.g. ARP) and IP->MAC mapping table.

Cons:
- You may have larger routing tables due to longer addresses. (However, since you don't need a separate IP->MAC mapping table, you may actually
still save memory)
- Routing protocol is network-dependent.

Can't think of others... I'm sure there are a lot more
advantages/disadvantages using this scheme.

Regards,
Alvin

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

---

From: "Alvin C Valera Alvin" <[email-masked]>
Date: Mon, 05 Aug 2002 15:41:06 +0800

Pros: 

Cons:

Regards,
Alvin

---

From: "Naidu, Venkata" <[email-masked]>
Date: Mon, 5 Aug 2002 11:35:38 -0400

-> >  3) the pros and cons use another node ID
-> 
-> Pros: 
-> - No need for address resolution (e.g. ARP) and IP->MAC 
-> mapping table.
-> 
-> 
-> Cons:
-> - You may have larger routing tables due to longer 
-> addresses. (However, since you don't need a separate IP->MAC 
-> mapping table, you may actually
-> still save memory)
-> - Routing protocol is network-dependent.
-> 
-> Can't think of others... 

  More cons...
  - You may lose the power of IP routing.
  - Interworking between different networks will become
    tough.
  - IP is so matured, in a way, that it can work eventually
    on any layer 2 technology (homogeneity).
  - If in future if you want to tunnel the packet from
    wireless network to/from wired network, you may have
    to face lot more issues if you are not using IP addresses
    [when compared to the Pros you are getting by not 
     converting Layer 3 (IP) <-> Layer 2 (MAC) addresses]

  Finally, naming, addressing and routing go side by side.
  If the addressing is not chosen properly then the potential
  routing issues will be unpredictable.

  Look at IP addressing history and how that impacted 
  routing protocols - subnetting, supernetting, CIDR etc 
  etc.

--
Venkata.

---

From: "Alvin C Valera Alvin" <[email-masked]>
Date: Tue, 06 Aug 2002 10:58:43 +0800

>>> "Naidu, Venkata" <[email-masked]> 08/05/02 23:44 PM >>>

More cons...

--
Venkata.  

Thanks for adding a list of cons. However, if I may, isn't it that those cons are _not_ apparently present if one is considering a single mobile ad hoc network?

Take for example subnetting. In the Internet, the advantage of subnetting is that one need not specify a next hop entry for every address. You only need to specify the network address + the mask and all packets to that address are taken cared of, saving lots of space in the routing table. 

But in a single mobile ad hoc network, does subnetting make sense? Let's suppose the network has 50 nodes. Then I create, let's say 5 subnets. Do I get the benefits as in the Internet? No, because the nodes can move. 

As for naming, well that is a totally different area. Actually, if we cannot impose some sort of hierarchy, then our naming system cannot also be hierarchical. But for one manet "domain", perhaps we can assign unique names to every host.