Subject: [manet] Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.txt

From: "HyunWook Cha" <[email-masked]>
Date: Tue, 2 Mar 2004 16:07:17 +0900

Hello, all.

After my presentation is finished, I got two comments. Although Paal's
comments which are more technical seem to be resolved(I guess. If wrong,
please correct me, Paal), I think that I must tell what is different
with existing solutions for MANET Internet connectivity in my draft. 

As I mentioned at my presentation, my draft consists of two component.
Route determination algorithm and Forwarding algorithm. As you know,
these are critical parts in this area(Int. Connectivity) and all
existing solutions address with their own way. 

Firstly, route optimization is not mentioned at existing drafts
referenced by mine (If wrong, please correct me.) 

As for proposed forwarding algorithm, forwarding using default route can
be done for packets without routing header. I.E, after look up of
routing table with destination address fails, forwarding decision is
based on source global address of the packet. That is, gw_info list is
searched with source prefix. If matched gw_info is found, the packet is
forwarded through host route entry for the gw advertising the prefix.
Thus, multiple addresses from multiple gateways can be configured in a
node and intermediate nodes can forward packets without routing header
only if gateway info list is maintained in the node.

I request valuable comments on my draft from authors of previous drafts
including C. Perkins, Wakikawa, C. Jelger, Pekka. Personally I also
believe that this area is very important and it is time to make
progress. How about requirement document or merged solution document?
Please let me know what is in your mind. Whoever is interested in this
topic may be welcomed in this thread.

Kindly Regards,

HyunWook Cha

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

---

From: "Pedro M. Ruiz" <[email-masked]>
Date: Tue, 02 Mar 2004 09:23:45 +0100

Dear HyunWook,

Please find my comments inline...

>progress. How about requirement document or merged solution document?
I completely agree with you on the need for a coordinated effort on 
this. I submitted recently such kind of requirement draft for IP 
Multicast internet conectivity 
(http://www.ietf.org/internet-drafts/draft-ruiz-manet-mcast-gw-reqs-00.txt). 
Some  of these requirements may also apply for the Internet connectivity 
area. So, I think that trying to define such kind of requirement 
document for Internet connectivity is interesting.

>topic may be welcomed in this thread.
My personal view is that currently we have different proposed solutions 
but it is not possible to decide which one is better because we have not 
settled down any requirements. I think at this point what we need is to 
prepare a requirement document stating the agreed view of the group. 
After that, we can then match different solutions againts the 
requirements and try to get an unified solution. If you are interested 
in producing such a requiment document, I'd be happy to contribute. 
Let's move forward!!

Best Regards,

Pedrom

---

From: Christophe Jelger <[email-masked]>
Date: Tue, 02 Mar 2004 10:29:25 +0100

Dear all,

I could not go to the IETF but I will have a look at all the latest 
proposals (HyunWook Cha and Jaehoon Jeong) and will give some coments as 
soon as possible. I agree with HyunWook Cha that it we could collaborate 
to write a requirement draft.

Regards,
Christophe

---

From: "Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 3 Mar 2004 10:48:51 +0900

SGkgSHl1bldvb2ssDQoNCkkgd291bGQgbGlrZSB0byBqb2luIGRyYWZ0aW5nIGEgcmVxdWlyZW1lbnRzIGRyYWZ0IGZvciBJbnRlcm5ldCBDb25uZWN0aXZpdHkuDQpNeSBvbmUgY29tbWVudCAgaXMgdGhhdCB3ZSBuZWVkIHRvIGRyYXcgb3V0IHRoZSByZXF1aXJlbWVudHMgZm9yIGJvdGggSVB2NCBhbmQgSVB2Niwgbm90IG9ubHkgSVB2Ni4NCldoYXQgYWJvdXQgbXkgc3VnZ2VzdGlvbj8NCg0KUGF1bA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkh5dW5Xb29rIENoYSIgPGphZnlAZXRyaS5yZS5rcj4NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDAyLCAyMDA0IDQ6MDcgUE0NCj4gDQo+IEhlbGxvLCBhbGwuDQo+IA0KPiBBZnRlciBteSBwcmVzZW50YXRpb24gaXMgZmluaXNoZWQsIEkgZ290IHR3byBjb21tZW50cy4gQWx0aG91Z2ggUGFhbCdzDQo+IGNvbW1lbnRzIHdoaWNoIGFyZSBtb3JlIHRlY2huaWNhbCBzZWVtIHRvIGJlIHJlc29sdmVkKEkgZ3Vlc3MuIElmIHdyb25nLA0KPiBwbGVhc2UgY29ycmVjdCBtZSwgUGFhbCksIEkgdGhpbmsgdGhhdCBJIG11c3QgdGVsbCB3aGF0IGlzIGRpZmZlcmVudA0KPiB3aXRoIGV4aXN0aW5nIHNvbHV0aW9ucyBmb3IgTUFORVQgSW50ZXJuZXQgY29ubmVjdGl2aXR5IGluIG15IGRyYWZ0LiANCj4gDQo+IEFzIEkgbWVudGlvbmVkIGF0IG15IHByZXNlbnRhdGlvbiwgbXkgZHJhZnQgY29uc2lzdHMgb2YgdHdvIGNvbXBvbmVudC4NCj4gUm91dGUgZGV0ZXJtaW5hdGlvbiBhbGdvcml0aG0gYW5kIEZvcndhcmRpbmcgYWxnb3JpdGhtLiBBcyB5b3Uga25vdywNCj4gdGhlc2UgYXJlIGNyaXRpY2FsIHBhcnRzIGluIHRoaXMgYXJlYShJbnQuIENvbm5lY3Rpdml0eSkgYW5kIGFsbA0KPiBleGlzdGluZyBzb2x1dGlvbnMgYWRkcmVzcyB3aXRoIHRoZWlyIG93biB3YXkuIA0KPiANCj4gRmlyc3RseSwgcm91dGUgb3B0aW1pemF0aW9uIGlzIG5vdCBtZW50aW9uZWQgYXQgZXhpc3RpbmcgZHJhZnRzDQo+IHJlZmVyZW5jZWQgYnkgbWluZSAoSWYgd3JvbmcsIHBsZWFzZSBjb3JyZWN0IG1lLikgDQo+IA0KPiBBcyBmb3IgcHJvcG9zZWQgZm9yd2FyZGluZyBhbGdvcml0aG0sIGZvcndhcmRpbmcgdXNpbmcgZGVmYXVsdCByb3V0ZSBjYW4NCj4gYmUgZG9uZSBmb3IgcGFja2V0cyB3aXRob3V0IHJvdXRpbmcgaGVhZGVyLiBJLkUsIGFmdGVyIGxvb2sgdXAgb2YNCj4gcm91dGluZyB0YWJsZSB3aXRoIGRlc3RpbmF0aW9uIGFkZHJlc3MgZmFpbHMsIGZvcndhcmRpbmcgZGVjaXNpb24gaXMNCj4gYmFzZWQgb24gc291cmNlIGdsb2JhbCBhZGRyZXNzIG9mIHRoZSBwYWNrZXQuIFRoYXQgaXMsIGd3X2luZm8gbGlzdCBpcw0KPiBzZWFyY2hlZCB3aXRoIHNvdXJjZSBwcmVmaXguIElmIG1hdGNoZWQgZ3dfaW5mbyBpcyBmb3VuZCwgdGhlIHBhY2tldCBpcw0KPiBmb3J3YXJkZWQgdGhyb3VnaCBob3N0IHJvdXRlIGVudHJ5IGZvciB0aGUgZ3cgYWR2ZXJ0aXNpbmcgdGhlIHByZWZpeC4NCj4gVGh1cywgbXVsdGlwbGUgYWRkcmVzc2VzIGZyb20gbXVsdGlwbGUgZ2F0ZXdheXMgY2FuIGJlIGNvbmZpZ3VyZWQgaW4gYQ0KPiBub2RlIGFuZCBpbnRlcm1lZGlhdGUgbm9kZXMgY2FuIGZvcndhcmQgcGFja2V0cyB3aXRob3V0IHJvdXRpbmcgaGVhZGVyDQo+IG9ubHkgaWYgZ2F0ZXdheSBpbmZvIGxpc3QgaXMgbWFpbnRhaW5lZCBpbiB0aGUgbm9kZS4NCj4gDQo+IEkgcmVxdWVzdCB2YWx1YWJsZSBjb21tZW50cyBvbiBteSBkcmFmdCBmcm9tIGF1dGhvcnMgb2YgcHJldmlvdXMgZHJhZnRzDQo+IGluY2x1ZGluZyBDLiBQZXJraW5zLCBXYWtpa2F3YSwgQy4gSmVsZ2VyLCBQZWtrYS4gUGVyc29uYWxseSBJIGFsc28NCj4gYmVsaWV2ZSB0aGF0IHRoaXMgYXJlYSBpcyB2ZXJ5IGltcG9ydGFudCBhbmQgaXQgaXMgdGltZSB0byBtYWtlDQo+IHByb2dyZXNzLiBIb3cgYWJvdXQgcmVxdWlyZW1lbnQgZG9jdW1lbnQgb3IgbWVyZ2VkIHNvbHV0aW9uIGRvY3VtZW50Pw0KPiBQbGVhc2UgbGV0IG1lIGtub3cgd2hhdCBpcyBpbiB5b3VyIG1pbmQuIFdob2V2ZXIgaXMgaW50ZXJlc3RlZCBpbiB0aGlzDQo+IHRvcGljIG1heSBiZSB3ZWxjb21lZCBpbiB0aGlzIHRocmVhZC4NCj4gDQo+IEtpbmRseSBSZWdhcmRzLA0KPiANCj4gSHl1bldvb2sgQ2hhDQo+ICAgIA0KPiANCj4g_______________________________________________manet mailing [email-masked]://www1.ietf.org/mailman/listinfo/manet

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 03 Mar 2004 15:58:37 +0900

I think the first step is MANET WG should make decision whether the WG
includes internet connectivity stuff in manet charter or
not. Otherwise, many similar drafts are submitted without any progress
at IETF. 

BTW, the statement to our global6 is wrong in
draft-cha-manet-aodv-internet.

You said
[1 global6] which do not use next hop forwarding and require that a
sender specifies a gateway in routing header.

In appendix D. of global6, we describe AODV operations and it said
"When the node sends packets to the internet, it MAY use any of the two
methods specified in section 7.1 and appendix C."
  Section7.1 is for next-hop forwarding.
  Appendix C is for the routing w/routing header

ryuji

At Tue, 2 Mar 2004 16:07:17 +0900,

---

From: "HyunWook Cha" <[email-masked]>
Date: Wed, 3 Mar 2004 17:02:28 +0900

Hello,  ryuji.

First of all, I am glad to hear your opinion and comment. 
Definately I agree with you. However, I think that it is valuable job to
make a requirement document which is agreed by the whole wg and can be
utilized as evaluation metrics for existing solutions and one guideline
for upcoming solution designs whether this topic will be accepted as a
wg item in near future or not. I know that several MANETers interested
in this topic agree with me. Do you think that it is still early to make
a requirement document reflecting valuable thoughts related to this
topic?

Although I admit that I was inspired and motivated by your draft, I do
not think that your draft does address all related issues and propose
all possilbe solutions. If you are interested in my suggestion, we can
have good chance to share ideas and make productive work in this topic.

As for your comment on my draft, please take it easy.

[The draft says]
one including [1 globalv6], [2], [3] which use next hop forwarding for
default routes and the other including [1 globalv6] which do not use
next hop forwarding and require that a sender specifies a gateway in
routing header.  

If you have any other comments, please let me know.

Regards,

HyunWook Cha
 
> -----Original Message-----
> From: Ryuji Wakikawa [mailto:[email-masked]] 
> Sent: Wednesday, March 03, 2004 3:59 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [manet] Request of Comments on the i-d 
> ietf-cha-manet-aodv-internet-00.txt
> 
> 
> 
> 
> I think the first step is MANET WG should make decision 
> whether the WG includes internet connectivity stuff in manet 
> charter or not. Otherwise, many similar drafts are submitted 
> without any progress at IETF. 
> 
> [1 global6] which do not use next hop forwarding and require 
> that a sender specifies a gateway in routing header.
> 
> In appendix D. of global6, we describe AODV operations and it 
> said "When the node sends packets to the internet, it MAY use 
> any of the two methods specified in section 7.1 and appendix C."
> > comments which are more technical seem to be resolved(I guess. If 
> > wrong, please correct me, Paal), I think that I must tell what is 
> > different with existing solutions for MANET Internet 
> connectivity in 
> > my draft.
> > 
> > As for proposed forwarding algorithm, forwarding using 
> default route 
> > can be done for packets without routing header. I.E, after 
> look up of 
> > searched with source prefix. If matched gw_info is found, 
> the packet 
> > is forwarded through host route entry for the gw advertising the 
> > prefix. Thus, multiple addresses from multiple gateways can be 
> > configured in a node and intermediate nodes can forward packets 
> > without routing header only if gateway info list is 
> maintained in the 
> > node.
> > 
> > I request valuable comments on my draft from authors of previous 
> > drafts including C. Perkins, Wakikawa, C. Jelger, Pekka. 
> Personally I 
> > also believe that this area is very important and it is 
> time to make

---

From: Christophe Jelger <[email-masked]>
Date: Wed, 03 Mar 2004 11:48:23 +0100

Hi Paal / all,

Of course as one of the authors of a solution that uses default route I 
don't agree with your statements. ;-)

In our draft each MANET node knows which gateway it uses, and (in the 
steady-state) it knows that all nodes on the "default route" path use 
the same gateway. With our solution gateways don't announce routes, they 
just announce prefixes. If two gateways announce the same prefix, an ad 
hoc node selects the closest gateway (it can be specified that it should 
from there use the same gateway). The propagation method used to 
propagate the prefix information ensures that the path to the gateway is 
made of nodes that also use the same gateway : there is no need of a 
routing header, and default routes can be used safely.

Regards,
Christophe

[email-masked] wrote:

>Ryuji,
>
>I think your preferred tunneling method (using the routing header) is good. Using default routes, on the contrary, might lead to problems and should be removed as an option:
>
>If you have two gateways announcing the same default route, the MANET node has no control of which gateway the packet is routed out through. You might get problems with:
>- Stateless firewalls: E.g. The first packet of your (TCP-) session might go out through another gateway than the one corresponding to the selected source IP address. Thus, the return inbound packets will not reach the gateway corresponding to the MANET node's source IP address if the gateway is behind i firewall because no state is set in the firewall.
>- Ingress filtering: Outbound packets escaping out through "wrong" gateways are filtered out.
>
>In addition to this, every time a MANEWT node moves e.g. on an OLSR MANET, until the routing converges, internal packets destined for this node might probably be sent out on the Internet along a default route.
>
>In fact, my comment in the WG meetings against the use of default routes was mainly targeted at the possible use of NATs with a IPv4 MANET. Here you have the additional problem that some GWs will probably implement NATs as a gateway enabling technology. But after second thoughts, I think my comment also applies well to IPv6.
>
>
>Paal
>
>  
>
>>From: Ryuji Wakikawa [[email-masked]]
>>Sent: 2004-03-03 07:58:37 CET
>>To: [email-masked]
>>Cc: [email-masked], [email-masked]
>>Subject: Re: [manet] Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.txt
>>
>>

---

From: Anders Nilsson <[email-masked]>
Date: Wed, 03 Mar 2004 11:05:03 +0100

Hello,

I must say that I agree with all the comments about trying to coordinate 
our efforts. (I am a co-author with Ryuji).
It doesn't make any sense at all to have several drafts that say 
basically the same thing, with some minor modifications. This is really 
the case right now. But the fact that we have so similiar drafts tells 
us that we are close to consensus, so making a common requirement 
document shouldn't be too hard. Having several drafts is really bad, and 
makes things bad for the implementors. There are implementors out there 
trying to implement these features, and they are clearly confused by all 
the different drafts. Nico Bayer have an implementation that he 
presented last week at EW2004, that closely follows the globalv6 draft. 
This is great, and although the imp. seems to follow the draft closely, 
there are some major differences to the draft. This could be explained 
by the confusion created by the different drafts, but may also 
implementation choices. Either way, a consensus is needed.

>have good chance to share ideas and make productive work in this topic.
Please point out what you think is wrong.

>next hop forwarding and require that a sender specifies a gateway in
What do you mean here?

This is from Paals mail:

> If you have two gateways announcing the same default route, the 
> MANET node has no control of which gateway the packet is routed 
> out through. You might get problems with:
> - Stateless firewalls: E.g. The first packet of your (TCP-) session 
> might go out through another gateway than the one corresponding to 
> the selected source IP address. Thus, the return inbound packets will 
> not reach the gateway corresponding to the MANET node's source IP address 
> if the gateway is behind i firewall because no state is set in the firewall.

As pointed out earlier, this problem can solved by letting intermediate 
forwarding nodes search their gateway list for the source prefix. If the 
source prefix matches an entry in the gateway list, the packet is 
forwarded to the indicated gateway. I think this solves the problem 
stated above. However, there is an other problem here. If the node is 
moving inside the network, it will probably want to switch to different 
gateways as they become closer. The only way for this to work in the 
mentioned solution is to onfigure a new address, which is not really a 
good solution. If the different gateways belong to the same domain, it 
might not even be possible, and routing header might be to prefer in 
that case. I discuss this problem among other things in a paper to be 
presented at WWC04, the main focus of the paper is performance though.

regards,

Anders

---

From: Christophe Jelger <[email-masked]>
Date: Wed, 03 Mar 2004 12:46:31 +0100

Actually each node knows what gateway it uses because there is a special 
field in the packet used to disseminate the prefix information. This 
field contains the IPv6 global address of the gateway (and another field 
gives the prefix length). Moreover, we "almost" don't need a routing 
protocol (of course don't take this statement too strictly), in the 
sense that, when a node wants to send data to some node in the Internet, 
it only uses a default route with next hop being one of its neighbors. 
The ad hoc node does not even need to have a /128 route to the gateway. 
Of course on the reverse path this is not the same (i.e. the gateway 
must have a /128 route to the ad hoc node).

Christophe

Anders Nilsson wrote:

> Hello again,
>
> Christophe Jelger wrote:
>
>>
>> Of course as one of the authors of a solution that uses default route 
>> I don't agree with your statements. ;-)
>>
>> the same gateway. With our solution gateways don't announce routes, 
>> they just announce prefixes. If two gateways announce the same 
>> prefix, an ad hoc node selects the closest gateway (it can be 
>> specified that it should from there use the same gateway). The 
>> propagation method used to propagate the prefix information ensures 
>> that the path to the gateway is made of nodes that also use the same 
>> gateway : there is no need of a routing header, and default routes 
>> can be used safely.
>>
> That sounds like a good solution, but the node can't control what 
> gateway it is currently using. A scenario where this is neeed is when 
> the node is moving from gateway to gateway. The node is then unable to 
> know what gateway it is currently communicating through. A node need 
> to know this when it switches to a new gateway, and "registers" 
> itself. This reason why this needed is because packets from the 
> Internet needs to be routed to the correct gateway, which is difficult 
> when mobile nodes are unware of its gateway. If a Cellular IP type of 
> solution is used, the routing entries in the access network are 
> updated by the actual packets flowing through the gateways. But there 
> is problems here as well, because oscillations easily occurs that 
> causes a lot of updates, especially when the mobile nodes are mobile. 
> I have simulated this, and it is harder to maintain than you might 
> think. If you rely on proactive gateway discovery, the default routing 
> entries have to be maintained during link breaks and mobility, along 
> with sequence number maintainence. I have a paper about this, in a 
> slightly different context, but during mobility and several hops to 
> the gateway, more complex control is needed.
>
> regards,
>
> Anders
>
>
>

---

From: Anders Nilsson <[email-masked]>
Date: Wed, 03 Mar 2004 13:11:05 +0100

Hello again,

That sounds good too. :-)
I read your draft again, refreshing my memory, it seems I have forgotten 
some of it, sorry.
Just a few more questions and comments.
I think you are forwarding each advertisement upon receiving it from the 
gateway, as in flooding? But updating it with new information.
Have you studied how the delay introduced by intetermediate nodes varies 
when the number of hops and neighbors increases?
I have an other question related to reactive protocols in your draft. 
Are you saying that mobile nodes should create the routing path to the 
gateway, reactively? I do think your solution for proactive discovery is 
good ;-) , I do, but if this proactivness is already taking place, even 
when a reactive protocol is used, why not also create the default route? 
You say it breaks the reactive nature of the protocol, I agree, but so 
does having periodic updates. I like your proactive discovery approach, 
but I think a reactive solution should be more purely reactive. But, 
this might need some more work.

