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

From: Pekka Pääkkönen <[email-masked]>
Date: Tue, 06 Jan 2004 15:40:45 +0200

At 16:55 2.1.2004 +0900, HyunWook Cha wrote:
>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.

The I-flag is set only in the prefix discovery phase. The route refresh related
messages (RREQ, RREP) are sent with I-flag set to zero as can be seen in 
figure 6
of the draft.

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

If the new path is broken (next-hop2) and the old one is not broken (next-hop1)
then the old next-hop is used as described in the draft. Am I missing 
something
here?

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

Could you point out what "maximized address stability" means?
How does the use of routing header enable optimal routing compared to
next-hop routing?

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

If an IPv6-node is equipped with MANET-routing protocol, it may use its
configured global address or site-local address for communication with
the other MANET-nodes.

If a MIPv6-node is enhanced with a MANET-routing protocol,
then either the home address or COA is used as a MANET-address for
communication depending on whether or not the node is at home.

There shouldn't be a problem?

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

Do you mean TTL in the RREQ originally sent by the source and forwarded by the
intermediate nodes? And then some intermediate node notices that the TTL is 
bigger than threshold
and sends a RREP to the source?

I guess application layer hints could be used, but cannot be relied on, and 
because of
it there should exist a solution for destination determination at the 
network layer.

Pekka

>Regards,
>HyunWook

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

---

From: "HyunWook Cha" <[email-masked]>
Date: Wed, 7 Jan 2004 10:10:47 +0900

Hello, Pekka.

Please see my comments below.

> The I-flag is set only in the prefix discovery phase. The 
> route refresh related messages (RREQ, RREP) are sent with 
> I-flag set to zero as can be seen in 
> figure 6
> of the draft.
> 

Then, how can you update default route entry? Normal RREP is not
sufficient.

> If the new path is broken (next-hop2) and the old one is not 
> broken (next-hop1) then the old next-hop is used as described 
> in the draft. Am I missing 
> something
> here?
> 

At this time, I want to ask another question related to this issue. In
your draft, forwarding algorithm in intermediate nodes is not defined.
In other words, how should intermediate nodes deal with received
packets? To do right thing, intermediate nodes should know that a
received packet was sent using host route entry or default route entry
by sender. 

Then, periodic RREQ message should be broadcast if new path is broken
and route entry for the gw is invalid, although old path(=default route)
is still valid. Because default route should be only used to the
communication with a node regarded as an Internet node. 

Could you explain?

> How does the use of routing header enable optimal routing 
> compared to next-hop routing?
> 
> 

What I mean by "address stability" is how long an address can be used? I
refered to Christophe(an author of gateway autoconf draft)'s notation.
IMO, your idea has same effect with routing header since a configured
address can be used as long as the gw is reachable.

Actually optimal is wrong word. "Route consistency with routing
protocol" is more accurate. As I mentioned before, with the use of
routing header, intermediate nodes do not have to maintain default route
which may cause "route inconsistency with routing protocol".

> If an IPv6-node is equipped with MANET-routing protocol, it 
> may use its configured global address or site-local address 
> for communication with the other MANET-nodes.
> 
> then either the home address or COA is used as a 
> MANET-address for communication depending on whether or not 
> the node is at home.
> 

At recent discussions(between C.Perkins and Manish) related to Internet
connectivity, I agree C.Perkins. We should consider that Internet
connectivity be added on the original(basic) assumption and
functionality of manet routing protocols. In other words, a node who is
equipped with Internet connectivity and wants to communicate with
Internet nodes should do route discovery for any global dest address.
Because a node can configure a static global address which can be
diffent with prefixes advertised by GWs. In this sense, it is desirable
that a manet node communicates directly with a IPv6/MIPv6 node which is
inside the manet.     

> Do you mean TTL in the RREQ originally sent by the source and 
> forwarded by the intermediate nodes? And then some 
> intermediate node notices that the TTL is 
> bigger than threshold

Nope. I think that parameter NETWORK_DIAMETER in sender is sufficient
for threshold value. (The failure of route discovery) I do not want to
add any overhead. 

> it there should exist a solution for destination determination at the 

Right. Applicability is restricted to MANET specific applications.
Distributed cache infos(route entry in stage 4) can be used to reply
with RREP-int_node messages to RREQs. More room to be thought.   

HyunWook

---

From: Pekka =?iso-8859-1?Q?P��kk�nen?= <[email-masked]>
Date: Fri, 09 Jan 2004 16:47:41 +0200

