Subject: [manet] RE: Comments on the draft-paakkonen-addressing-htr-manet-00.txt

From: "HyunWook Cha" <[email-masked]>
Date: Fri, 2 Jan 2004 17:24:16 +0900

Hello, Pekka.

Thanks for the reply which corrects my comments. Please see comments
below.

> 
> 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.
> 

I see. In your draft, same type of RREP which is with I-flag set is
used for two phases(prefix discovery, route refresh). So, in above
scenario, this issue can be resolved by sending unicast RREQ becauase
the route entry for AR is still valid though default route is not
available. 

How about the other case where the new path for AR is broken before
RREQ message is issued? In this case, the node should broadcast RREQ
though it does have valid  route entry for the default router which can
be used as one for the AR. I think that this is inefficient behavior
which should be avoided since we can not guarantee that this is only
rare case which is negligible under reactive routing protocols.

> >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.
> 
> True. It should also be taken into account.
> 
> >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?).
> 
> 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.
> 

Right. However, the use of routing header has several valuable
advantages including maximized address stability and use of optimal
route. In addition, it works well with multiple gateways since routing
header leads packets to the right gateway. As many drafts including
yours point out, implementation of this requires kernel patch as MIPL
of HUT does for type 2 routing header. 

I think that alternative designs should avoid the use of routing header
while keeping all advantages mentioned above and requires additional
processing overhead as least as possible. 
 
> 
> 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.
> 

Ok. I will do that. 

> 
> >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.
> 
> 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?
> 

I am sorry. I misunderstood that an IPv6/MIPv6-node is equipped with a
MANET routing protocol. Anyway, do you consider this case which I
intend to point?

> >  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 
> >1->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 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).
> 

Right. In case of UDP, the transition (1->4) occurs when ttl used for
route discovery is above threshold. To reduce unnecessary RREQs during
state 1, cache or route information of local host or other nodes can be
helful. In further, user or application's input(hint) via extened
socket option can be helpful for determination of whether a destination
is inside the MANET or not. 

Regards,

HyunWook

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