regards,

Anders

Christophe Jelger wrote:

> Actually each node knows what gateway it uses because there is a 
> special field in the packet used to disseminate the prefix 
> information. This field contains the IPv6 global address of the 
> gateway (and another field gives the prefix length). Moreover, we 
> "almost" don't need a routing protocol (of course don't take this 
> statement too strictly), in the sense that, when a node wants to send 
> data to some node in the Internet, it only uses a default route with 
> next hop being one of its neighbors. The ad hoc node does not even 
> need to have a /128 route to the gateway. Of course on the reverse 
> path this is not the same (i.e. the gateway must have a /128 route to 
> the ad hoc node).
>
> Christophe
>
> Anders Nilsson wrote:
>
>> Hello again,
>>
>> Christophe Jelger wrote:
>>
>>>
>>> Of course as one of the authors of a solution that uses default 
>>> route I don't agree with your statements. ;-)
>>>
>>> In our draft each MANET node knows which gateway it uses, and (in 
>>> the steady-state) it knows that all nodes on the "default route" 
>>> path use the same gateway. With our solution gateways don't announce 
>>> routes, they just announce prefixes. If two gateways announce the 
>>> same prefix, an ad hoc node selects the closest gateway (it can be 
>> the node is moving from gateway to gateway. The node is then unable 
>> to know what gateway it is currently communicating through. A node 
>> need to know this when it switches to a new gateway, and "registers" 
>> Internet needs to be routed to the correct gateway, which is 
>> difficult when mobile nodes are unware of its gateway. If a Cellular 
>> IP type of solution is used, the routing entries in the access 
>> network are updated by the actual packets flowing through the 
>> gateways. But there is problems here as well, because oscillations 
>> easily occurs that causes a lot of updates, especially when the 
>> mobile nodes are mobile. I have simulated this, and it is harder to 
>> maintain than you might think. If you rely on proactive gateway 
>> discovery, the default routing entries have to be maintained during 
>> link breaks and mobility, along with sequence number maintainence. I 
>> have a paper about this, in a slightly different context, but during 
>> mobility and several hops to the gateway, more complex control is 
>> needed.
>>
>> regards,
>>
>> Anders
>>
>>
>>
>
>
>

---

From: Christophe Jelger <[email-masked]>
Date: Wed, 03 Mar 2004 14:19:27 +0100

Anders,

The difference with pure flooding is that an ad hoc does not forward the 
information if it does not use it. With this very simple rule prefix 
continuity is possible.

We did not want to add a default route for reactive protocols because :
1. If there is a default route, how can the protocol be reactive ? 
(there is always a match in the routing table for any destination)
2. If there is no default route, the gateway can reply to REQ for 
destinations that are outside the Internet. Of course if we want to 
guarantee that all nodes on the path to the gateway share the same 
prefix, we cannot use the route obtained via the reactive protol. Each 
node must send the packet to the neighbor from which it got its prefix. 
I'm sure how this could be specified within the operation of a reactive 
protocol.

Christophe

Anders Nilsson wrote:

> I read your draft again, refreshing my memory, it seems I have 
> forgotten some of it, sorry.
> I think you are forwarding each advertisement upon receiving it from 
> the gateway, as in flooding? But updating it with new information.
> Have you studied how the delay introduced by intetermediate nodes 
> varies when the number of hops and neighbors increases?
> gateway, reactively? I do think your solution for proactive discovery 
> is good ;-) , I do, but if this proactivness is already taking place, 
> even when a reactive protocol is used, why not also create the default 
> route? You say it breaks the reactive nature of the protocol, I agree, 
> but so does having periodic updates. I like your proactive discovery 
> approach, but I think a reactive solution should be more purely 
> reactive. But, this might need some more work.
>
> regards,
>
> Anders
>
> Christophe Jelger wrote:
>
>>>> path use the same gateway. With our solution gateways don't 
>>>> announce routes, they just announce prefixes. If two gateways 
>>>> announce the same prefix, an ad hoc node selects the closest 
>>>> gateway (it can be specified that it should from there use the same 
>>>> gateway). The propagation method used to propagate the prefix 
>>>> information ensures that the path to the gateway is made of nodes 
>>>> that also use the same gateway : there is no need of a routing 
>>>> header, and default routes can be used safely.
>>>>
>>> gateway it is currently using. A scenario where this is neeed is 
>>> when the node is moving from gateway to gateway. The node is then 
>>> unable to know what gateway it is currently communicating through. A 
>>> node need to know this when it switches to a new gateway, and 
>>> "registers" itself. This reason why this needed is because packets 
>>> from the Internet needs to be routed to the correct gateway, which 
>>> is difficult when mobile nodes are unware of its gateway. If a 
>>> Cellular IP type of solution is used, the routing entries in the 
>>> access network are updated by the actual packets flowing through the

---

From: Erik Nordström <[email-masked]>
Date: Wed, 03 Mar 2004 13:28:47 +0100

Hi,

I don't see how you can efficiently handle multiple gateways when using
default routes? Especially with reactive protocols that do not have a
complete view of the network. Even if you maintain the gateway mapping,
how will you deal with hand-overs between gateways? You say  that the
solution is to force nodes to use the "same" default route, but I do not
think that is a good idea. Individual nodes may know best when to switch
gateways, and they should be allowed to do so if they wish. How can you
guarantee that a default route is not diverted to another gateway at an
intermediate node if a packet carries no mapping between the (final)
destination and the gateway? How do you handle control packets (from
different gateways) that want to change the default route --> gateway
mapping?

My experience with AODV-UU is that gateway tunneling has many properties
that are prefered in an ad hoc network. Tunnels easily support multiple
gateways and are transparent for intermediate nodes that forwards the
traffic to the gateway. I have a paper pending that clearly shows the
advantages of tunnels in this context.

Before proceeding with a merged draft on Internet connectivity, I think
that the proposal should be backed up with serious research showing
problems or benefits of different strategies. I have implemented gateway
connectivity in AODV-UU, and my experience clearly points in the
direction of tunnels.

Regards,

Erik Nordström

---

From: Christophe Jelger <[email-masked]>
Date: Wed, 03 Mar 2004 14:51:41 +0100

Hi Erik,

Well about handovers everything is in the draft, but I have to admit 
that it's not very clear sometimes. I hope to write a new version soon.

To summarise : we propose different algorithms used by each ad hoc node 
to choose (and switch between) a gateway. It can either use the closest 
gateway (whatever prefix it uses), or a gateway that uses the same 
prefix than it currently uses (whatever the distance from the gateway). 
We also proposed slight variants. So first answer to your email is that 
switching between gateways is controled by each ad hoc node independently.

Moreover, and because of our particular (but very simple) way of prefix 
propagation, we can guarantee that a default route is never diverted (in 
the steady-state). By steady-state, I mean that of course topological 
changes can cause trouble during a very small amount of time. The main 
idea behind our draft is prefix continuity : we "build" contiguous 
islands of nodes that share the same prefix/gateway. This can be of high 
interest for providers (e.g. management, services, ...).

