Subject: [manet] draft submission

From: Pekka =?iso-8859-1?Q?Pääkkönen?= <[email-masked]>
Date: Tue, 16 Dec 2003 08:38:52 +0200

Hi all,

I have submitted an individual draft, which focuses on IPv6
addressing in a heterogeneous MANET-network.
Any comments on the subject are welcome.

Pekka Pääkkönen

draft URL:
http://www.ietf.org/internet-drafts/draft-paakkonen-addressing-htr-manet-00.txt

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

---

From: "HyunWook Cha" <[email-masked]>
Date: Sat, 20 Dec 2003 12:27:27 +0900

Hello, paakkonnen.

I read your draft with much interest. And I am glad to share my idea
about the Internet connectivity for MANETs. 
I have several comments as follow. 

5.2. Global connectivity & Appendix B: Global connectivy via next-hop
routing
I agree that recursive lookups of kernel routing table is impossible in
some OS including LINUX(Mayby configuration itself may not be allowed).
However, your solution for this problem is not perfect. In figure 6, as
a result of prefix discovery, AODV-node has 3 rt entries: AR-> Int.node,
::/0 -> Int.node, Int.node->eth0. As you can see, the node maintains rt
entries for default route and actual gateway independently. So, it is
possible that only host route for the gateway can be updated through
RREP which was sent to reply RREQ from other node so that next hop of
the rt entry for the gateway is differnt from that of the rt entry for
default route. -> route inconsistency between default route and actual
gateway. This issue can cause that path to the gateway via default route
may fail while the path to the gateway via host route is still valid. At
this moment, you can not swith next hop of default route to that of host
route for the gateway because you can not guarantee that the next hop of
host route have default route entry. IMO, we can not force only next hop
routing(fowarding) in on-demand routing protocols by this reason. In
other words, some complementary processing is need.

Next issue is about consideration of multiple gateways. Your idea does
not work in this situation since intermediate nodes can choose different
gatways for default routes from sender node. This can lead the ingress
filtering. 

Well, I think that the use of routing header which is preferred to next
hop forwarding in R.Wakikawa's I-D is one solution. Because we do not
have to concern frequent inconsistent route information for default
route and actual gateway as well as ingress filtering. Also, all
intermediate nodes do not need to have default route entry, and only
sender node does. IMO, kernel routing table issue can be avoided if
routing header can be inserted and pre-processing in which dst ip in
IPv6 is swapped with gateway ip in routing header can be done in
LOCAL_IN netfilter hooking point. (the feasibility is not sure, any
comments?). 

In addition, I want to suggest source prefix(address) based default
routing(forwarding). Please refer to the discusstion with Richard Ogier.
http://www1.ietf.org/mail-archive/working-groups/manet/current/msg02799.
html. With this approach, ingress filtering can be avoided in natural
manner. However, route inconsistency issue should be resolved because
default rt entry is not needed and host rt enry in intermediate nodes
can be updated irrespective of gatway discovery of sender node. In my
scheme,  tunneling and routing header are used to forward packets after
this route inconsistence occurred. And, for fast recovery, unicast
GW_SOL message is forwarded along host route for the gateway and the
route inconsistency issue can be fixed by GW_ADV replied from the
gateway. When this procedure is done succefully, routing header and
tunneling are not used any more. I know that a lot of issue exist in
this scheme.: Implementation, additional processing overhead,
determination of which should be used among host route and default route
to forward a packet. I have ns-2 implementation of this approach and the
plan to write a I-D in near future. Any comments?

5.3 Global vs. site-local addresses & 6.1 AODV communication algorithm

According your algorithm, it is not allowed for manet nodes with
different global prefixes from different ARs to communicate each other
directly although they are reachable in a MANET. In further, it is not
allowed a manet node to communicate with a IPv6/MIPv6-node directly when
HoA of the IPv6/MIPv6-node is involved in this communiation even though
they are also reachable. Is this desirable? I do not think so. My
suggestion is as follows. 

1. If (dest is a site-local addres)
	execute route discovery. 
2. if (prefix of dest is global)
	send packets via the default router in parallel with the
excution of route discovery.

IMO, destination ip does not give sufficient hint to distinguish whether
dest node resides in the MANET or not. IPv6-node with same prefix as
sender node can not reply RREQ though it is reachable in the MANET.
Also, HoA of a IPv6/MIPv6-node can be reachable in the MANET. 

In order to implement this scheme, rt entry for AODV is managed in four
states:

1. NoHints - may be reachable in local MANET or outside the MANET. To do
- send packets via the default router in parallel with the excution of
route discovery.
2. ValidHostRoute - a node has valid host route. To do - send packets
via host route. 
3. NotValidHostRoute -  a node has invalid host route. To do - execute
route discovery. packets are enqueued.
4. InternetNode - a node consider dest as an Internet node outside the
MANET. To do - send packets via the default router.

For a given communication with destination with global ip, state
transitions can be different according scenarios.

1->2 : the success of route discovery 
1->4 : ttl used for route discovery is above threshold or on receiving a
packet from the destination.(I assume that the packet should be replied
to a packet sent by sender)
(2->)3->2 : normal case
(2->)3->4 : ttl used for route discovery is above threshold
2 or 3 or 4 -> 1 : timer expired.

I welcome any comments. As I said above, I will write up my I-D
including source address based forwarding and above algorithm. Since any
noticeable consensus for this issue does not exist in MANET wg, I think
that we had better converge different approaches and analyze to give
valuable information for further design. Are there any room to share
research results and achieve improvements in this subject between us? 

Regards,

HyunWook Cha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Pekka P?kk?en
> Sent: Tuesday, December 16, 2003 3:39 PM
> To: [email-masked]; [email-masked]
> Subject: [manet] draft submission
> 
> 
> 
> Hi all,
> 
> addressing in a heterogeneous MANET-network. Any comments on 
> the subject are welcome.
> 
> Pekka Pääkkönen
> 
> draft URL: 
http://www.ietf.org/internet-drafts/draft-paakkonen-addressing-htr-manet
-00.txt

---

From: Pekka =?iso-8859-1?Q?Pääkkönen?= <[email-masked]>
Date: Wed, 31 Dec 2003 10:19:14 +0200

>I have several comments as follow.

Thanks for the comments.

>other words, some complementary processing is need.

Let me try to understand how the entries become inconsistent:
Once the MANET-node has performed the global connectivity procedures
the routing tables are configured as in figure 6. The AODV-node maintains 
reachability
to the gateway with periodic updates (RREQ, RREP) and keeps the entries for
the default gateway and AR based on the updates. If some other node such as
AODV-node2 executes route discovery for AR via the intermediate node, the 
intermediate
node could update a different next-hop for the AR than already exists for 
the default route, right?
(AR-> next-hop2; ::/0 -> next-hop1)

When the periodic updates would again be performed by the AODV-node, the 
entries for the AR and
default router at the intermediate nodes would be updated.

>gatways for default routes from sender node. This can lead the ingress

True. It should also be taken into account.

>LOCAL_IN netfilter hooking point. (the feasibility is not sure, any

This is the other choise of global communication. It has routing header
overhead in the form of additional processing and space in every
IPv6 packet? Doesn't the source have to know in this case whether
or not the destination is in the MANET or not? If not, insert
a routing header. Otherwise send the packet normally. Could failure in route
discovery provide this information? I haven't tested this alternative.

>plan to write a I-D in near future. Any comments?

So the benefit of using the source address based routing is support for
ingress filtering. I guess the intermediate nodes would perform ingress
filtering in the form of source based routing (if no gateway prefix matches
the source prefix => discard packet?)? Would this solution support
also multiple gateways? How do the intermediate nodes maintain the
gateway information, based on which source based routing is performed?
Please go ahead and write a more detailed draft. It is easier to give 
comments based on
it.

>directly although they are reachable in a MANET.

True. Packets between nodes in different MANETs would flow via the ARs if 
global
addresses are used. But site-local addresses could be used for direct 
communication
if the MANETs overlap.

>In further, it is not
>they are also reachable. Is this desirable? I do not think so.

The communication between a MANET-node and an IPv6-node goes via the AR, 
because
the IPv6-node does not understand MANET related messages. The local 
IPv6/MIPv6 nodes
are treated as the global Internet nodes, because they have a different 
IPv6 prefix from the one
received from the AR.
Could you point out for example in a picture how a MANET-node could not 
communicate
with an IPv6/MIPv6-node via its HA?

>  My

I guess you point out that the IPv6 prefix should not solely be used to 
determine
whether or not the destination is in the same MANET, and the algorithm 
could be
improved to support that notion.
Can you assume that the destination answers to the packets send by the 
sender (1->4)?
This does not always happen (consider UDP traffic).

>research results and achieve improvements in this subject between us?

Sure. Please write the draft and it will be easier to give comments.

Pekka