Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D

From: Greg Daley <[email-masked]>
Date: Fri, 29 Jul 2005 13:49:44 +1000

Hi JinHyeock,

I've got my chair hat off and my blast goggles on:

It looks like you've been doing some welding...
----- Original Message -----
[cut]
> > How much faster is it than the MN soliciting
> > itself?
> 
> Main difference between MN soliciting and AP soliciting is that, 
> with the latter, we can realize a scheme (similar to Hash based 
> FastRA) in a simpler way. 
> 
> We can assume that an AP knows all the ARs in a link. 
> So AP can send UNICAST RS (to remove random delay) 
> and solicit ARs in turns (for load balancing). 

This would require (small) modification to RFC2461, as
routers mandatorily perform 0-500ms backoff, regardless
of the destination address of the RS.

Also, you definitely need modified routers, but I guess
that's handled by TSLLAO.

> When a new host is attached to the AP, 
> AP can sends an unicast RS to a chosen AR 
> 1) with unspecified source address 
> 2) with the host's MAC address in TSLLAO. 
> 
> Upon receiving the unicast RS,  
> the AR can send an RA immediately 
> (because it is solicited in unicast).
> in unicast (using TSLLAO)  
> 
> Also AP take turns to solicit ARs, 
> such as this time AR1 next time AR2 
> to achieve load balancing. 
> 
> Hence no load balancing mechanism is needed 
> in ARs. 

This is actually using the hackiest part of TSLLAO ;)
In some devices it won't be possible to modify the 
outbound MAC address of the packet on the router, but 
it seems in this environment, you could either discover
the ones which handle the TSLLAO, or mandate modified
routers.

Should we leave that part in the TSLLAO draft for
the moment then? :)

> > Surely the same logic is needed for the AP or there would be 
> > collisions if there are multiple routers on the link.
> 
> Yes, AP needs some logic (but simpler one, in my opinion) and 
> for hosts and routers, only TSLLAO is needed. 
> Other than that there is nothing to change in them. 
>
> How do you think of it? 

I think that if protocols were in a beauty contest, it would
be the ugliest cheetah around.

It's really not possible to tell how much simpler it is, though.
The APs need to track a list of all routers, some of which may
not be trusted at L3 (Do they do SEND?).  In each of the ARs,
the RA delivery scheme needs to be modified (TSLLAO w/o Ncache, 
Delay removal for Unicast RS).

In other schemes, ARs need to track other DNA routers. In
each of the ARs, modifications to the RA delivery scheme are
needed (TSLLAO, delay + scheduling modification, unicast response).

Greg

---

From: Syam Madanapalli <[email-masked]>
Date: Fri, 29 Jul 2005 11:35:08 +0530

Hi Greg,

[cut]
> of the destination address of the RS.

The random delay is to avoid simultaneos access to the medium,
in this case there is only one router that is sending an RA. However
all implementations may not do that, in such cases we need the 
modification.

> that's handled by TSLLAO.

Yes. Also TSLLAO is not required all the time, in such cases 
the router would send multicast RA.

> not be trusted at L3 (Do they do SEND?).  

APs either can be manually configured or can be learnt from RAs.
I am thinking that APs/Base Stations are more trustable nodes.
Are you saying the APs may be trustable at L2 but not at L3?
I do not know much about SEND, but I think it can be used if
required.

> In each of the ARs,