We have implemented our solution (IPv6) as an independent daemon and it 
works really well in the presence of multiple gateways and prefixes. We 
will soon integrate it in an IPv6 version of OLSR (Qolyester from LRI in 
France). I am also finishing some simulations in which we evaluate our 
solution : I hope I can submit the results for publication very soon.

Well and before everybody says what's best and what's bad, I personally 
think it's very difficult at this stage to say so. If you have done some 
simulations of the tunnel approach you have probably seen that results 
can greatly vary across different simulation scenarios. I think all 
solutions have pros and cons, and we should be able to find the best 
parts of all solutions.

Regards,
Christophe

---

From: "Philippe Jacquet" <[email-masked]>
Date: Wed, 3 Mar 2004 14:20:16 +0100

Hello, Christophe,

I like your draft. Just some details worry me. I see that gateways send
refresh message every two seconds. Since these messages are somewhat
retransmitted by all nodes sharing the same prefix, is it not too much
traffic in dense networks? Another question(maybe I misunderstood the basic
concept): your protocol helps the node to select their gateway, but if the
route to the gateway is given by the routing protocol which is independent
of your protocol, how do you guarantee that the data path provided by the
routing protocol won't cross different prefix islands and then end to a
different gateway?

Regards,
Philippe

---

From: Christophe Jelger <[email-masked]>
Date: Wed, 03 Mar 2004 15:36:20 +0100

Hello Philippe,

Of course the propagation method implies one retransmission per node 
every two seconds. While this is not so much overhead (that's a personal 
opinion), we explain in our draft that our proposal can benefit from a 
better approach such as flooding with MPR (as in OLSR).

Now the propagation method itself leads to prefix continuity, i.e. it 
guarantees that there exists a path, between a node and its gateway, 
such that this path is made by nodes that use the same gateway. This is 
a sort of "recursive" concept ... for each ad hoc node, if it receives 
the information about gateway G and prefix P from one of its neighbor 
N1, it means that :

- the neighbor N1 uses P and G
- this neighbor N1 got the information from one of its neighbors (say 
N2) that uses G and P as well
- the default route of N1 points to N2
- recursively the same conclusions apply to N2 a nd all the upstream 
neighbors towards G

Christophe

---

From: [email-masked]
Date: 3 Mar 2004 15:06:12 +0100

Christophe,

It seems I triggered some discussion that passed me by, but let me cut into this thread and response to your preference for default routes.

This is from Anders' mail:
> stated above. 

Here I think Anders gets to the core of the matter - i.e destination based routing: Many nodes communicating with the same external host cannot share the same destination-based route and still get to different gateways.

1) Either you need a tunneling solution or some sort, 
2) or you need source address based default routing

The first is lean and mean, and works in nearly any networking scenario, and with any routing protocol. 

The functionality of the second is obscure, it is less clean than the tunneling solution, and probably makes routing more complicated. In addition, you bind internet access together with address autoconfiguration, which reduces the level of modularity.

Since the latter solution resembles a hack (as compared to the clean tunneling solution), I also think it might lead to unforseen problems sooner or later. For example, if I would use it in an IPv4 setting, it would obviously not work. (Default routes is not a good idea, at least not with IPv4, and should never have been accepted in the experimental RFCs, IMO).

Yes, and by the way, here is another problem, which I didn't think of:

> However, there is an other problem here. If the node is 
> might not even be possible

I think I am willing to pay the little extra overhead of tunneling to get a simpler, modular, and more robust solution.

Paal

> From: Christophe Jelger [[email-masked]]
> Sent: 2004-03-03 15:36:20 CET
> To: manet [[email-masked]]
> Subject: Re: [manet] Default Routes
> 
> Hello Philippe,
>

---

From: Erik Nordström <[email-masked]>
Date: Wed, 03 Mar 2004 15:13:28 +0100

Jelger,

I admit that I am not that familiar with your proposal, and probably
should read it more carefully. However, there are some things I
question... 

For example, why implement a seperate flooding mechanism when this is
already provided by the routing protocol (for example OLSR)? You propose
to optionally integrate this with the routing protocol, but I do not see
how that is possible with MPR-based flooding?

I am not convinced that you have maximum flexibility when building your
prefix islands of nodes. How can nodes part of a prefix island
individually choose another gateway? But, I admit, I need to study your
draft in more detail.

With tunnels you can simply add a flag in ordinary control messages
announcing some nodes as gateways. Nodes can then individually choose a
gateway and tunnel packets to it. The routing protocol takes care of the
rest transparently. This also works well with reactive protocols.

/Erik

---

From: "Philippe Jacquet" <[email-masked]>
Date: Wed, 3 Mar 2004 16:52:46 +0100

I don't see any problem with MPR flooding, when last hop is MPR selector
then it will be the upstream neighbor.
I think the algorithm could be an application of the recent MPRF draft with
the option TTL=1.

Philippe
----- Original Message -----
From: Erik Nordström <[email-masked]>
To: Christophe Jelger <[email-masked]>
Cc: manet <[email-masked]>
Sent: Wednesday, March 03, 2004 3:13 PM
Subject: Re: [manet] Default Routes

Jelger,

/Erik

---

From: Christophe Jelger <[email-masked]>
Date: Wed, 03 Mar 2004 19:12:25 +0100

Erik,

(please call me Christophe !)

You are right when you say that a node within an "island" can't change 
its prefix. Our objective is to create these islands, so we don't really 
want to see a node that breaks this organisation. ;-)

I also agree with you that the tunnel-based solution is the best one in 
terms of control overhead (less control packets sent). I think our 
proposal has a completely different objective. The only point we try to 
defend is the concept of prefix continuity : this feature might be of 
real interest for operators who like to have a somehow organised 
network. This feature can also allow an operator to do some management 
control and stuff like that.

Regards,
Christophe

PS : we do not implement a separate flooding mechanism, because this is 
not flooding !!! (I insist on that !) The information disseminates away 
from gateways, it look like flooding but it's not ! ;-)

---

From: Erik Nordström <[email-masked]>
Date: Wed, 03 Mar 2004 18:14:16 +0100

Maybe I am missing something (and please point it out), but will not the
MPR flooding limit the distribution of (different) prefixes in the
network? My concern is that a node far down the (MPR) distribution path
rooted at a gateway will not be able to change gateway/prefix unless its
upstream neighbor (closer to the gateway) also changes its prefix (of
another gateway)? 

//Erik

---

From: Christophe Jelger <[email-masked]>
Date: Wed, 03 Mar 2004 19:25:54 +0100

Erik,

You are right ... sometimes a node cannot change its prefix unless its 
upstream neighbor chooses another one. This is what allows to have 
prefix continuity. We cannot have all nodes do whatever they want and 
guarantee the prefix continuity feature ... ;-)

Again using MPR is not a problem ... there will be less flexibility and 
routes might not be "shortest path", but there is no reason why it 
should not work.

And about prefix distribution : prefix distribution is limited "by 
nature", i.e. a node that is a the limit of two "islands" will not 
forward control packets received from the island it does not belong to.

Christophe

---

From: Erik Nordström <[email-masked]>
Date: Wed, 03 Mar 2004 18:34:44 +0100

Christophe,

Ok, you are proposing a limited scope solution, which is fine. I just
didn't realize that was your intention.

However, I have another question. How do you handle "contention" between
the announcements at the edges of bordering prefix islands? I guess that
borderline nodes have the ability to select gateway by themselves, but
that could potentially affect many downstream nodes that previously used
another prefix. A node could also cut off and isolate islands of nodes
if it chooses to change prefix/gateway. What are the convergence times
for situations like that? Is it desirable that borderline nodes could
have such a big effect on lots of downstream nodes?

//Erik

---

From: "Philippe Jacquet" <[email-masked]>
Date: Wed, 3 Mar 2004 19:40:36 +0100

Christophe,

This is property of MPR flooding: the path may be shorter than with blind
flooding, of course not necessarily the shortest path since transmissions
may be desequenced.

Philippe
----- Original Message -----
From: Christophe Jelger <[email-masked]>
To: manet <[email-masked]>
Sent: Wednesday, March 03, 2004 7:25 PM
Subject: Re: [manet] Default Routes

Erik,

Christophe

>>>>>Actually each node knows what gateway it uses because there is a
special

---

From: Richard Ogier <[email-masked]>
Date: Wed, 03 Mar 2004 11:30:17 -0800

Christophe Jelger wrote:

> Again using MPR is not a problem ... there will be less flexibility 
> and routes might not be "shortest path", but there is no reason why it 
> should not work. 

Routes *will* be the min-hop, since the gateway info message contains 
the distance in hops
to the gateway, so a node can always choose a neighbor with fewer hops 
as the next hop
to the gateway.  But the MPR forwarding rule should be that a node 
relays a gateway info
message if the *next hop* is an MPR selector.   Thus, the path to the 
gateway will be
a sequence of MPR selectors.    Philippe, is this correct?

Richard

>>>>>>> when
>>>>>>> difficult

---

From: Richard Ogier <[email-masked]>
Date: Wed, 03 Mar 2004 11:50:36 -0800

I need to make a minor correction for my suggestion to work
(i.e., to guarantee min-hop paths to the gateway).
The next hop to the gateway must be selected uniquely among
all neighbors that report the minimum number of hops to the gateway.
One way to do this is to select the *first* neighbor that reported
the gateway info with a given sequence number. However, as was discussed
last week, this is a probem with the MPRF draft, since different nodes
may not agree on which neighbor was the first one to transmit a given 
packet.
To fix this, a node should relay the gateway info message if the
minimum ID neighbor that reports the minimum number of hops to the
gateway is an MPR selector.

Richard

Philippe Jacquet wrote:

