Subject: Re: [manet] Comments on draft-jelger

From: [email-masked]
Date: Fri, 12 Sep 2003 13:09:41 -0700

Christophe and all,

(I tried to post this message a few days ago but there was
a problem with the list server.)

I noticed that your message was not posted to the manet list
even though you copied the list. However, your original message
is included in this reply.

> Richard and all,
> 
> I think your assumtions make sense, but there is just one thing you don't 
> mention. If prefix continuity is maintained, it creates more coherence in the 
> topological (and geographical) organization of the network, i.e. "islands" of 
> sub-networks. I personaly appreciate this feature and think that most people 
> running a network would prefer something organized that something "messy".

I agree that prefix continuity has some advantages, but it also 
has some disadvantages. As discussed below, I think it is contrary 
to the consensus of previous discussions on the manet list because 
it does not allow intra-manet routing to a destination having a 
different prefix (i.e., to reach a different prefix island, the 
packet must go through a gateway).

> Now about the routing header ... I don't fully understand your point, 
> particularly why you need routing header in 2 but not in 1. Personnaly I think 
> you could get rid of the routing header in both cases, by using the link-local 
> address of the neighbor towards the gateway as the next hop for the default 
> route. But honestly I haven't really thought about that, so I may be missing 
> something.
> 
> Regards,
> 
> Christophe

(Note: This is the end of Christophe Jelger's comments. The message 
that he is replying to appears at the end of this email.)

This problem regarding the routing header was discussed in a post by 
Guillaume Chelius on 22 July 2002.  Note that a packet sent on the 
default route without a packet header does not contain any information 
about the default gateway.  (In solution 2 [see below] the default 
gateway is required to have the same prefix as the source node.)
Thus, if prefix continuity is not maintained, the source router might 
have default gateway GW1, while the next hop on the shortest path to 
GW1 might have default gateway GW2 (which could result in a loop, 
or could send the packet to the wrong gateway).

Therefore, since solution 2 requires a routing header for default
routing, and solution 3 requires prefix continuity, my opinion is
that solution 1 is the best approach, which simply finds the
shortest path to each other manet node, including each gateway,
and allows a node to select any nearby gateway (and use its prefix).

I think it is best to use a solution that does not require using 
a routing header except for special cases.  OSPF does not require 
a routing header for routing to an external network, so why should 
we require one? (Also, this allows the manet routing protocol to 
be an extension of OSPF.)

I would like to make a few more points. Your method (which uses a
DSDV-like protocol to select a gateway and maintain prefix continuity)
results in default routing that does not use the min-hop path to the
default gateway (since the min-hop path might use intermediate nodes
having a different prefix), and therefore is not consistent with a
proactive min-hop routing protocol, unless the routing protocol is
restricted to finding routes only within each prefix island.
For example, to reach a manet node in another prefix island (even if 
the other node is only 2 hops away), your method would send the packet 
to the default gateway. I think this is contrary to previous discussions 
on the manet list (e.g., if there is a manet node 2 hops away, the 
packet should be routed along a 2-hop path within the manet, even if 
the node has a different prefix).

Another point I want to make has been made before on this list.
On 22 July 2002 Guillaume Chelius wrote:

> My opinion is that we should not split the gateway advertisement mechanism from
> the routing protocol. It is the protocol responsability to propose a mechanism
> which allows a node to discover gateways and to manage routes between nodes to
> gateways.

I completely agree with this. For example, assuming that a proactive
routing protocol is used, there is no need to introduce a DSDV-like
mechanism to provide gateway information to the manet nodes, when the
routing protocol can provide this information to the manet nodes.
If prefix continuity is desired, the routing protocol can be modified to
achieve this (e.g., by computing a source tree for each known prefix
and having a node change its prefix only when it does not have
a path to a gateway with the same prefix).

