Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac hes

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Fri, 6 Oct 2000 20:03:46 +0200

> I am aware of this and am not disagreeing.
> My point is that the registration can be done before the Mobile
> gets the L2 message informing it to handoff. Thus we require
> interworking between L2 and L3 on the network-side (which is
> needed anyway) such that L3 registration can occur at the same
> time as L2 signalling and such that the L2 handoff message is
> sent after the L3 registration. As I wrote in my reply to Pete,
> this is what is summed up in point 2) of the list of differences
> sent out.
> >> Can you please be more specific and provide some example
> in context of
> any present or future wireless network ? Please provide some messaging
> information and mention
> how L3 registartion will be done before L2 handoff is
> complete. To me it
> looks like
> that you are assuming too many things which is not be doable in a real
> system.

The point is that any further specification of the above interaction
of L2/L3 would bring in L2 issues specific to a certain wireless/cellular
system which is what we decided was out of scope. I think that the
above explanation is quite clear.
What is it that we are assuming that is so unrealistic?
I definitely think our assumptions are no less realistic than
those in the Proactive draft, if that is what you meant.

/Karim

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 6 Oct 2000 11:09:15 -0700

> above explanation is quite clear.

We need to be careful in setting the scope. In my opinion, what is out of
scope is a solution that cannot work with known wireless technologies.

PatC

---

From: Ajoy Singh <[email-masked]>
Date: Fri, 6 Oct 2000 13:58:17 -0500

The point is that any further specification of the above interaction
of L2/L3 would bring in L2 issues specific to a certain wireless/cellular
system which is what we decided was out of scope.

<<AS> I was not asking you to specify these detail in fast handoff.
Does out of scope mean that any claim about link layer is possible ? <AS>

I think that the

<AS> You are trying to make sure that you will have enough
time, after link layer handoff is detected, to do everything as
specified in section 4 of fast handoff draft before mobile goes out of
range. <AS>

<AS> In proactive draft, we are not making any claim to register
with mobile node through the old access point before link layer
handoff is complete. We are just talking about some link layer trigger, even
fast
handoff draft talks about that. In quick handoff draft(personal id submitted
by Sebastian and me), we have specified how we can get link layer trigger
without making lot of changes in current L2 technologies. The details are
not included
in proactive draft because of the scope of the mobile/IP protocol. <AS>

-----Original Message-----
From: IP Routing for Wireless/Mobile Hosts (mobile-ip)
[mailto:[email-masked]]On Behalf Of Karim
El-Malki (ERA)
Sent: Friday, October 06, 2000 1:04 PM
To: [email-masked]
Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff
approac hes

/Karim

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 6 Oct 2000 12:27:26 -0700

I have a comment on draft-ietf-mobileip-reg-tunnel-03.txt, section 4.1, which
reads:

4.1. Regional Registration Flag

   The Agent Advertisement message MAY include a flag indicating
   whether the domain, to which the foreign agent generating the Agent
   Advertisement belongs, supports regional registrations.  The flag
   is inserted in one of the reserved fields, after the flags defined
   in [9].

   The flag is defined as follows:

      I          Regional registration.  This domain supports Regional
                 Registration as specified in this document.

When I implemented this feature, I ended up using a bit that was free
according to [9] (RFC 2002). Unfortunately, as I am adding Reverse Tunneling
support, I see that the bit I had randomly chosen (given the rather vague
directives above) conflicts with Reverse Tunneling.

Could the authors of the above I-D add some clearer directives to implementors?
 Thanks,

PatC