>>>I think the algorithm could be an application of the recent MPRF draft
>>>
>with
>
>>>the option TTL=1.
>>>
>>>Philippe
>>>>switching between gateways is controled by each ad hoc node
>>>>
>independently.
>
>>>>>>field contains the IPv6 global address of the gateway (and another
>>>>>>
>field
>
>>>>>>sense that, when a node wants to send data to some node in the
>>>>>>
>Internet,
>

---

From: Eric Fleury ARES--INRIA <[email-masked]>
Date: Wed, 03 Mar 2004 22:10:43 +0100

Hello,

 > routes might not be "shortest path", but there is no reason why it

I think that the great property inside OLSR is that MPR offers shortest 
path as opposed to a of pure flooding process that may generate non 
optimal routes... but my point is not to enter in this polemical details 
right know.

I do not really understand the aim of this debate since each one tries 
to push one solution  with a implementation point of view.
I'll prefer to try to model / formalize the problem and try to design 
general classes of solutions but without  all implementation constrains 
in a first time. Some works do  exist on  proactive/reactive compromise 
for routing. I'm sure that we can also have and show the same behavior 
on GW discovery processes.

Trying to maintain contiguous areas is a potential candidate but the 
argument to support such proposal should not be "it avoids to set up 
source routing which is hardest to setup on current kernel...". Note 
that IP was modified to support multicast (-;

This discussion on GW discovery appeared several months/years ago in the 
MANET mailing list and in fine, one conclusion was that we need a more 
general service discovery protocol. More precisely, trying to focus only 
on prefix delegation and developing a independent protocol is a so so 
answer since it will always be redundant with the underlying routing 
protocol used (cf OLSR flooding discussion!).

Thus either we try to set up a more generic discovery protocol and a 
GW/prefix is one service (and we can try to compare here large classes 
of philosophies : pro actively announce services, reactively reclaim 
services...) or we can try to develop MANET routing protocol extension 
in order to corporate prefix delegation. IN OLSR, using MPRs + TC 
packets will be more efficient than re designing a flooding like prefix 
delegation...

I'm ok to set up the skeleton of an initial draft requirement for a 
generic service discovery (even if I do not like this term of service 
since it is used 1000 times in several contexts...)

Regards

Eric

---

From: Richard Ogier <[email-masked]>
Date: Wed, 03 Mar 2004 13:45:39 -0800

Eric Fleury wrote:

> This discussion on GW discovery appeared several months/years ago in 
> the MANET mailing list and in fine, one conclusion was that we need a 
> more general service discovery protocol. More precisely, trying to 
> focus only on prefix delegation and developing a independent protocol 
> is a so so answer since it will always be redundant with the 
> underlying routing protocol used (cf OLSR flooding discussion!).
>
> packets will be more efficient than re designing a flooding like 
> prefix delegation...

I agree with your point that it is redundant to have a separate protocol
to advertise gateways (which is really a distance-vector routing protocol),
when gateway information can and should be provided by the underlying
routing protocol (without promoting a particular routing protocol at 
this time).

In fact, I made a similar point last September, which I will repeat here:

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

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

---

From: "Pedro M. Ruiz" <[email-masked]>
Date: Wed, 03 Mar 2004 22:57:52 +0100

Hi all,

> general classes of solutions but without  all implementation 
> constrains in a first time. Some works do  exist on  
> proactive/reactive compromise for routing. I'm sure that we can also 
> have and show the same behavior on GW discovery processes.

I think this evidences once more the need for an WG-agreed requirements 
document. I think this is somethink we need to start working on as a WG. 
Comparing the prefix continuity approach against the tunnelling 
approaches does not make any sense if we do not agree firstly on what 
are our requirements. For example, in an "opperator centric" approach, 
prefix continuity would be very interesting. Is that one of our 
requirements?. I think those are the things we have to state in such a 
document.

As I mentioned some e-mails ago, I'd be willing work on such a draft. 
But, it needs definetly to be agreed within the WG.

> packets will be more efficient than re designing a flooding like 

I also think that Internet conectivity is a basic service to discover 
inside a MANET. In fact, a prefix does not convey enough information 
about the network to which the GW is connected. Should GW provide 
further information, MANET nodes can take more intelligent decissions. 
However, I think that working towards a general service discovery could 
actually add much more complexity. I think we can concentrate at the 
moment on Internet connectivity whereas this general service discovery 
(including Internet) may fall into the ANS charter??

In any case, I have no objection if the WG dicides to go that way.

Regards,

Pedro

---

From: Joe Macker <[email-masked]>
Date: Wed, 03 Mar 2004 17:44:19 -0500

At 07:54 PM 3/3/2004, Richard Ogier wrote:
>Eric Fleury wrote:
>
>>This discussion on GW discovery appeared several months/years ago in the MANET mailing list and in fine, one conclusion was that we need a more general service discovery protocol. More precisely, trying to focus only on prefix delegation and developing a independent protocol is a so so answer since it will always be redundant with the underlying routing protocol used (cf OLSR flooding discussion!).
>>
>>Thus either we try to set up a more generic discovery protocol and a GW/prefix is one service (and we can try to compare here large classes of philosophies : pro actively announce services, reactively reclaim services...) or we can try to develop MANET routing protocol extension in order to corporate prefix delegation. IN OLSR, using MPRs + TC packets will be more efficient than re designing a flooding like prefix delegation...
>
>
>routing protocol (without promoting a particular routing protocol at this time).
>
>> 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.
>
>routing protocol can provide this information to the manet nodes. If prefix continuity is desired, the routing protocol can be modified to
>manet nodes in a timely, efficient manner. (If it doesn't, then the routing protocol needs to be improved.)
>

I agree with this also.
Gateway advertisement has been straightforward for the proactive routing approaches.
This is applied in practice today.

A problem statement should not require a separate mechanism for that case.

-Joe

---

From: "Pedro M. Ruiz" <[email-masked]>
Date: Wed, 03 Mar 2004 23:44:26 +0100

Joe Macker wrote:

Eric Fleury wrote:

I agree with this also.

I tend to agree with both of you.
But I would also consider the to extend a reactive protocol with a
proactive gateway discovery mechanism. So, you can call this enhanced
protocol to be hybrid. But I think there is no point in having the
mechanism separate from the routing protocol.

However, I think is a good practice to focus now on defining such a
mechanism regardless of the routing protocol, and then try to
incorporate the agreed mechanism into any of the MANET routing
protocols (either proactive or reactive).

Regards, Pedro

---

From: "HyunWook Cha" <[email-masked]>
Date: Thu, 4 Mar 2004 14:20:49 +0900

Hello, Christophe. 

Please see my inline comments.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christophe Jelger
> Sent: Wednesday, March 03, 2004 10:19 PM
> To: manet

Why not? It depends on the condition on which route discovery should be
triggered based. We can give more stric constraint like this to reactive
routing protocol. If  a valid route entry which is not a default route
is not found, peform route discovery. Otherwise, another way is
presented in my draft(and somewhere in other draft). If default route is
available according to source address, do not "route discovery" and just
forward using the default route. And later,         prefix route(/n)
entry from solicited/unsolicited gateway advertisement is found, packets
are forwarded using the prefix route and perform route discovery. ->
"route optimization". I think that this approach is also
reacive(on-demand). 

> prefix, we cannot use the route obtained via the reactive 
> protol. Each node must send the packet to the neighbor from which it
got 
> its prefix. I'm sure how this could be specified within the operation
of 
> a reactive protocol.

I remember that we have discussed about this. Could you elaborate on
this? 

More question. When current default route(path) which share same prefix
breaks, how can this fact is informed to downstream nodes immediately?
By RERR for the corresponding gateway? As I mentioned several times
before, it is not guaranteed that route informaition(next hop of the gw)
obtained by routing protocol is same as upstream neighbor of the default
route. Thus, RERR for the gateway may not be issued. If different
neighbor node advertising same prefix is available, you can switch this
node as new upstream node. However, If not, (It may take a few seconds
to recognize this.) the node should change its address with one with
different prefix. In recuresively, all downstream nodes will change
their addresses if they are arranged in a line. Total delays are
incremented node by node until leaf node will recognize breakage of the
default route.
  
I have a question which has not been asked before. In your draft, how
can a gateway determine that a global address affiliated to its prefix
is owned by a MANET node or not? A gateway can do this because it should
issue ICMP destination unreachable for addresses which are not used any
more by MANET nodes and perform route discovery for addresses which are
used by MANET nodes. In other drafts including Wakikawa's, Pekka's, and
mine, a node updates its address lifetime as well as reachability from a
gateway through periodic RREQ/RREP exchange.  

Regards,

HyunWook

---

From: "HyunWook Cha" <[email-masked]>
Date: Thu, 4 Mar 2004 15:36:55 +0900

Hello, Chiristophe and Eric.

> Sent: Wednesday, March 03, 2004 10:52 PM
> To: manet

As long as I understand, what Eric means is that "switching decision
between gateways" in a node should not be affected by neighbors'
prefix/address and each node can decide independently its best gateway.
In case of second algorithm, this is not provided.

[from Eric's mail]  
> >advantages of tunnels in this context.

Could you elaborate on this? What are tunnel end points? What about
inbound traffic?

> >connectivity in AODV-UU, and my experience clearly points in the

I think that tunneling, source based forwarding, routing header those
kind of stuff are not research issues but engineering issues. Though,
performance does matter on either side. 

Regards,

HyunWook

---

From: Christophe Jelger <[email-masked]>
Date: Thu, 04 Mar 2004 10:46:08 +0100

Hi,

Can you please elaborate on that ? While I agree with your statement, I 
don't fully agree with the way that it is "straighforward". Advertising 
a prefix is obviously very easy, and using it is also easy with the 
tunnel approach. I think the complexity (relatively speaking) is in the 
maintenance due to nodes mobility. Even with the tunnel approach, a node 
must check that the gateway is always reachable in order to be able to 
switch to a new gateway. Each node should also always use (for example) 
the closest gateway. We can also consider load balancing between gateways.

Christophe

---

From: Christophe Jelger <[email-masked]>
Date: Thu, 04 Mar 2004 10:54:49 +0100

Hi Pedro,

I agree with you when you say that the gateway discovery mechanism 
should not be separated from the routing protocol.

As stated in the draft, our approach could easily be integrated into 
OLSR. That's what we plan to do with the LRI version (Qolyester). We 
could therefore use the neighbors table of OLSR and use TC packets to 
send the gateway information (the operation has to be slightly modified 
but I won't go into the details).

There might be some more complicated issues with reactive protocols, but 
I haven't gone into implementation details so far.

Christophe

Pedro M. Ruiz wrote:

>>
> I tend to agree with both of you. But I would also consider the to 
> extend a reactive protocol with a proactive gateway discovery 
> mechanism. So, you can call this enhanced protocol to be hybrid. But I 
> think there is no point in having the mechanism separate from the 
> routing protocol.
>
> _______________________________________________ manet mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/manet

---

From: Christophe Jelger <[email-masked]>
Date: Thu, 04 Mar 2004 11:15:52 +0100

Hi all,

Well I obviously appreciate the discussions we have on gateway 
discovery, but as Eric Fleury said, we had similar discussions in the 
past. This time I hope it won't be for nothing, and I hope there could 
be some constructive consequences. It seems that many MANET members are 
willing to work on that, so maybe we could summarize the discussions we 
had and try to go ahead, maybe with a problem statement draft.

So (maybe this is a very direct question) are the chairs willing to add 
this issues in the WG charter ?

I think we could start to discuss on how we could collaborate ...

Christophe

---

From: "Pedro M. Ruiz" <[email-masked]>
Date: Thu, 04 Mar 2004 10:14:36 +0100

Hi Christophe,

I completely agree with your approach. First you define how to do the 
Internet interworking, then once it is proven to be correct, it will be 
integrated within the routing protocols (e.g. OLSR),

Of course, some problems may happen to appear when integrating with the 
protocol. But, I think those are solvable once you know exactly how do 
you want to perform the Interworking.

So, I think we have the same view on this.

Regards, Pedro

Christophe Jelger wrote:

> send the gateway information (the operation has to be slightly 
> modified but I won't go into the details).
>
> There might be some more complicated issues with reactive protocols, 
> but I haven't gone into implementation details so far.
>
> Christophe
>
> Pedro M. Ruiz wrote:
>
>>>
>> mechanism. So, you can call this enhanced protocol to be hybrid. But 
>> I think there is no point in having the mechanism separate from the 
>> routing protocol.
>>

---

From: "HyunWook Cha" <[email-masked]>
Date: Thu, 4 Mar 2004 18:33:17 +0900

Hello, all.

I agree with Christophe, though "Gateway Discovery" seems to be narrow.
This is important issue since it is not an optional service, and basic
framework to enable communication through Internet as well as
incorporation with MIPv6 and multi-homing issues can be addressed in
this category.  

HyunWook 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christophe Jelger
Sent: Thursday, March 04, 2004 7:16 PM
To: manet
Subject: [manet] Gateway Discovery : are we going forward ?

Hi all,

Christophe

---

From: "HyunWook Cha" <[email-masked]>
Date: Thu, 4 Mar 2004 18:46:35 +0900

Hello, all.

Could you tell me why GW discovery should not be separated from reactive
routing protocols? IMO, periodic gw solication/advertisement seems to be
proactive. 

Thanks in advance.

HyunWook 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Ogier
Sent: Thursday, March 04, 2004 6:46 AM
To: manet
Subject: Re: [manet] Default Routes

I agree with your point that it is redundant to have a separate protocol
to advertise gateways (which is really a distance-vector routing
protocol),
when gateway information can and should be provided by the underlying
routing protocol (without promoting a particular routing protocol at 
this time).

In fact, I made a similar point last September, which I will repeat
here:

mechanism from
mechanism

nodes to

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

Regards,
Richard

---

From: Guillaume Chelius <[email-masked]>
Date: Thu, 04 Mar 2004 11:39:30 +0100

Hello,

> routing protocols? IMO, periodic gw solication/advertisement seems to be

A periodic solicitation/advertisement scheme is indeed proactive. As for 
a periodic unsolicited advertisement one. But on-demand 
solicitation/advertisement (route-request to the gateway) is reactive. 
This clearly shows that for reactive protocols, the gateway/prefix 
advertizement may be either integrated to the routing protocol (for 
reactive) or may be performed by a separate protocol if a proactive 
scheme is preferred.

For a proactive protocol, the question does not hold as proactive 
advertizement can be performed at almost 0 cost.

Regards,
Guillaume.

---

From: Erik Nordström <[email-masked]>
Date: Thu, 04 Mar 2004 12:40:07 +0100

> Could you elaborate on this? What are tunnel end points? What about

Tunnel end points would be the source node in the ad hoc network and the
gateway. Between these end points packets are encapsulated/tunneled
(through ip-in-ip, or similar). Intermediate nodes (between the source
and the gateway) can then forward the packets without knowledge of the
external (Internet) address. In fact they need no extra state, except a
route to the gateway, which is provided by the ad hoc routing protocol.
Inbound traffic (i.e., traffic from the Internet to the ad hoc network)
does not need to be tunneled inside the ad hoc network since the return
address is routable there (in case you run Mobile IP, NAT or have
address conf).

/Erik

---

From: Erik Nordström <[email-masked]>
Date: Thu, 04 Mar 2004 13:36:16 +0100

> had and try to go ahead, maybe with a problem statement draft.

I agree that a "problem statement" draft is needed. The problem I have
with the current drafts is that they try to cover _all_ grounds by
including several ways to do forwarding, address conf etc. Speaking from
experience (by trying to implement Internet connectivity in AODV-UU), it
is hard to extract something useful from these documents.

A problem statement draft would explore all issues, scenario focus,
gateway discovery, gateway forwarding, address conf etc. Hopefully, this
would lead to one draft describing a simple and efficient way to provide
Internet connectivity.

After that, there would be an opening for limited scope solutions,
extensions and optimizations, etc.

//Erik

---

From: "Philippe Jacquet" <[email-masked]>
Date: Thu, 4 Mar 2004 13:44:24 +0100

----- Original Message -----
From: Richard Ogier <[email-masked]>
To: Christophe Jelger <[email-masked]>
Cc: manet <[email-masked]>
Sent: Wednesday, March 03, 2004 8:30 PM
Subject: Re: [manet] Default Routes

> a sequence of MPR selectors.    Philippe, is this correct?
Yes you are correct, excepted the minor point that there is no guarantee
that blind flooding or MPR flooding forward information on min-hop path even
in presence of error free transmissions. The reason is that retransmissions
on optimal path could be re-empted by retransmissions on non-optimal paths.
However MPR flooding will be statistically done on shorter paths than blind
flooding.

In order to get shortest path for sure we would have either to allow nodes
to retransmit the information several times, everytime they receive it on
shorter hop number (see our paper on superflooding), or to wait long enougth
between retransmission in order to collect the shortest path before
retransmission. There is also the possibility to explicitly compute the
shortest path to the gateway but this will only work with proactive
protocols.

I agree that if gateway advertizement were included in routing protocols, as
it is done in proactive protocols, the problem would be much simpler. OLSR
has already an embedded mechanism called HNA. It can be easily extended to
several gateways information if one uses the rule of selecting the gateway
with the shortest path.

Philippe

> >> file://Erik

---

From: [email-masked]
Date: 4 Mar 2004 15:35:18 +0100

Erik,

On a side note: I am just wondering if your solution really is fully transparent as you claimed? Does not AODV also use the source IP addresses of data packets to keep routes up to date... and without tunneling from GW...? Comments?

Paal

---

From: Guillaume Chelius <[email-masked]>
Date: Thu, 04 Mar 2004 15:45:24 +0100

Hello Paal,

You could also use source routing instead tunneling. However, if a 
tunnel is used, the source address of the tunnel is identical to the one 
of the original packet. Between the tunnel header and the packet header, 
only the destination address changes (gateway address instead of 
destination address).

Regards,
Guillaume Cheluis.

---

From: Erik Nordström <[email-masked]>
Date: Thu, 04 Mar 2004 16:03:16 +0100

> On a side note: I am just wondering if your solution really is fully transparent as you claimed? Does not AODV also use the source IP addresses of data packets to keep routes up to date... and with…

The source address is not changed in the encapsulated packet... Only the
destination is "rewritten" to be the gateway. Therefore it is fully
transparent in the sense that intermediate nodes only have to run a
standards compliant AODV implementation. If Mobile IP is used the source
address is the node's home address and will by MIP be tunneled to the
correct gateway (FA) where the node is registered. Since this home
address is routable in the ad hoc network there is no need for a tunnel
from the gateway to the ad hoc node.

Does this answer your question?

/Erik

---

From: [email-masked]
Date: 4 Mar 2004 16:28:37 +0100

Erik and Guilliaume, 

You both misunderstood the question and what the potensial problem is about, so I take that as evidence that I need to express myself more clearly.

- First, to address Guilliaumes comment: "Tunneling" is not a clear word: is CN->MN communication in MIP6 tunneling or not? So let us use the word "Encapsulation" and "Source Routing" instead.

- Encapsulation from Manet Node to Gw is straightforward (and probably a satisfactory IPv4 solution). Source routing is also an option (and preferable with IPv6). This is not the question! Let us not discuss that.

- Here is the question: If you do not do "encapsulation" (thanks, Guilliaume, for clarifying that source routing does NOT work in this case) of the return/inbound packets from GW to the MANET node, you import external addresses into the routing system. Normally, AODV would update the outgoing route (to the gateway) based on the source address of the incoming (un-encapsulated!) traffic. However, this incoming un-encapsulated traffic use external addresses as source addresses.

This is why I believe your solution is not fully transparent. And this is what I asked your comment on. 

Got it?

Paal

> From: Erik Nordström [[email-masked]]
> Sent: 2004-03-04 16:03:16 CET
> To: [email-masked]
> Cc: 'manet' [[email-masked]]
> Subject: Re: SV: RE: [manet] Default Routes (Intern)
>

---

From: Erik Nordström <[email-masked]>
Date: Thu, 04 Mar 2004 16:41:40 +0100

Paal,

Ok, I understand what you mean. This might be an issue for specific
protocols and I guess for transperency you have to make tradeoffs. In
the AODV case this is not such a big issue, the gateway route will be
refreshed by the outgoing traffic (if using TCP), and I think that is
sufficient. If outgoing traffic is one way (UDP) there is no issue. The
only problem is incoming UDP traffic which is one way. In that case, it
does not really matter if the (reverse) gateway route times out, since
no traffic goes in that direction anyway.

If transparency is important, it is possible to encapsulate traffic (by
rewriting the source address) from the gateway to the source node too,
but increases complexity and overhead a bit.

However, because of the above mentioned reasons, I do not think that
this matters for AODV. Or do you think differently?

//Erik

---

From: "Sukanta K. Hazra" <[email-masked]>
Date: Fri, 05 Mar 2004 00:31:16 +0800

Hi Erik,

A short comment inline.
> no traffic goes in that direction anyway.
This is not strictly true. Even if the incoming UDP traffic is predominantly one
way, there are often control messages sent in the reverse direction, and
thus may need a route to the gateway.

> > > From: Erik Nordstr??m [[email-masked]]

-- 
Sukanta K. Hazra (Mr.)	<[email-masked]>
Institute for Infocomm Research
Tel: +65 6874-1953 Fax: +65 6776-8109
Homepage: http://www1.i2r.a-star.edu.sg/~sukanta/

---

From: [email-masked]
Date: 4 Mar 2004 19:06:50 +0100

Erik,

No, I am very much in line with your thinking here. 

By simple reasoning, I drew more or less the same conclusions as you did. But I am not 100% sure, since we have not tested the differences between the "ideal" to-way-tunneling and one-way-tunneling. (In fact, we tested both, based on your AODV-UU code, thanks!, but we have not made any proper comparizons.) 

My current standing is that the "ideal" Internet access mechanism, as far as routing is concerned, is tunneling in both directions: source routing (IPv6) or encapsulation (IPv4) of outbound traffic via the gateway and encapsulation of inbound traffic from gateway to MANET node (IPv4 and IPv6). From there you start to make optimizations to save bandwidth etc., and each optimization resembles a "hack", i.e. it undermines the ideal model.
 
- The first step is to go from two-way to one-way tunneling, as we have just discussed. 
- The next is perhaps your proposal to "rewrite" destination addresses at the GW, as you seem to propose (It does not sound good, IMHO. I think we have to accespt that we might need NAT for outgoing IPv4 traffic, but I hope you do not need it for incoming traffic as well.)
- Another alternative is to use source-address-based routing. This "hack" means that all outgoing traffic MUST have a souce IP addres under the gateways prefix. I.e. it will not work for IPv4, where you use private/IPv4-link-local address with NATs or home-address with a MIP-FA based gateway. It will also exclude every future IPv6 protocol that might need to use a source address that is not topologically correct for any gateway - i.e. this solution is also a "hack".
- The next step is perhaps to introduce Proxy RREPs (AODV, i.e. gateway impersonates external hosts when sending RREP, see the old globalv4/MIPv4 draft) or to use default routes (e.g. OLSR). Here you might introduce routing race conditions, and also race conditions between MANET nodes that have preference for using different gateways but who are communicating with the same external host.
- And so on...

What I have yet to understand (and this is why I initiated this discussion on "default routes") is the reason for default routes: i) Is it necesary ii) can it enhance routing performance of external traffic iii) or is it simply an optimization (or "hack") to save bandwidth.

Due to radio/link dynamics and mobility, the routing protocols are providing a service that is inherently not robust. What is my concern is that the default routes, and the route selection mechansims necessary, are also not rebust and prone to malfunctioning due to network dynamics. Intuitively, default routes adds an additional unpredictable element, in addition to the unpredictability of the routing.

With tunneling, on the contrary, we have only one single problem: How to make the routing protocol robust.

Thoughts?

Paal

> proto
cols and I guess for transperency you have to make tradeoffs. In

---

From: Richard Ogier <[email-masked]>
Date: Thu, 04 Mar 2004 10:32:14 -0800

Christophe Jelger wrote:

> Guillaume,
>
> Just on point, see inline my comment. In general I agree that gateway 
> discovery should not be separated, as stated in the draft. We first 
> implemented it as a stand-alone process to check the operation. As you 
> know, we plan to integrate it into OLSR. (see below for a last comment)

<SNIP>

>
> With prefix continuity, routes are optimal if we use the "distance" 
> algorithm : always choose closest gateway. In that case the route is a 
> shortest route, but it can be different than the shortest route 
> computed by the routing protocol. On the other hand, if we use the 
> algorithm "prefix stability", then the route might not be optimal (I'm 
> currently simulating this and it appears that routes are not much 
> longer on average).
>
So, the gateway discovery protocol (which uses distance vectors)
computes a route to some gateway, and the link-state routing protocol
(e.g., OLSR or TBRPF or OSPF) computes a route to each gateway, which
may be different from the one computed by the gateway discovery protocol.
Also, it is possible that the link-state protocol reacts to topology
changes faster or slower than the gateway protocol.
Wouldn't it be nice if the two protocols could *agree* on the route to
each gateway?  I would prefer to remove this redundancy, and just have
one routing protocol that computes the routes to all nodes, including
routes to gateways and default routes.
Several people (including Joe Macker, Chelius Guillaume, Pedro Ruiz,
Eric Fleury) have agreed that it would be better to avoid redundancy
between the proactive routing protocol and gateway discovery.
Can we agree that we have consensus on this
Now, you may say that the proactive routing protocol still needs some
mechanism to achieve prefix continuity.  IF we decide we need
to ensure prefix continuity (and I have doubts about this),
then the link-state routing protocol can be modified to achieve this,
using link-state routing (instead of distance vectors).

Regards,
Richard

---

From: Erik Nordström <[email-masked]>
Date: Thu, 04 Mar 2004 20:29:46 +0100

> No, I am very much in line with your thinking here. 
good ;-)

> My current standing is that the "ideal" Internet access mechanism, as far as routing is concerned, is tunneling in both directions: source routing (IPv6) or encapsulation (IPv4) of outbound traffic…

Tunneling in both directions is OK, but I am not sure I would call it
"ideal". It is just one solution, and I believe one-way is enough. But
it is not such a big deal I think.

> - The next is perhaps your proposal to "rewrite" destination addresses at the GW, as you seem to propose (It does not sound good, IMHO. I think we have to accespt that we might need NAT for outgoin…

I am not sure what you mean here... I did not propose to rewrite the
destination address except for the src->gateway encapsulation (depending
on what encapsulation method you choose). I agree that NAT is a good
target, but can be problematic with multiple gateways (i.e., keeping
consistent NAT states). Mobile IP is the best solution for seamless
migration between gateways I think.

> - Another alternative is to use source-address-based routing. This "hack" means that all outgoing traffic MUST have a souce IP addres under the gateways prefix. I.e. it will not work for IPv4, wher…

Yes, this solution is very much a hack... I do not think it is needed.

> - The next step is perhaps to introduce Proxy RREPs (AODV, i.e. gateway impersonates external hosts when sending RREP, see the old globalv4/MIPv4 draft) or to use default routes (e.g. OLSR). Here y…

I agree.  This is a separate issue from the forwarding and there are
several ways to do it. However, I think a proxy RREP solution is very
attractive.

> What I have yet to understand (and this is why I initiated this discussion on "default routes") is the reason for default routes: i) Is it necesary ii) can it enhance routing performance of externa…

I think it is neither. I have played around with default routes. With
reactive protocols it is my strong belief that they give more problems
than they solve. It is clear that you can't use a generic routing entry
with a reactive protocol and multiple gateways without adding extra
state. It quickly becomes a mess...

> With tunneling, on the contrary, we have only one single problem: How to make the routing protocol robust.

agreed.

/Erik

---

From: Richard Ogier <[email-masked]>
Date: Thu, 04 Mar 2004 15:44:00 -0800

>shortest path to the gateway but this will only work with proactive

Philippe,

You and I are not talking about exactly the same solution. What I am
proposing does not require multiple retransmissions or waiting long
enough to collect the shortest path.
The proposed gateway discovery protocol computes the min-hop
route to the gateway using distance vectors. I.e., it computes an
"upstream neighbor", which should stay the same as long as the topology
does not change. Thus, there is no need for retransmitting the info
several times or waiting long enough to collect the shortest path.
Instead, a node periodically sends its GW_INFO message if and only if
its "upstream neighbor" is an MPR selector.  This guarantees min-hop
paths.
As I noted before, for this to work, the "upstream neighbor" must be
chosen consistently, e.g., by using node ID to break a tie when there
are multiple possible upstream neighbors.

Regards,
Richard

>>>>Maybe I am missing something (and please point it out), but will not
>>>>
>the
>
>>>>rooted at a gateway will not be able to change gateway/prefix unless
>>>>
>its
>
>>>>>I am not convinced that you have maximum flexibility when building
>>>>>
>your
>
>>>>>individually choose another gateway? But, I admit, I need to study
>>>>>
>your
>
>>>>>draft in more detail.
>>>>>
>>>>>announcing some nodes as gateways. Nodes can then individually choose
>>>>>
>a
>
>>>>>>changes can cause trouble during a very small amount of time. The
>>>>>>
>main
>
>>>>>>France). I am also finishing some simulations in which we evaluate
>>>>>>
>our
>
>>>>>>simulations of the tunnel approach you have probably seen that
>>>>>>
>results
>
>>>>>>>default routes? Especially with reactive protocols that do not have
>>>>>>>
>a
>
>>>>>>>how will you deal with hand-overs between gateways? You say  that
>>>>>>>
>the
>
>>>>>>>different gateways) that want to change the default route -->
>>>>>>>
>gateway
>
>>>>>>>mapping?
>>>>>>>
>>>>>>>gateways and are transparent for intermediate nodes that forwards
>>>>>>>
>the
>
>>>>>>>traffic to the gateway. I have a paper pending that clearly shows
>>>>>>>
>the
>
>>>>>>>>field in the packet used to disseminate the prefix information.
>>>>>>>>
>This
>
>>>>>>>>gives the prefix length). Moreover, we "almost" don't need a
>>>>>>>>
>routing
>
>>>>>>>>Of course on the reverse path this is not the same (i.e. the
>>>>>>>>
>gateway
>
>>>>>>>>>>gateway : there is no need of a routing header, and default
>>>>>>>>>>
>routes
>
>>>>>>>>>>can be used safely.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>slightly different context, but during mobility and several hops
>>>>>>>>>
>to
>

---

From: "HyunWook Cha" <[email-masked]>
Date: Fri, 5 Mar 2004 11:40:39 +0900

Hello, Guilaume.

On-demand solicitation/advertisement should be performed periodically to
extend address lifetime and update bidirectional reachability whether
packets to be forwarded toward Internet exist or not. IMHO, reactive
routing protocol is reactive because it perform route discovery only
when valid route entry needed for forwarding does not exist. In this
sense, I think that separate protocols can be more adequate for reactive
routing protocols since routing protocols can still behave for its
original purpose. If I am wrong, please enlighten me. 

Regards,

HyunWook    

-----Original Message-----
From: Guillaume Chelius [mailto:[email-masked]] 
Sent: Thursday, March 04, 2004 7:40 PM
To: [email-masked]
Cc: 'manet'
Subject: Re: [manet] Why GW discovery should not be separated from
reactive routing protocols?

Hello,

> Could you tell me why GW discovery should not be separated from 
> reactive routing protocols? IMO, periodic gw solication/advertisement 
> seems to be proactive.

Regards,
Guillaume.

---

From: Justin Lipman <[email-masked]>
Date: Fri, 5 Mar 2004 14:00:42 +1100

Hi HyunWook,

I agree. I think from the reactive approach, there is plenty of existing 
approaches sensor network and information collection literature which can be 
used to build reactive approaches to determining the existence of gateways, 
determining the best gateways to be used and necessary paths...

Kind regards,
Justin

-- 
Research Associate
Smart Internet Technology Cooperative Research Centre
http://www.titr.uow.edu.au/~justin

---

From: "HyunWook Cha" <[email-masked]>
Date: Fri, 5 Mar 2004 15:27:14 +0900

Hello,

Please find my inline comments.

> Behalf Of Erik Nordstr?
> Sent: Friday, March 05, 2004 4:30 AM
> Subject: Re: SV: Re: SV: Re: SV: RE: [manet] Default Routes (Intern)
> 
> 
> 
> > By simple reasoning, I drew more or less the same 
> conclusions as you 
> > did. But I am not 100% sure, since we have not tested the 
> differences between the "ideal" to-way-tunneling and 
> one-way-tunneling. (In fact, we tested both, based on your 
> AODV-UU code, thanks!, but we have not made any proper comparizons.)
> > 
> > My current standing is that the "ideal" Internet access 
> mechanism, as 
> > far as routing is concerned, is tunneling in both 
> directions: source routing (IPv6) or encapsulation (IPv4) of 
> outbound traffic via the gateway and encapsulation of inbound 
> traffic from gateway to MANET node (IPv4 and IPv6). From 
> there you start to make optimizations to save bandwidth etc., 
> and each optimization resembles a "hack", i.e. it undermines 
> the ideal model.
> >  

What is ideal and what is hack?  It depends on your thought? 

> 
> Tunneling in both directions is OK, but I am not sure I would 
> call it "ideal". It is just one solution, and I believe 
> one-way is enough. But it is not such a big deal I think.
> 

IMO, to enforce all inbound traffics to be encapsulated is hack !!!
What makes you think that route entries for global addresses assigned to
MANET nodes should not be maintained inside the MANET? I do not see any
reason. If gateway obtains valid route entry for a destination node's
global address, it can forward packets as they are. Unnecessary
encapsulation is useless, wastful and it can cause packets to be dropped
when size of encapulated packets are greater thatn MTU in case of IPv6.
I believe that encapsulation should be used only when valid route entry
for global address does not exsit and valid route entry for MANET local
address is available and it is guaranteed that two addreeses point the
same node.

> > - The next is perhaps your proposal to "rewrite" 
> destination addresses at the GW, as you seem to propose (It 
> does not sound good, IMHO. I think we have to accespt that we 
> might need NAT for outgoing IPv4 traffic, but I hope you do 
> not need it for incoming traffic as well.)
> 

If you want to use NAT for only outbound traffic(but not for inbound
traffic) and encapsulation for inbound traffic, communication is not
possilbe. The reason is that a node does not know its external address
which is used as destination address in inbound traffic and even if it
knows, existing upper layer (TCP/UDP) can not recognize that inbound
traffics belong to the session bound to internal address.   

> I am not sure what you mean here... I did not propose to 
> rewrite the destination address except for the src->gateway 
> encapsulation (depending on what encapsulation method you 
> choose). I agree that NAT is a good target, but can be 
> problematic with multiple gateways (i.e., keeping consistent 
> NAT states). Mobile IP is the best solution for seamless 

Right. Could you handle gateway handover using NATs?    

> > - Another alternative is to use source-address-based routing. This 
> > "hack" means that all outgoing traffic MUST have a souce IP addres 
> > under the gateways prefix. I.e. it will not work for IPv4, where you

> > use private/IPv4-link-local address with NATs or home-address with a

> > MIP-FA based gateway. It will also exclude every future IPv6
protocol 
> > that might need to use a source address that is not topologically 
> > correct for any gateway - i.e. this solution is also a "hack".
> 

Soure address based forwarding assumes that source address is globally
routable and configured dinamically from a gateway. Just forget
private/ipv4 link local with NATs!!! Corporation with MIPv4 has never
been considered by me. In this case, sender node has no choice but
encapsulation from it to FA gateway because it knows that source address
based default routing is not available because of absence of gateway
advertisement from HA gateway. 

As you know, all global addresses configured statefully/statelssly from
routers are alway topological correct. I think that we have same goal.
Packets should be forwarded to right exit gateway according to source
address. Right?

> > - The next step is perhaps to introduce Proxy RREPs (AODV, i.e. 
> > gateway impersonates external hosts when sending RREP, see the old 
> > globalv4/MIPv4 draft) or to use default routes (e.g. OLSR). Here you

> > might introduce routing race conditions, and also race conditions 
> > between MANET nodes that have preference for using 
> different gateways but who are communicating with the same external
host.
> 
> I agree.  This is a separate issue from the forwarding and 
> there are several ways to do it. However, I think a proxy 
> RREP solution is very attractive.
> 

Whe source address based forwarding is used, MANET nodes that have
preference for using different gateways but who are communicating with
the same external host can do what they want. Actually intermediate
nodes does not have to maintain default route entry(/0) but gateway
information list as well as route entry(/128) for gateways. 

I am not familiar with globalv4/MIPv4 draft. However I want to know that
proxy RREPs works well under multiple gateways or not, and how to
configure global addresses. 

> > - And so on...
> > 
> > What I have yet to understand (and this is why I initiated this 
> > discussion on "default routes") is the reason for default 
> routes: i) 
> > Is it necesary ii) can it enhance routing performance of external 
> > traffic iii) or is it simply an optimization (or "hack") to save 
> > bandwidth.
> > 
> 
> I think it is neither. I have played around with default 
> routes. With reactive protocols it is my strong belief that 
> they give more problems than they solve. It is clear that you 
> can't use a generic routing entry with a reactive protocol 
> and multiple gateways without adding extra state. It quickly 
> becomes a mess...
> 