>Then, how can you update default route entry? Normal RREP is not

Thanks for the correction. There is an error in the draft. The I-flag is 
set in both
phases. The bad side with this solution is route inconsistency, right?

>communication with a node regarded as an Internet node.

The intermediate nodes forward packets based on the routing table entries:

If the destination is already in the routing table, it is sent based on the 
entry.
If no routing table entry for the destination exists, then
   If the destination's IPv6 prefix is the MANET's IPv6 prefix, route 
discovery is used.
   else
   the packet is sent normally i.e. the default route is used.

How could an intermediate node determine if the previous node forwarded the 
packet using
the default route entry or the host entry?

>address can be used as long as the gw is reachable.

I agree. Don't both approaches require the refreshing of the gw-info,
which is used to update the lifetime of the IPv6 address(es)?

>which may cause "route inconsistency with routing protocol".

Got it.

>that a manet node communicates directly with a IPv6/MIPv6 node which is

OK, I see your point. Some node inside the MANET might have
configured an IPv6 address from a different IPv6 prefix than the
what is advertised in the gw-info, and also uses the MANET-routing protocol.
And route discovery should be used in such situations.

But if the node doesn't have MANET-capabilities (dest), and the other node 
does (source),
then the dest could not answer to the initial RREQs sent by the source.
Because of this the packets in the draft were routed via the AR between the 
peers.
If the peers would be in the same link, then direct communication could be 
established
by using the link-local addresses?

>for threshold value. (The failure of route discovery) I do not want to

OK.

---

From: "HyunWook Cha" <[email-masked]>
Date: Mon, 12 Jan 2004 11:47:52 +0900

Hello, Pekka.

> -----Original Message-----
> From: Pekka P狎kk?en [mailto:[email-masked]]
> Sent: Friday, January 09, 2004 11:48 PM
> To: [email-masked]; [email-masked]
> Cc: 'autonet'
> Subject: RE: Comments on the
> draft-paakkonen-addressing-htr-manet-00.txt
>
>
>
> > > The I-flag is set only in the prefix discovery phase. The route
> > > refresh related messages (RREQ, RREP) are sent with I-flag set to
> > > zero as can be seen in figure 6
> > > of the draft.
> > >
> >

You are welcome. :-)

> the default route entry or the host entry?

Please think about two scenarios. If sender node obtains host route
entry for dest by performing route discovery and sends its packets using
the route entry and an intermediate node which has route entry for dest
invalidated by RERR receives the packets(this is possible because
broadcasting RERR is not reliable), packets are forwarded to the
Internet using default route although RERR should be generated to notify
to sender that path to dest was broken. Then, if dest is inside MANET
and globally reachable, it is ok but packets may be forwarded through
Internet until sender is notified by another RERR and reinitiates route
discovery. If dest is inside MANET and globally unreachable, sender will
receive ICMP dest unreachable but how can it deal with this error
message corretly? Reinitiates route discovery after invalidating the
route entry?

Another case is the reverse one. If sender node does not obtain host
route entry for dest by performing route discovery and sends its packets
using the default entry and an intermediate node which has valid route
entry for dest, it is desirable that wrong information about dest in
sender be corrected through additional signalling. => "Route
optimization"  (refered to an ANS presentation)

Wakikawa's draft does not have to consider above issues because it get
rid of using default route with routing header. However, forwarding with
default route entry which we are discussing should resolve this problem.

> which is used to update the lifetime of the IPv6 address(es)?

Right.

> by using the link-local addresses?

Here are my thoughts about the determination and forwarding of default
routing. Global address itself does not mean that it can be globally
reachable from MANET point of view. Due to the dynamics of MANET, the
current assumption(knowledge) about the location of the dest should be
changeable(adaptable) according to the reachability of the dest rather
than address itself as reactive routing protocols do. ("Reachability"
means that dest has MANET routing functionality and is reachable via
multi-hops.)

My point is that your algorithm restrict the adaptability by relying on
address itself. More specifically, route optimization can not be done in
your algorithm when nodes with different global prefix from different
GWs want to communicate each other. Or the communication itself is not
allowed since sender forwards its packets toward Internet for dest with
unknown global prefix although multi-hop paths are available. 

As for the above case mentioned by you, it is sufficient that sender
node knows that dest is not reachable in local MANET and select default
route for dest from now on. This change of state(knowledge) can be done
through route discovery. Do you concern "delay" taken by route
discovery? The algorithm suggested by me is helpful.

Regards,

HyunWook