Similarly, a multi-hop extension of NDP as described in
draft-wakikawa-manet-globalv6-02.txt should not be necessary since the
routing protocol can and should provide the required information to the
manet nodes in a timely, efficient manner.
(If it doesn't, then the routing protocol needs to be improved.)

The only reason to have a separate mechanism to advertise gateway
information is if one wanted to do this proactively, even though the
underlying routing protocol is reactive. In this case, I think that
either

(a) the separate mechanism would be used ONLY with the reactive protocol, or

(b) the mechanism would really be a reduced version of the proactive
    protocol, which maintains routes only to and from each gateway.

Regards,
Richard

> 
> Quoting [email-masked]:
> 
> > 
> > To Christophe and all,
> > 
> > I thought more about the solution in your draft, and the benefits 
> > of "prefix continuity".  One of the benefits of prefix continuity 
> > that I did not consider before is that it allows hop-by-hop default 
> > routing, without using a routing header to specify the gateway.
> > (This is because the default next-hop router has the same prefix 
> > and thus has a consistent default route.)
> > 
> > Also, I understand that your method minimizes the number of prefix 
> > changes, given that you want to maintain prefix continuity.  
> > (For example, it requires fewer changes than if a manet node was 
> > required to always select a nearest gateway and use its prefix.)  
> > I think it would be better to allow changing the prefix if 
> > another gateway becomes *much* closer, but my main point in
> > this message is whether or not prefix continuity should be
> > required.
> > 
> > I see three possible solutions, depending on whether prefix continuity 
> > is required, and on whether a packet routed to the internet must go 
> > thru a gateway having the same prefix as the sender.
> > I hope people will comment on which of these three solution
> > is preferable, and whether any of them (particularly the first one)
> > is unacceptable.  
> > 
> > 1. The default route always uses the nearest gateway, regardless of
> >    its prefix. Prefix continuity is not maintained.
> > 
> >   Benefit: Hop-by-hop default routing is easy (without routing header).
> >   Benefit: A manet node does not need to change its prefix to
> >     maintain prefix continuity.
> >   Drawback: Gateway prefix may be different from sender prefix,
> >     which could cause a problem with source address filtering, and 
> >     the reverse route could go thru a different gateway with a 
> >     different prefix. (Are these drawbacks acceptable?)
> > 
> > 2. The default route is required to use a gateway with the same prefix 
> >    as the sending node, even if there is a closer gateway, but prefix
> >    continuity is not maintained. 
> > 
> >   Benefit: Gateway prefix is same as sender prefix.
> >   Benefit: A manet node does not need to change its prefix to
> >     maintain prefix continuity.
> >   Drawback: A routing header (to reach gateway) is required for default 
> >     routing.  Hop-by-hop default routing is not possible.
> >    
> > 3. Same as 2, but prefix continuity is maintained.
> > 
> >   Benefit: Gateway prefix is same as sender prefix.
> >   Benefit: Hop-by-hop default routing is possible (without routing header).
> >   Drawback: A manet node may need to change its prefix to maintain
> >     prefix continuity, unlike the first two solutions.
> > 
> > In my opinion, the first solution is best if it is OK to route
> > the packet thru a gateway with a different prefix, otherwise the 
> > second solution is best if using a routing header is not considered
> > a significant drawback, otherwise the third solution is best.
> > 
> > Regards,
> > Richard
> > 
> > 
> 
> 
> 

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

---

From: "Christophe Jelger" <[email-masked]>
Date: Mon, 15 Sep 2003 16:10:21 +0200

Richard / all,

Just to quickly reply to your comment below (part of your previous email).
I'm afraid that your point is not correct, as with our proposal we don't use
the gateway information to create a default route with reactive protocols.
It is stated in the draft that we don't use a default route with reactive
protocols because it prevents the protocol from being reactive (there is a
default route!) and, as you state, it can prevent the use of shortest-path
route.

Of course, if the gateway is closer than the destination (which is in a
different subnet), then the gateway will answer first and direct (maybe
shorter) routing is not achieved. Waiting for some more time to select a
(maybe possible) best answer is a solution, but it introduces a longe delay
to establish the route, and many times the node will wait for nothing if
there is no direct route. But this problem is the same with all proposals.

For proactive the problem does not exist, as a node will have a view of the
entire adhoc topology and will use the direct route to join an adhoc node
with a different prefix (i.e. there will a /128 route for this destination
in the routing table).

Regards,
Christophe

---

From: [email-masked]
Date: Wed, 10 Sep 2003 15:56:07 -0700

Christophe and all,

This problem regarding the routing header was discussed in a post by 
Guillaume Chelius on 22 July 2002.  Note that a packet sent on the 
default route without a packet header does not contain any information 
about the default gateway.  (In method 2, the default gateway is 
required to have the same prefix as the source node.)
Thus, if prefix continuity is not maintained, the source router might 
have default gateway GW1, while the next hop on the shortest path to 
GW1 might have default gateway GW2 (which could result in a loop, 
or could send the packet to the wrong gateway).

Regards,
Richard

---

From: "HyunWook Cha" <[email-masked]>
Date: Mon, 22 Sep 2003 16:10:39 +0900

Richard and all,

I have some questions and comments.
Why are you guys thinking that only one gateway should be chosen and
used by a manet node?
If a node has "gw_info"s from multiple gateways, the node can configure
multiple global addresses with prefixes in those infos
in stateless manner as normal IPv6 does.
I think that it is necessary to consider validity of global prefixes or
gw_info as independent of  reachability of corresponding gateways
because the topology of manet is dynamically changeable. 
Please see my inline comments.
 
> packet must go through a gateway).