This depends on implementation of default route forwarding. I can not
understand why you are considering default route forwarding using prefix
continuity or source address based forwading. Please give careful
comments on two drafts.(Do not say "hack" before you can prove that
clearly.)   

HyunWook Cha

---

From: Christophe Jelger <[email-masked]>
Date: Fri, 05 Mar 2004 09:46:29 +0100

Richard,

I think we all agree that gateway discovery and prefix announcement can 
be integrated into a proactive routing protocol. Again I'd like to 
re-state that we clearly say that in the draft ... ;-) At least that 
seems to be a first consensus.

I also just want to re-state that we first decided to propose the idea 
without integrating the concept in any routing protocol ... this is (in 
its current state) why we can have different routes between our 
standalone process and the routing protocol. Of course the final 
objective when we integrate it in OLSR is to "merge" everything (e.g. 
unique neighbors table and neighbor discovery mechanisms).

Finally, I know that there has already been a lot of discussions on 
"should we have something like prefix continuity, or can we just mix 
nodes and don't bother about that ?". I'm not sure that's something we 
should decide, because it will mainly be a matter of deployment. If an 
operator (at a large sense) wants to deploy an ad hoc network, it should 
be able to choose whether it wants prefix continuity or not (as it can 
choose between different types of routing protocol). I think our task is 
to propose solutions, and people just decide (or not) to use them. Of 
course I like prefix continuity, but not just because we (sort of) 
proposed that. I really think it's something people will like in their 
deployment, it can be really useful in a number of situations 
(management, accounting, load balancing).

