Subject: RE: [mobile-ip] Low Latency MIPv4 Handoffs: Coverage Area Transit ion

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

> How are transitions to and from PrePreg coverage areas handled?
> What should the FAs do, and more importantly, how should the MN
> know when it has entered and left PreReg coverage areas?

Wouldn't expect someone to build PRE-REG plus POST-REG areas and
allow movement between the two. There's the common method which I like
since it makes PRE and POST work together. Don't know if that was what
you meant. If instead you are considering PRE-REG to RFC2002 then it
depends on mobile/network initiated. The MN doesn't have an active
role in network-initiated so there would be no difference. In
mobile-initiated the MN will either not get the L2-MT trigger, so
no soliciting happens, or the PrRtSol doesn't receive a reply
which means that in both cases the MN follows RFC2002 when it connects
to nFA. The new failure recovery section should handle these cases
and the FA behaviour, which basically involves doing RFC2002.

/Karim

---

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

> since it makes PRE and POST work together. Don't know if that was what

Sorry - I am referring to PRE-REG to / from RFC2002.

> and the FA behaviour, which basically involves doing RFC2002.

First I should call out one place where it looks like we may have
differing assumptions. I assert that the MN MUST know whether or
not it is in a PRE-REG or rfc2002 coverage area, since the actions
it takes on movement detection will be different. For rfc2002, a
MN typically on receipt on an advert will flush L2 caches and
routing tables, add a default and host route through the FA, and
send a registration reply. For PRE-REG, however, the MN will on
receipt of a PrRtAdv will send a registration request to nFA (via
oFA), and then *do nothing* until it gets a link up trigger. Only
then should it adjust routing and L2 caches, since if it does this
earlier it will disrupt communications while still on oFA's link.

Now, let's break the analysis into two parts: entering a PRE-REG from
rfc2002 coverage area, and departing a PRE-REG to rfc2002 coverage
area.

When entering a PRE-REG area, how does the MN know that it is now
in a PRE-REG area? Is it expected to infer this from the receipt of
a PrRtAdv? If so, how does one distinguish a PrRtAdv? It appears that
the only way to do this is by the presence of a GLLA extension. Section
3.3, however, states that the inclusion of the GLLA L2 extension
is only a MAY - perhaps it should be a MUST? Also, this means that
FAs must always include the GLLA L2 extension in all their adverts,
since they don't know who is soliciting them - probably good text
for a FA considerations section.

I guess another way you might be able to distinguish a PrRtAdv is by
looking at when it arrived. For example, if an advert shows up before
the link-down trigger and it belongs to a different FA than the current
FA, than it must be a PrRtAdv. Either way, this should be made clear in
the spec.

When departing a PRE-REG area, you suggested that the MN can tell it
is leaving by the absense of the L2-MT trigger, or the lack of a reply
to PrRtSol. How does the MN differentiate between a failure and a
departure from a PRE-REG domain? Or does it *not* differentiate, and
just use whatever detection method it used to entering a PRE-REG area?

Jonathan

---

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

> send a registration reply.

It would do that after it received a registration reply. I guess that's
what you meant.

> For PRE-REG, however, the MN will on

True, in the current draft the L2-UP is necessary in addition to
the registration reply. In a previous email on the relaying regreplies
thread I proposed to have the reply only sent to the new link.
That would mean that the normal MN behaviour would apply (which is what
was meant in the beginning) since the receipt of a successful registration
reply would make the MN change default router etc.

> FA, than it must be a PrRtAdv. Either way, this should be 

I'd go for the PrRtAdv (with LLA extension) since the timing may be
tricky. The LLA would be a MUST.

> just use whatever detection method it used to entering a PRE-REG area?

If MN doesn't get a PrRtAdv after it attempts PrRtSol a few times or if it
receives a normal agent adv. in the absence of PrRtSol then it MUST do
RFC2002. The choice of mov. detection method is a separate issue which could
depend on the performance on the network in question. PRE-REG specifies being
eager to register and that should be viable also in an RFC2002 network. That
may not be a perfect fit for all networks. If an MN is intelligent and can
adapt its movement detection if it sees something wrong then all the better.

I'll put in some text on the MN considerations for RFC2002/PRE-REG movement
issues if people find the above is appropriate.

/Karim

---

From: Jonathan Wood <[email-masked]>
Date: Tue, 6 Nov 2001 12:53:21 -0800 (PST)

> It would do that after it received a registration reply. I guess that's

Actually the MN can set the default route whenever it wants after it
gets an advert; so far as I can tell rfc2002 is silent on the matter
and it makes little difference. The implementation I am using sets
the default route after getting the advert and before sending the
registration request (yes I typoed above - s/reply/request/). This
is significantly different for PRE-REG, where it is critical the
default route is not reset until the MN is on the new FAs link. (You
do touch on this in section 3.6.) 

> reply would make the MN change default router etc.

I mostly agree - However I think it is important to point out that
normal rfc2002 MN behavior does not apply on receipt of the registration
reply during PRE-REG handover. While this may fall in the catagory of
implementation details, it does shed light on the MN modifications
needed for PRE-REG needed for many platforms...

For normal rfc2002 MNs, you must set up a host route to the FA and add a
L2 cache entry for the FA before sending the registration request, or
else the request will not make to the FA. As discussed above, the MN
has some latitude for setting the default route. On receipt of a
registration reply, a MN may not have anything more to do with routing.

During PRE-REG, MNs must not set up a host and/or default route to nFA
before sending the registration request. All routing and L2 cache
updates must be done after the link up trigger (or possibly the following
registration reply - does it matter?)

> tricky. The LLA would be a MUST.

I agree.

> adapt its movement detection if it sees something wrong then all the better.

Sure. I think we just need to make sure that the minimum rules needed to
ensure interoperability are present in the spec. Just saying that the
MN should be eager to register might be a bit too loose.

Jonathan

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Wed, 7 Nov 2001 16:56:23 +0100

> do touch on this in section 3.6.)

I don't think RFC2002bis is silent on this. It says the following under
MN considerations (4.2.1):

  When registered on a foreign network, the mobile node chooses a
  default router by the following rules:

     -  If the mobile node is registered using a foreign agent care-of
        address, it MAY use its foreign agent as a first-hop router.
     .....

From the above I understand that the MN chooses the default router
once registered and MAY use the FA with which it is registered. When a MN
has an active registration and receives another agent advertisement it
shouldn't immediately change default router. It has to do movement detection
and wait until a successful registration goes through before making routing
changes. Otherwise any ongoing communication (through the current FA) would
be disrupted since the new FA shouldn't let traffic through (to and from MN)
until it gets the successful reply.

/Karim