Manet node(sender) should sends its packets using default route (default
gateway) only when it cannot obtain host route for destination.
If destination in a different prefix island is reachable by source,
source node forwards packets using the host route.

> > >     routing.  Hop-by-hop default routing is not possible.

I want to add an alternative schem for solution 2.
How about source address based forwarding? 
Sender's upper layer chooses one source address with a prefix from a
gw_info when a session is initiated. 
When ad hoc routing module processes packets of the session, 
it firstly looks up routing table and if no host route, forwards towards
corresponding gateway according to source address.
I think this is applicable to intermediate nodes. If an intermediate
node has route entry as well as gw_info of corresponding gateway by any
means, 
it can decide how to forward packets sent to a gateway by sender. 

2.2 source address(prefix) based forwarding
Benefit: Gateway prefix is same as sender prefix.
Benefit: A manet node does not need to change its prefix to maintain
prefix continuity.
Benefit: Hop-by-hop default routing is possible (without routing
header).
Drawback: Unlikely solution 2(using routing header), all nodes including
sender on the path to corresponding gateway must have both gw_info and
route entry for the gateway. 

I think this drawback may degrade performance slightly(?) but this is
also considerable.

Regards,

Hyunwook Cha

---

From: [email-masked]
Date: Mon, 22 Sep 2003 08:08:28 -0700

Christophe,

 > default route!) and, as you state, it can prevent the use of shortest-path

That's fine for reactive routing. I was focusing on proactive routing,
where you *do* propose using the gateway information to maintain
a default route.