Regards,
Christophe

Richard Ogier wrote:

>> implemented it as a stand-alone process to check the operation. As 
>> you know, we plan to integrate it into OLSR. (see below for a last 
>> comment)
>
>
> <SNIP>
>
>>
>> algorithm : always choose closest gateway. In that case the route is 
>> a shortest route, but it can be different than the shortest route 
>> algorithm "prefix stability", then the route might not be optimal 
>> (I'm currently simulating this and it appears that routes are not 
>> much longer on average).
>>

---

From: Erik Nordström <[email-masked]>
Date: Fri, 05 Mar 2004 12:35:18 +0100

> IMO, to enforce all inbound traffics to be encapsulated is hack !!!

Why would this be a hack? Tunneling is an established mechanism. Do you
have a good argument for this?

> reason. If gateway obtains valid route entry for a destination node's

Tunneling does not totally exclude global (non-adhoc) addresses in the
MANET. Routing entries for global addresses still have to be maintained
at end nodes. It just simplifies the routing, and you achieves route
aggregation since you can share a tunnel among many addresses. In the
AODV case, there is also no need to maintain sequence numbers for routes
to global destinations since it maps to the gateway route. This would
not be the case if you "import" global addresses/routes into the ad hoc
network.

> Right. Could you handle gateway handover using NATs?    

I guess, if you tunneled traffic from your "old" gateway to the new one.
Of course, there would have to be some extra signaling between the
gateways.

> configure global addresses. 

Proxy RREPs works with multiple gateways. A source node gets multiple
replies and can chose the best route (i.e., based on hop count or
something else).

As for the global address, why would you need to configure one? In the
NAT case you can use your home address or a link local. With MIP you
would use your home address in the ad hoc network and the gateway/FA
would just rewrite the packet with the care-of-address. No address
configuration is necessary as long as you have a unique home address.
For those that don't have a valid home address, you can just configure a
link local address.

> comments on two drafts.(Do not say "hack" before you can prove that

Prefix continuity is fine but clearly has limitations, since (all) nodes
can't chose gateways by themselves. I am not sure what you mean with
source address based forwarding. Do you select your default route based
on source address? In that case you need to maintain a lot of extra
state and you have no route aggregation which is mainly what default
routes are for. Correct me if I am wrong.

/Erik

---

From: Christophe Jelger <[email-masked]>
Date: Fri, 05 Mar 2004 13:03:52 +0100

Erik,

Just a few comments: see below in the text ...

CHristophe

>not be the case if you "import" global addresses/routes into the ad hoc
Route aggregation ? Well usually route aggregation is for the routing 
table ... and if you don't use a default route it means you will still 
have a routing entry for each destination. The "next hop" entry will be 
the same tunnel, but still you have one entry per destination. This 
doesn't really look like route aggregation ... but maybe did you mean 
something else ?

>For those that don't have a valid home address, you can just configure a
With IPv6 each MANET node will need a global address, unless you allow 
to route and forward link local addresses (fe80::/64). That's why there 
was once a proposal to use a site-local MANET prefix ... there is also a 
proposal from Guillaume Chelius and Eric Fleury (ANA6) that tries to 
solve this issue (routing without a global address). In general when you 
want Internet connectivity you'll need a global address.

>routes are for. Correct me if I am wrong.
I won't call that a limitation ... the objective is to maintain prefix 
continuity, not to allows nodes to choose whatever prefix they want. In 
the later case it's best to use a solution that uses tunnels (or routing 
header with IPv6). Would you call IPv6 stateless autoconf "a limitation" 
because it gives the same prefix to all nodes of a subnet ? To me it's 
just doing fine what it has been designed for ... ;-)

---

From: Erik Nordström <[email-masked]>
Date: Fri, 05 Mar 2004 13:16:32 +0100

> just doing fine what it has been designed for ... ;-)

Ok, limited applicability? I agree that if prefix continuity is fine if
that's what you want.

And yes, stateless autoconf can be a limitation since it does not allow
you to easily switch between gateways (and maintain your connections).
MIP would be better for that (or a combination). But it does not mean it
is not useful for what it was design for. Which I do not believe were ad
hoc networks and multiple gateway scenarios. Rather as an alternative to
DHCP? 

/Erik

---

From: Richard Ogier <[email-masked]>
Date: Fri, 05 Mar 2004 09:24:56 -0800

Christophe Jelger wrote:

> Richard,
>
> I think we all agree that gateway discovery and prefix announcement 
> can be integrated into a proactive routing protocol. Again I'd like to 
> without integrating the concept in any routing protocol ... this is 
> (in its current state) why we can have different routes between our 

My point is that your draft proposes a specific mechanism based on
distance-vector routing to determine the route to a gateway. OLSR uses
a different mechanism based on link-state routing to determine the
route to every node.  You have not said how you plan to "merge"
everything, but even if you do, it is still redundant to have these two
different mechanisms.  If you want prefix continuity, this can be
done using link-state routing, by having each node advertise its
prefix, and having each node compute a source tree for each prefix.
If you are claiming that it is better to use distance vector routing
to achieve prefix continuity, that is possible, but it *might* also
be better to use distance-vector routing (instead of link-state routing)
for proactive routing.  But the WG has decided to use link-state
routing for proactive routing, so for consistency it would be good to
use link-state routing for gateway discovery and prefix continuity,
if possible.

However, a valid reason for using distance-vector routing is to have
a common mechanism that can be used for both proactive and reactive
routing. This is because OLSR-style link-state routing is not
useful for computing routes to only a *few* nodes (e.g., gateways),
but distance-vector routing is ideal for this. (Which is why
it is also used for landmark routing.) As a side note, source-tree
based routing algorithms (such as TBRPF) are also useful for computing
routes to only a few nodes, since each node only needs to advertise
links on its shortest path to each such node.
BUT, it is not necessary to use the same mechanism for both proactive
and reactive routing (and such a mechanism would be redundant for
proactive routing).

> operator (at a large sense) wants to deploy an ad hoc network, it 
> should be able to choose whether it wants prefix continuity or not (as 
> it can choose between different types of routing protocol). I think 
> our task is to propose solutions, and people just decide (or not) to 
> use them. Of course I like prefix continuity, but not just because we 
> (sort of) proposed that. I really think it's something people will 
> like in their deployment, it can be really useful in a number of 
> situations (management, accounting, load balancing).

It seems to me that prefix continuity makes load balancing more
difficult. (In any case, load balancing does not require prefix
continuity.) Correct me if I am wrong, but my understanding is that
only nodes on the boundary between two prefix islands can choose
between two gateways with different prefixes.  Nodes in the interior
of a prefix island know only about the gateway(s) with the same
prefix, and thus cannot use another gateway for load balancing.
Is that correct?

