Subject: [mobile-ip] Low Latency MIPv4 Handoffs: PreReg Complexity

From: Jonathan Wood <[email-masked]>
Date: Fri, 2 Nov 2001 13:23:27 -0800 (PST)

In general the proposal is significantly complicated by specifying
multiple ways of doing things. Specifically:
1 FAs may (or may not) cache advertisements from other FAs. This
  means that (per section 3.3) MN soliciations are either unicast
  to the oFA or the nFA. How does the MN know which method it should
  use? What if the MN decides to unicast to oFA for a proxy advert,
  but oFA isn't caching adverts from nFA?
2 It is often hard to determine exactly which messages under what
  circumstances must contain which extensions. For example,
  Section 3.3 also states that "The PrRtAdv message MAY contain the
  nFA's L2 address (using the LLA extension in 7.2)". When should the
  L2 address extension be present? What are the ramifications of not
  including it?
3 Section 3.4 lists three different ways of obtaining nFA
  advertisements. This seems likely to cause interoperability problems.
  For example, what if FA1 expects all agent advertisements to
  be piggybacked on L2 messaging, while FA2 does not? They will
  not be able to exchange advertisements, and therefore will not
  be able to complete PreReg handovers between them.

I think if the proposal came up with just one way of obtaining agent
advertisements, a lot of complexity would fall out.

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Mon, 5 Nov 2001 18:29:26 +0100

>   but oFA isn't caching adverts from nFA?

In 3.3., 3.41. and 3.5 it says that the FAs SHOULD cache the
advertisements. I'll run through to check for inconsistencies. The
solicitation to nFA was meant for the case in which there was no caching.
I was making some changes and wanted to clarify in 3.3 that the MN SHOULD
unicast solicitation to oFA. Unicasting to nFA would have been the fallback
for those cases where caching is impossible. However this fallback doesn't
seem to add much so I'd like to remove it altogether. Would this
solve your concern?

>   L2 address extension be present? What are the ramifications of not

That part says:

   "The PrRtAdv message MAY
   contain the nFA's L2 address (using the LLA extension in 7.2) as
   described in sections 3.7 and 3.8."
 
Actually it's sections 3.6 and 3.7 which describe when it is to be used.
These sections should answer your questions. I'll look through to
sort out any places where the use of extensions is unclear. 

>   be able to complete PreReg handovers between them.

3.4.1 and 3.4.2 each apply to different cases. 3.4.1 is for source
triggered or mobile initiated. 3.4.2 instead is for target triggered.
I'll read it through to make this clear if it isn't. 3.4.3 instead
doesn't add much so I propose to take that away. This should solve the
issue.

In general we have not considered FA capability discovery since
it is quite complex and the draft is complicated enough as is. In the new
version we'll clearly state that this is outside the scope. So it is assumed
that the FA capabilities are manually configured to be compatible
and a separate mechanism could be used for autoconfiguration.

Hope this solves a good part of your concerns.

/Karim

---

From: Jonathan Wood <[email-masked]>
Date: Mon, 5 Nov 2001 17:48:43 -0800 (PST)

> seem to add much so I'd like to remove it altogether. Would this

It would help. It would also mean that FAs MUST solicit from each
other and cache aderts, and MNs MUST unicast solicitations to oFA,
right?

> sort out any places where the use of extensions is unclear. 

I think I'm quibbling about whether the PrRtAdv's inclusion of
the GLLA L2 ext should be a MAY or MUST. This depends on the
defition of a PrRtAdv (as discussed in a seperate email).

> doesn't add much so I propose to take that away. This should solve the

Taking away 3.4.2 would be good. I also recommend you frame 3.4.1
and 3.4.2 not as alternate ways of obtaining adverts, but rather
as one for source triggered and mobile initiated, and the other for
target triggered.

> Hope this solves a good part of your concerns.

It should help. I'll look forward to the next version of the draft.

Jonathan

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Tue, 6 Nov 2001 17:51:27 +0100

> On Tue, Nov 06, 2001 at 02:24:29PM +0100, Karim El-Malki (ERA) wrote:
> > I meant MNs MUST unicast solicitations to oFA and FAs SHOULD do
> > message 1a/b in advance and cache. The inter-FA soliciting and
> > advertising SHOULD be done in advance with caching unless there's a
> > good reason not to. In the latter case it becomes part of 
> the handoff
> > sequence and could add latency as described in the current text.
> 
> If neighboring FAs cache their advertisements, how do you 
> deal with stale 
> challenges???

If the challenge-response is used then the idea was to have inter-FA
solicitations frequently enough so that the cached challenge has not
expired and the MN has a chance of registering. It's explained in the
current draft (3.5) but there were some inaccuracies so I've just
updated that part.

/Karim