<snip>

 > with a different prefix (i.e. there will a /128 route for this destination

I wasn't sure whether you wanted to allow direct (intra-manet) routing
between nodes in different prefix islands, so my paragraph that you
refer to considers both cases. Here is the paragraph again:

 > proactive min-hop routing protocol, UNLESS the routing protocol is

Although it may not have been clear, the example given in the last part
of the paragraph assumes that direct routing is allowed only between
nodes in the same prefix island (the "UNLESS" clause), so of course
it is not valid if direct routing is allowed between different
prefix islands.

But the first part of the paragraph states that if direct routing is
allowed between different prefix islands (the negation of the "UNLESS"
clause), then your method of maintaining a default route for *proactive*
routing is not consistent with the routes computed by the proactive
routing protocol itself, since the proactive routing protocol will
compute the min-hop path to the gateway, even if this path includes
intermediate nodes that belong to a different prefix island.

I'm not sure whether this inconsistency will cause any serious problems,
but one way to avoid it, as I discussed in my previous email, is to
simply let the routing protocol disseminate gateway information and
maintain default routes to gateways (as in OSPF).

(If the goal is to have a common gateway discovery mechanism for both
proactive and reactive routing, I also discussed that in my previous
email, but the gist is that, since the proactive routing protocol
should already provide such a mechanism, it does not make sense to
provide another such mechanism that can be used with both proactive
and reactive routing, unless this common mechanism is already part of
the proactive routing protocol.)

Regards,
Richard

---

From: [email-masked]
Date: Mon, 22 Sep 2003 08:58:55 -0700

Hello Hyunwook,

> in stateless manner as normal IPv6 does.

I agree.  In fact, I mentioned in my post on 9/1 that
a manet node can select multiple gateways and have
multiple prefixes.  

> source node forwards packets using the host route.

I agree (and I discussed in my earlier message today).
My above comment was based on the assumption that prefix
continuity divides a manet into autonomous prefix islands/clusters
(like "areas" in OSPF), because frankly I do not see any other 
good reason to maintain prefix continuity.

> it can decide how to forward packets sent to a gateway by sender. 

Absolutely.  This way a packet with no host route is forwarded 
(hop-by-hop) to the nearest gateway having the same prefix as 
the source, without requiring a routing header.
I also considered this, but was concerned about requiring that
source-address-based forwarding be supported. 
If we can assume source-address-based forwarding is supported, and 
if it is important to route to a gateway with the same prefix as
the source, then this is the best solution.

> I think this drawback may degrade performance slightly(?) but this is

I don't think this "drawback" is a problem, since all intermediate 
nodes on the path to the gateway are closer to the gateway.
If, as I suggested in my previous email, the gateway information
is disseminated by the proactive routing protocol (as in OSPF),
then this is certainly not a drawback.  The only possible drawback 
I see is that source-address-based forwarding is required.
Is this a significant drawback?

Regards,
Richard

---

From: "HyunWook Cha" <[email-masked]>
Date: Tue, 23 Sep 2003 11:13:19 +0900

Hi Richard,

Thanks for your reply.
Please see inline comments.

> I also considered this, but was concerned about requiring 
> that source-address-based forwarding be supported. 
> if it is important to route to a gateway with the same prefix 
> as the source, then this is the best solution.
> 

Right. For source address based forwarding, additional search procedures
are needed in intermediate nodes. 
1. lookup of route table for destination (/128)
2. search corresponding gateway with prefix (/64) of source ip in
gateway cache
3. lookup of route table for the gateway found in step 2 (/128) 

In this scheme, another issue is about following case. 
After source node sends packets using default route, an intermediate
node finds host route for destination. 
Then, the node forwards using this route information directly.
I think this is ignorable in proactive routing protocols but how about
reactive protocols?
As long as sender does not find that destination is reachable directly,
this problem can continue.
I think address with MANET_PREFIX is helpful in solving this issue.
If source node intends to forward packets through a gateway, then source
ip of outgoing packets should be with global prefix and  
intermediate nodes forwards packets towards right gateway.
But, if source node intends to forward packets using host route entry,
then source ip of packets should be with MANET_PREFIX, 
intermediate nodes forwards packets using only host route entry for
destination.
If this is applied, above procedure can be reduced to 2 steps.(step 2,
step 3)

As for solution 2 with routing header, only step 1 is preformed. 

> > Drawback: Unlikely solution 2(using routing header), all nodes 
> > including sender on the path to corresponding gateway must 
> have both 
> > gw_info and route entry for the gateway.
> > 
> If, as I suggested in my previous email, the gateway 
> information is disseminated by the proactive routing protocol 
> (as in OSPF), then this is certainly not a drawback.  The 
> only possible drawback 

I agree you for the case of proactive routing protocols.
However, in reactive ones, gw_info and route entry are maintained
indepently. 
For example, lifetime of active route entry is incremented by
ACTIVE_ROUTE_LIFETIME 
whenever a packet is forwarded using this entry. This results that route
entries can remain after gw_infos are expired.
So, in case of solution 2 with routing header, sender node can recover
path failure through simple RREQ for a gateway 
which does not require gw_info. 
However, in source address based forwarding, simple RREQ is not
sufficient since all intermediate nodes are required to have
route entry as well as gw_info while sender node needs only route entry.
IMO, this can result in more control packets and packet delay.

Regards,

Hyunwook

---

From: [email-masked]
Date: Tue, 23 Sep 2003 10:17:37 -0700

Hello Hyunwook,

Please see my comments below.

> 3. lookup of route table for the gateway found in step 2 (/128) 

Step 2 can be avoided if the routing table has a default
route entry for each known prefix.  Thus, step 2 is performed 
when the route is created, not for each packet.
The following procedure is then taken for each packet:
  1. lookup of route table for destination (host route)
  2. if no host route, use the default route corresponding
     to the source address prefix.

However, I am still not sure that it is necessary for the
default gateway to have the same prefix as the source.
(If it is not necessary, then method 1 works fine.)

> I think this is ignorable in proactive routing protocols 

I would like to allow this for proactive routing, since it is
useful for limited-scope routing (such as Landmark routing).
Thus, if the source does not have a host route, it sends the
packet using the default route, or if a gateway with the same
prefix as the destination is known, it sends the packet
toward that gateway. When the packet gets closer to the gateway, 
an intermediate node might have a source route, which 
should then be used. 

> but how about reactive protocols?

> this problem can continue.

I assume you are saying that a routing loop can occur with
reactive routing. (See my comments at the end of this message
regarding this possibility.)

> intermediate nodes forwards packets towards right gateway.

This would not allow the solution I suggest above, which
supports limited-scope routing.
Also, I prefer to avoid requiring the use of a MANET_PREFIX,
since I would rather have a solution that applies more generally 
(not just to manets).

> > > have both gw_info and route entry for the gateway.
> > > 
> > > I think this drawback may degrade performance slightly(?) 
> > > but this is also considerable.
> > 

With the forwarding procedure I described above, where there
is a default route entry for each known prefix, the 
lifetime of a default route can also be incremented by
ACTIVE_ROUTE_LIFETIME, so maybe this fixes the problem.
(Let me know if I am mistaken.)

Regards,
Richard

---

From: "HyunWook Cha" <[email-masked]>
Date: Wed, 24 Sep 2003 11:17:39 +0900

Hi Richard,
Thanks for your comments.
Please see inline comments.

> > > > Sender's upper layer chooses one source address with a 
> prefix from 
> > > > a gw_info when a session is initiated. When ad hoc 
> routing module 
> > > > processes packets of the session, it firstly looks up routing 
> > > > table and if no host route,
> > > forwards towards
> > > > I think this is applicable to intermediate nodes. If an 
> > > > intermediate node has route entry as well as gw_info of 
> > > > corresponding
> > > gateway by any
> > > > means,
> > Right. For source address based forwarding, additional search 
> > procedures are needed in intermediate nodes. 1. lookup of 
> route table 
> > for destination (/128) 2. search corresponding gateway with prefix 
> > (/64) of source ip in gateway cache

Ok. You mean two route entries (host route and prefix route) per one
gateway are created and managed. 

> default gateway to have the same prefix as the source. (If it 
> is not necessary, then method 1 works fine.)
> 

IMO, environment where multiple gateways are available is similar to
that considered by Multi6 working group.
Multi6 falks think that ingress filtering should be avoided (C. Huitema
names site exit issue).
What is your opinion?

> an intermediate node might have a source route, which 

Limited-scope routing seems to potato routing. I think that this idea
aims to make proactive routing protocols more scalable. 

> > As long as sender does not find that destination is reachable 
> > directly, this problem can continue.
> 

No, let me explain more detail.
Let's assume that destination node with global ip is inside different
partion from one where source node resides.
Since sender can not find host route and destination address is global,
it sends packets using default route.
During the session, two partitions may be connected and an intermediate
node on the path from sender to the gateway may have
host route information for destination whether it is active or reverse.
As for proactive routing, not to mention limited scope routing, sender
will get host route in little time.      
However, this can not be guranteed in reacive ones.

> 
> > I think address with MANET_PREFIX is helpful in solving 
> this issue. If 
> > source node intends to forward packets through a gateway, 
> then source 
> supports limited-scope routing. Also, I prefer to avoid 
> requiring the use of a MANET_PREFIX, since I would rather 
> have a solution that applies more generally 
> (not just to manets).

Do you think that address with MANET_PREFIX can not be used as source
ip?
Manet nodes which can not configure their global IPs because no gateways
are reachable 
can communicate each other. In this case, MANET_PREFIX address is only
vailable.
Thus, I think MANET_PREFIX address should not be deleted although global
IPs can be configured.
I think MANET_PREFIX can be useful to address above issue as I mentioned
in previous comment.
IMO, we should investigate MANET specific stuffs before we think about
more general solutions.

> > then source ip of packets should be with MANET_PREFIX, intermediate 
> > nodes forwards packets using only host route entry for destination.
> However, in 
> > reactive ones, gw_info and route entry are maintained indepently.
> ACTIVE_ROUTE_LIFETIME, so maybe this fixes the problem. (Let 
> me know if I am mistaken.)
> 

You point the cause of this issue.
While lifetime of a default route and host route of corresponding
gateway are incremented as packets are forwarded using the default
route,
gw_info lifetime is not. So, host route of gateway and corresponding
default route can remain after gw_info for the gateway is expired.  This
holds whether node is sender or intermediate one. 
In solution 2 with routing header, sender only needs valid host route
for gateway to forward packets using default route 
as long as gw_info is valid. So, while gw_info does not need to be
refreshed, sender does route discovery if necessary.
However, as I mentioned before, in source address based forwarding,
sender's route discovery requires that only intermediate nodes which
have 
valid gw_info or gateway itself should answer with route information as
well as gw_info for requested gateway, whether gw_info needs to be
refreshed or not.
I am not sure how this can affect performance. I think two approaches
should be compared through simulation work.
Personally, I have a preference with source address based forwarding
strategy since routing header hides actual destination ip not to mention
security issue.
Do you have any comments?