Regards,
Richard

>
>
> Regards,
> Christophe
>
> Richard Ogier wrote:
>
>> Christophe Jelger wrote:
>>
>>> Guillaume,
>>>
>>> Just on point, see inline my comment. In general I agree that 
>>> gateway discovery should not be separated, as stated in the draft. 
>>> We first implemented it as a stand-alone process to check the 
>>> operation. As you know, we plan to integrate it into OLSR. (see 
>>> below for a last comment)
>>
>>
>>
>> <SNIP>
>>
>>>

---

From: "Zhensheng Zhang" <[email-masked]>
Date: Fri, 5 Mar 2004 09:56:05 -0800

CALL FOR PAPERS

BroadNets 2004
Broadband Wireless Networking Symposium

October 25-29, 2004, San Jose, California, USA
http://www.broadnets.org

BroadNets 2004 is a new conference focusing on broadband networking and
covers the entire gamut of next generation networks with ultra-high
bandwidth available all the way from access networks, to regional and
metropolitan networks, to wide-area core networks.  Broadband Wireless
Networking that is defined to cover   high-speed wireless networking for
access, regional and backhaul networks including backhaul capacity
provisioning using wireless, including the WLAN networks and WMAN.
.BroadNets 2004 will thus offer a unique forum for researchers from
academia, government, and industry to share ideas and disseminate new
results in these important areas.  We are soliciting full papers in all
research, development, and deployment areas on broadband wireless
networking.  Papers of particular merit will be considered for a special
issue of ACM/Kluwer Mobile Networks (MONET) Journal.

Topics
Full papers are solicited in all research and applied areas related to
broadband wireless networking.  Topics include, but not limited to:

Ø	 3G/4G Systems
Ø	 Fixed Broadband Wireless Access
Ø	Wireless Local Area Networks
Ø	WLAN Hotspots
Ø	Wireless indoor & home networks
Ø	Wireless Personal Area Networks including IEEE 802.15
Ø	 IEEE 802.16 (WiMax) Standards Activities and Products
Ø	 Wireless Metropolitan Area Networks
Ø	Wireless Wide Area Networks
Ø	Free-Space Optics
Ø	Ultra Wideband (UWB) Networks
Ø	Ad-hoc networks
Ø	System architecture
Ø	Network Topology management
Ø	Neighbor discovery
Ø	Unicast and multicast routing
Ø	Quality-of-Service support
Ø	Security techniques and systems
Ø	Resource management
Ø	Software-defined radio
Ø	Space-time processing, MIMO systems
Ø	Digital signal processing
Ø	Smart (directional) antennas
Ø	Power control
Ø	Wireless emergency systems
Ø	Standards, Licensing and regulation
Ø	Interference mitigation for multiple access
Ø	Economics and business cases 

Important Dates
·	Submission Deadline:	March 15, 2004
·	Acceptance Notification:  	June 7, 2004
·	Final Manuscript Due:	July 7, 2004

Submission Instructions
Authors are invited to submit full papers of up to 20 double-spaced pages,
including references, figures, and tables.  All submissions should be
submitted electronically in Postscript or Adobe PDF format through the EDAS
submission system at http://edas.info/Conferences.cgi.
Proposals for Workshops, Tutorials, and Panels
Proposals for workshops, tutorials, and panels on broadband wireless
networking and related topics are solicited. Workshop proposals should
consist of: 1) title of the workshop, 2) description of potential audience,
3) description of the workshop topic and justification of why the proposed
topic is interesting and timely and, 4) intended format of the workshop.
Tutorial proposals should consist of: 1) title and outline of materials to
be presented, 2) description of potential audience, 3) justification of why
the proposed topic is interesting and timely and, 4) biographical sketch of
the presenter(s). Panel topics should address innovative, controversial, or
otherwise provocative issues of interest related to broadband wireless
networking and communications. Workshop proposals should be submitted to the
appropriate chair by March 15, 2004.  Tutorial and Panel proposals should be
submitted to the appropriate chairs by May 1, 2004.
Exhibits and Sponsorship Opportunities
For information on exhibit space or sponsorship opportunities at BroadNets
2004, please contact the Exhibits and Sponsorships Chairs.
Organizing Committee
 
Symposium Chair
Zhensheng Zhang, San Diego Research Center	
[email-masked]

Technical Program Chairs
Parameswaran Ramanathan, Univ. of Wisconsin-Madison, [email-masked] 
Thomas Hou, Virginia Tech,  [email-masked]

---

From: [email-masked]
Date: 6 Mar 2004 21:19:16 +0100

Hi HyunWook Cha,

Comments inline:

On  2004-03-05 13:03:52 CET Christophe Jelger wrote
>>>What is ideal and what is hack?  It depends on your thought? 

I agree with you that it is difficult to draw a clear line, so let's not argue over words... (However, if you want to know my thought: According to my terminology, a "hack" is a solution that imposes additional requirements on the network that *significantly* narrows the room for improving technology in the future. E.g. NAT is a hack that changes the rules of the networking, by requiring all traffic be initaited from one side, and IP-layers protocols (e.g. IPSec and MIP) be transparent to changes in IP-addresses (and portnumbers  - for NAPT). The result of a "hack" is normally new "hacks", e.g. MIP-over-UDP-tunnels or IPSec-over-UDP, to circumvent the additional requirements imposed by the previous hack.)

>>>IMO, to enforce all inbound traffics to be encapsulated is hack !!!

According to how I defined a "hack" above, it is probably not...but again let's not argue over words. It was stupid of me to use a negatively loaded word. I am not saying that encapsulating inbound traffic is a good solution. I only say that it is the "cleanest" solution. Probably we will need to do optimisations to make things more efficient. There is a tradeoff between making it clean and making it efficient, and I am not sure exactly where to draw the line. That is what I intend to find out.

>>have a good argument for this?

Agree with Erik.

>>>reason. If gateway obtains valid route entry for a destination node's

Take AODV as an example, how does gateways maintain destination sequence numbers on behalf of external nodes? And how does the gateways cooperate to maintain sequence numbers. I remember that some version of the AODV-draft (maybe the RFC) proposed co-operation between gateways, but in my opinion this is not a desireable way to go.

>>not be the case if you "import" global addresses/routes into the ad hoc

<...>

>>>Right. Could you handle gateway handover using NATs?    

Using MIP with NAT-traversal is probably the most straightforward solution, but the additional overhead of 28bytes only for the NAT-traversal part is not insignificant on a MANET. (In fact, we have discussed implementing this, just to see how it works.) The upside is that you could probably use off-the-self MIPv4 code in co-located mode and with NAT-traversal, and I assume it would work without major changes. I believe that other MIP-for-MANET solutions proposed, on the contrary, would need special-purpose code that would differ significantly from regular off-the-shelf MIPv4. 

>>Of course, there would have to be some extra signaling between the

Yes, Erik, that might be another option... None of them seems ideal, though...

<...>

Paal

---

From: [email-masked]
Date: 6 Mar 2004 22:14:27 +0100

Erik,

> replies and can chose the best route (i.e., based on hop count or

It works, but whether it works "fine"or not is probably a matter of definition ;-)

The problem is that it easily leads to routing race conditions. For example, if you have two gateways that are located an equal number of hops away from the MANET node, both gateways will return the same Proxy RREP (assuming that both gateways use the same gateway-independent rules for setting the sequence number, and thus return the same sequence number.)

Every time the outgoing route needs to be re-discovered due to link breaks or route-timeouts, the outgoing route is determined by the first Proxy RREPs that reaches the MANET node or the intermediate node where the return routes of the two Proxy RREPs meet. The outgoing route may shift between the two gateways in a non-deterministic way. If there are NATs present, the performance can be discouraging.

We have both done tests and simulations on this issue, and the results so far does not yet convince me that Proxy RREP is a solution without significant problems. You might have different experiences?

Paal

---

From: "HyunWook Cha" <[email-masked]>
Date: Mon, 8 Mar 2004 03:40:28 +0900

Hello, Paal and all.

My comments below.

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; "Christophe Jelger" <[email-masked]>;
"Erik Nordström" <[email-masked]>
Cc: "'manet'" <[email-masked]>
Sent: Sunday, March 07, 2004 5:19 AM
Subject: Re: SV: RE: [manet] Default Routes (Intern)

Hi HyunWook Cha,

Comments inline:

>>>What is ideal and what is hack?  It depends on your thought?

I agree with you that it is difficult to draw a clear line, so let's not
argue over words... (However, if you want to know my thought: According to
my terminology, a "hack" is a solution that imposes additional requirements
on the network that *significantly* narrows the room for improving
technology in the future. E.g. NAT is a hack that changes the rules of the
networking, by requiring all traffic be initaited from one side, and
IP-layers protocols (e.g. IPSec and MIP) be transparent to changes in
IP-addresses (and portnumbers  - for NAPT). The result of a "hack" is
normally new "hacks", e.g. MIP-over-UDP-tunnels or IPSec-over-UDP, to
circumvent the additional requirements imposed by the previous hack.)

[HW]
Ok, I understand what you mean by "hack". However, IMO, we have not analyzed
existing solutions fully until now, so it is not suitable time to say what
is ideal or hack. I agree that tunneling in both directions are simple and
do not cause any problem, but I do not think that that is efficient and has
no room to optimize and any effort to do that are just hack. I do not want
to argue over words, either.

>>>IMO, to enforce all inbound traffics to be encapsulated is hack !!!

According to how I defined a "hack" above, it is probably not...but again
let's not argue over words. It was stupid of me to use a negatively loaded
word. I am not saying that encapsulating inbound traffic is a good solution.
I only say that it is the "cleanest" solution. Probably we will need to do
optimisations to make things more efficient. There is a tradeoff between
making it clean and making it efficient, and I am not sure exactly where to
draw the line. That is what I intend to find out.

[HW]
>From your definition about "hack", you are right. Tunneling itself is not
hack, but the strict requirement that inbound traffics should be
encapsulated is not desirable as I mentioned before.

Agree with Erik.

>>>reason. If gateway obtains valid route entry for a destination node's

Take AODV as an example, how does gateways maintain destination sequence
numbers on behalf of external nodes? And how does the gateways cooperate to
maintain sequence numbers. I remember that some version of the AODV-draft
(maybe the RFC) proposed co-operation between gateways, but in my opinion
this is not a desireable way to go.

[HW]
Why gateways care about seq no for external nodes?  Are you considering
about proxy RREP based solution? In the most of existing drafts including
globalv6 related this issue, route entries for external nodes are not needed
for outbound traffics and only ones for gateways to be passed are demanded
whether default routes are used for forwarding or not. Do you concern about
updating route entry for gateways by inbound traffics? Right, unencapsulated
inbound traffics can not do that. However, periodic gateway
solicitation/advertisement exchanges between MANET nodes and gateways and
unsolicited gateway advertisements from gateways can prevent from degrading
performance of bidirectional communications like TCP sessions. Other
thoughts?

Regards,

HyunWook

>>>Right. Could you handle gateway handover using NATs?

Using MIP with NAT-traversal is probably the most straightforward solution,
but the additional overhead of 28bytes only for the NAT-traversal part is
not insignificant on a MANET. (In fact, we have discussed implementing this,
just to see how it works.) The upside is that you could probably use
off-the-self MIPv4 code in co-located mode and with NAT-traversal, and I
assume it would work without major changes. I believe that other
MIP-for-MANET solutions proposed, on the contrary, would need
special-purpose code that would differ significantly from regular
off-the-shelf MIPv4.

>>Of course, there would have to be some extra signaling between the

Yes, Erik, that might be another option... None of them seems ideal,
though...

<...>

Paal

---

From: "HyunWook Cha" <[email-masked]>
Date: Mon, 8 Mar 2004 04:25:35 +0900

Hello, Eric and Christophe.

My comments below;

----- Original Message -----
From: "Erik Nordstr?" <[email-masked]>
To: "Christophe Jelger" <[email-masked]>
Cc: "'manet'" <[email-masked]>
Sent: Friday, March 05, 2004 9:16 PM
Subject: Re: SV: Re: SV: Re: SV: RE: [manet] Default Routes (Intern)

> > >routes are for. Correct me if I am wrong.

Right. A sender node select a default route to send a packet according to
its global source address. The node already maintain default gateway list to
configure and maintain its global addresses. It does not require additional
state. Also, additional route entries for Internet nodes (=external nodes)
are not needed since this approach has same effect as default route
forwarding execpt that actual forwarding is based on route entry for
corresponding gateway with source address.

> > just doing fine what it has been designed for ... ;-)

Christophe, IPv6 stateless autoconf does not prohibit that multiple global
addresses are configured and used by a node. When two addresses are
available, one address can be used as HoA and the other as CoA to preserve
transport session or load balancing. When multiple addresses are allowed,
source address based forwarding is a solution which has same effect as
"prefix continutity" since it can demultiplex corresponding gateway with
source address without routing header/tunneling.

Regards,

HyunWook

---

From: Cedric Adjih <[email-masked]>
Date: Wed, 24 Mar 2004 04:48:16 +0100

On Friday 12 March 2004 21:46, Li Li wrote:
> If a MID message is received from a non-symmetric neighbor, we'd discard
> the message. Why is this? For security reasons? If we don't discard the
> MID, what're the negative impacts?

Hello Li Li,

The issue you are rising, is indeed subtle ;-): the reason MID message
processing discards packets from non-symmetric neighbors
(same for TC, and HNA), is mainly for simplicity reasons.

It was introduced when OLSR protocol presentation was clarified
and simplified around draft-version-8:
. the problem is that even if you process messages from non-symetric
neighbors, the "default forwarding algorithm" won't put them
in the duplicate table. As a result, the negative impact is
that you could process the same MID twice. Actually, if the
network is static, and there is no packet loss, you
will also receive it from some symmetrical neighbor,
so you would process it at least twice. Not satisfying :-)
. if you want to prevent this, you have to add some flags in
the duplicate table, and complicate the processing/forwarding
algorithm a little bit. Well, it was decided that somehow,
maybe the potential gain was not worth it.

Hope this helps,
Regards,
-- Cedric

---

From: Li Li <[email-masked]>
Date: Wed, 24 Mar 2004 09:46:53 -0500

Thanks a lot! Cedric. It does help to explain for me. 

Li Li

---

From: Guillaume Chelius <[email-masked]>
Date: Thu, 04 Mar 2004 11:21:56 +0100

Hello,

Since Richard is quoting my mail of last year, I just want to reexpress 
my opinions on the subject. I think that the gateway discovery process 
(and prefix advertizement in IPv6) is deeply bound to the routing 
mechanism. As it has already been said many times, by myself and by 
others, the mechanism can be easily integrated into a proactive routing 
protocol. It requires the definition/addition of few flags/fields and 
would not only reduce the load induced by a separate gateway 
advertisement protocol but also set up an interesting adequation between 
the reactivity of the routing protocol and the advertizement frequency 
of gateways. Who wants to receive gateway advertizements every 2 seconds 
if routes are only refreshed  every 5 seconds (or the opposite)?

In the case of a reactive protocol, as Richard and Joe already said it, 
it could be usefull or interesting to design a proactive gateway 
advertizement protocol. The two gateway advertizement modes of operation 
(proactive or reactive) present different advantages and may be applied 
in different situations:
  - proactive: constant load (independant of the number of nodes 
accessing the Internet).
  - reactive: linear load in the number of nodes accessing the Internet.

In conclusion, I think there is no need for a separate gateway/prefix 
advertizement protocol when a proactive routing protocol is used. It 
would be a waste (medium use) not to include it in the routing protocol. 
In the case of a reactive protocol, things are different as proactive 
advertizement can still be usefull.

To go on with the discussion, I think the main issue is the following: 
should we impose or not gateway/prefix continuity.
  - with gateway/prefix continuity: routes are not optimal; routes to 
the gateway and routes to the Internet through the gateway may differ as 
they are computed respectively by the routing protocol and by the 
advertizement mechanism; defalt routing may be used to join the Internet.
  - without gateway/prefix continuity: routes are potentially optimal 
(depending on the routing protocol); necessity to use tunneling/source 
routing.

If we give an answer to this question, other issues and implementations 
will be more straightforward.

Regards,
Guillaume.

---

From: Thomas Noel <[email-masked]>
Date: Fri, 5 Mar 2004 09:16:51 +0100

Richard,

>   IF we decide we need

I'm a co-author of draft draft-jelger-manet-gateway-autoconf

Just to clarify the situation why do you doubt about prefix continuity ?

Regards

Thomas

---

From: Christophe Jelger <[email-masked]>
Date: Thu, 04 Mar 2004 12:37:34 +0100

Guillaume,

Guillaume Chelius wrote:

> Hello,
>
> Since Richard is quoting my mail of last year, I just want to 
> reexpress my opinions on the subject. I think that the gateway 
> discovery process (and prefix advertizement in IPv6) is deeply bound 
> to the routing mechanism. As it has already been said many times, by 
> myself and by others, the mechanism can be easily integrated into a 
> proactive routing protocol. It requires the definition/addition of few 
> flags/fields and would not only reduce the load induced by a separate 
> gateway advertisement protocol but also set up an interesting 
> adequation between the reactivity of the routing protocol and the 
> advertizement frequency of gateways. Who wants to receive gateway 
> advertizements every 2 seconds if routes are only refreshed  every 5 
> seconds (or the opposite)?
>
> In the case of a reactive protocol, as Richard and Joe already said 
> it, it could be usefull or interesting to design a proactive gateway 
> advertizement protocol. The two gateway advertizement modes of 
> operation (proactive or reactive) present different advantages and may 
> be applied in different situations:
> would be a waste (medium use) not to include it in the routing 
> protocol. In the case of a reactive protocol, things are different as 
> proactive advertizement can still be usefull.
>
> the gateway and routes to the Internet through the gateway may differ 
> as they are computed respectively by the routing protocol and by the 

With prefix continuity, routes are optimal if we use the "distance" 
algorithm : always choose closest gateway. In that case the route is a 
shortest route, but it can be different than the shortest route computed 
by the routing protocol. On the other hand, if we use the algorithm 
"prefix stability", then the route might not be optimal (I'm currently 
simulating this and it appears that routes are not much longer on average).

>
> If we give an answer to this question, other issues and 
> implementations will be more straightforward.
>
> Regards,
> Guillaume.
>
> Richard Ogier wrote:

---

From: "Pedro M. Ruiz" <[email-masked]>
Date: Thu, 04 Mar 2004 10:29:04 +0100

Hi Guys,

Completely agree with both of you on this issue. I think there is a 
clear interest on the topic, and we should move forward defining a clear 
problem statement, and then proposing "agreed" solutions.

Regards, Pedro

---

From: Anders Nilsson <[email-masked]>
Date: Wed, 03 Mar 2004 11:36:51 +0100

Hello again,

Christophe Jelger wrote:

> they just announce prefixes. If two gateways announce the same prefix, 
> an ad hoc node selects the closest gateway (it can be specified that 
> it should from there use the same gateway). The propagation method 
> used to propagate the prefix information ensures that the path to the 
> gateway is made of nodes that also use the same gateway : there is no 
> need of a routing header, and default routes can be used safely.
>
That sounds like a good solution, but the node can't control what 
gateway it is currently using. A scenario where this is neeed is when 
the node is moving from gateway to gateway. The node is then unable to 
know what gateway it is currently communicating through. A node need to 
know this when it switches to a new gateway, and "registers" itself. 
This reason why this needed is because packets from the Internet needs 
to be routed to the correct gateway, which is difficult when mobile 
nodes are unware of its gateway. If a Cellular IP type of solution is 
used, the routing entries in the access network are updated by the 
actual packets flowing through the gateways. But there is problems here 
as well, because oscillations easily occurs that causes a lot of 
updates, especially when the mobile nodes are mobile. I have simulated 
this, and it is harder to maintain than you might think. If you rely on 
proactive gateway discovery, the default routing entries have to be 
maintained during link breaks and mobility, along with sequence number 
maintainence. I have a paper about this, in a slightly different 
context, but during mobility and several hops to the gateway, more 
complex control is needed.

regards,

Anders

---

From: Li Li <[email-masked]>
Date: Fri, 12 Mar 2004 15:46:17 -0500

Thanks for any insights,

li li
Li Li, Ph.D
Communications Research Centre, Industry Canada
3701 Carling avenue 
P.O. box 11490 
Station H, Ottawa, 
Ontario, Canada K2H 8S2 
Tel: (613) 990-5246 
Email: [email-masked]

---

From: "HyunWook Cha" <[email-masked]>
Date: Thu, 4 Mar 2004 11:18:59 +0900

Hello, Anders.

> From: Anders Nilsson [mailto:[email-masked]] 
> Sent: Wednesday, March 03, 2004 7:05 PM
> To: [email-masked]; manet; [email-masked]
> Subject: Re: Default Routes (WAS: Request of Comments on the 
> i-d ietf-cha-manet-aodv-internet-00.txt) 
> 
> 
> 
> Hello,
> 

Do not tell that every other drafts are just variants from your drafts
which have only negligible contribution, and have made just confusions
to implementors. You must analyze what issues are targeted in their
drafts and how efficiently they can be resolved before you told that
efforts by others are harmful. 

> Please point out what you think is wrong.

I did not say that I wrote my drafts since yours is wrong. I like other
authors want to see other ways to get the goal. 

> >next hop forwarding and require that a sender specifies a gateway in

I mean that your draft proposes default route as well as routing header
for AODV. However, you authors prefers to the use of routing header
because of several reasons including one mentioned by Paal. However,
since many other authors do not like this overhead in all data packets,
many alternative approaches have come out. My draft adopts source prefix
based routing as you mentioned below and Christophe's tries to keep
"prefix continuity".
   
> > - Ingress filtering: Outbound packets escaping out through 
> "wrong" gateways 
> > are filtered out.
> 
> moving inside the network, it will probably want to switch to 
> different gateways as they become closer. The only way for this to
work in the 

> good solution. 

Right. I do not address gateway handover issue in this draft. 
This issue is very important component in Internet connectivy support. 
I do not think that current address should be changed with new address
to communicate through a closer gateway since this is harmful for
tranport layers. 
I also support registration based mechanism for tunneling from old
gateway for inbound traffic and to old gateway/peer node for outbound
traffic. 
To do that, multiple addresses can be configured and used for a MANET
interface simultaneously. 
Although MIPv6 is indispensable for macro-mobility, I think that MANET
specific registration method is helpful for micro-mobility. 
I proposed reactive registration scheme incorporating(deeply coupled)
with AODV in my draft named "extended support for MANET internet
connectivity". 
Without MIPv6, this method can keep active session in which address from
old gateway is involved as source address going through tunneling. 
In addtion, this approach can prevent frequent inefficient end-to-end
signalling (RO in MIPv6) by hiding unreliable MANET topology. For
example, this can enable MIPv6 to decide handover time according to
urrent available(and reachable directly) gateway set while active
sessions are kept alive. I will write more detail related to this issue
in revised version. 

If the different gateways belong to the same 
> domain, it 
I am interested in this point. Could you explain what this scenario is
for? For load balancing? Do you use proxy-nd?

Regards, 

HyunWook

---

From: "HyunWook Cha" <[email-masked]>
Date: Thu, 4 Mar 2004 16:43:07 +0900

Hello, Paal.

I am sorry that I am now in Daejon not Seoul. Please see my inline
comments. 

> Behalf Of [email-masked]
> Sent: Wednesday, March 03, 2004 11:06 PM
> To: Christophe Jelger; manet
> Subject: SV: Re: [manet] Default Routes (Intern)
> 
> 
> Christophe,
> 
> It seems I triggered some discussion that passed me by, but 
> let me cut into this thread and response to your preference 
> for default routes.
> 
> > > - Ingress filtering: Outbound packets escaping out 
> through "wrong" gateways 
> > > are filtered out.
> > 
> Here I think Anders gets to the core of the matter - i.e 
> destination based routing: Many nodes communicating with the 
> same external host cannot share the same destination-based 
> route and still get to different gateways.
> 

For an external node, a route entry can not be discovered to be shared
by all packets destined to the node.  

> The first is lean and mean, and works in nearly any 
> networking scenario, and with any routing protocol.
> 

I do not see any problem a source address based default forwarding in
corporating with routing protocols if forwarding routine in IP layer can
be extended.

> The functionality of the second is obscure, it is less clean 
> than the tunneling solution, and probably makes routing more 
> complicated. In addition, you bind internet access together 
> with address autoconfiguration, which reduces the level of modularity.
> 

I think that the second method is not obsure, though forwarding function
needs additional processing(almost one hash for searching gateway list +
one more lookup for matched gateway's route entry). However, tunneling
or routing header also require additional processing in IPv6 module
since an extension header has been added after all. In addition, routers
(Internet gateways) are given additional workload which is decapsulation
or swpping between destination header and routing header entry.  

In tunneling based method, tunnel end point is determined for a given
source address in packet. Difference between two methods, packet
overhead for existing destination forwarding infra or extending
forwarding functionality instead of packet overhead. For fast
deployment, the former is better, I agree.   

> Since the latter solution resembles a hack (as compared to 
> the clean tunneling solution), I also think it might lead to 
> unforseen problems sooner or later. For example, if I would 
> use it in an IPv4 setting, it would obviously not work. 
> (Default routes is not a good idea, at least not with IPv4, 
> and should never have been accepted in the experimental RFCs, IMO).
> 

I do not understand what this scenario is for and the problem is. Could
you tell me?

Regards,

HyunWook

> I think I am willing to pay the little extra overhead of 
> tunneling to get a simpler, modular, and more robust solution.
> 
> Paal
>

---

From: Christophe Jelger <[email-masked]>
Date: Thu, 04 Mar 2004 11:03:33 +0100

Please see my comments inline.

>"route optimization". I think that this approach is also
OK you are right, one could find some rules in order to use a default 
route. However this is slightly contradictory with the basic routing 
approach : there is a route, therefore I use it ! ;-) I think this is 
something that is maybe more related to routing, so people of AODV and 
DSR are better placed to decide whether they want to do something like 
that or not. I don't really bother, I just prefered not to do so.

(more below)

>route. 
If there is a break, downstream nodes are not informed in an active way. 
They have a timer associated with the upstream neighbor entry. If it 
does not send updated information within a short period of time (we 
chose a default value of 3*2 seconds, 2 seconds being the period at 
which this information should be updated), the entry is removed, and the 
node chooses a new upstream neighbor. Maybe we could use a more clever 
mechanism to detect link breaks, but in this case there is a probability 
to detect "false" breaks.

>Thus, RERR for the gateway may not be issued. If different

---

From: [email-masked]
Date: Fri, 5 Mar 2004 03:18:43 -0500

<Apologies if you receive this message multiple times>

CALL FOR PAPERS

Complete CFP at http://academic.udayton.edu/DucTran/research/dms2004.htm

Special Session on MULTIMEDIA STREAMING IN AD HOC NETWORKS
at the 2004 International Conference on Distributed Multimedia Systems 
(DMS '04)
Hotel Sofitel, San Francisco Bay, California
September 8 - 10, 2004

Important Dates 
 
        March 31, 2004   Paper submission due 
        June 1, 2004     Notification of acceptance
        July 1, 2004     Final manuscript due
        July 1, 2004     Early conference registration due

---

From: [email-masked]
Date: 3 Mar 2004 10:30:44 +0100

Ryuji,

Paal