Subject: [mobile-ip] MIPv6 Handover Coverage Area Transition Issues

From: James Kempf <[email-masked]>
Date: Wed, 26 Sep 2001 15:44:22 -0700 (PDT)

All,

Last week, Rajeev Kooldi and I had a very productive discussion in which
I thought we had pretty much nailed down the technical interoperability issues 
involved in transitioning between areas in which the ARs support different
MIPv6 handover algorithms. This week, the basic issue of handover coverage
area transition has been raised yet again.

The major issue that seems to have arisen this week is including some
notification of the handover algorithm supported in the standard MIPv6
Router Advertisement and Solicitation for Router Advertisement. The
issue was that this is unnecessary and wastes network bandwidth. 

Below, I've attached a description of how a transition could work without
having any modification to the Router Advertisement or Solicitation
for Router Advertisement. All notification of transition would occur
through FMIPv6 signaling. There is only one "bad case:" a network-initiated
handover from an FMIPv6 AR to a BETH AR. The network must first
establish whether the MN is a standard MIPv6 node or is FMIPv6/BETH
capable before it can perform BETH, otherwise, it may conclude that
the MN can't do BETH and a potential for optimization will be lost. 

I am interested in hearing some feedback on this, but I would like it
to be constructive and focused at improving the transition protocol
so that it is simpler, while still maintaining the promising optimization
potential of the various algorithms. Baiting, flaming, and other such tactics
will result in my hitting the "Delete" button, as they should for
every participant in every IETF list. I am interested in achieving
closure on this so that we can move forward with the spec.

Thanx.

		jak
		
-------------------------------------------------------------------------------
This is a proposal about how to handle transitions between coverage
areas providing different optimized handover support with a minimum
of notification to the MN. Transitions from/to each kind of coverage
area are considered. The proposal is based on using the FMIPv6
expanded usage of the message code field, which already is used for notifying 
the MN of particular kinds of handover.

Note: SMIPv6 stands for "Standard MIPv6" handover.

1) BETH -> SMIPv6

AR sends MN a PrRtAdv with code SMIPV6-HANDOVER.

MN uses SMIPv6 movement detection. MN solicits a RtAdv if it can
determine when it is on the new AR, otherwise waits for the unsolicited
RtAdv.

2) SMIPv6 -> BETH

The handover from the last SMIPv6 AR to the first BETH/FMIPv6 AR
is done using the SMIPv6 movement detection.

Handover to the next BETH router is done according to 5).

3) SMIPv6 -> FMIPv6

Same as 2).

4) FMIPv6 -> SMIPv6

Same as 1).

5) FMIPv6 -> BETH

Two cases: network initiated and mobile initiated.

    a) Network Initiated:
	AR sends PrRtAdv to MN with code BETH-HANDOVER.
	   
           i) If MN is BETH capable, it supresses all 
	      handover related radio traffic until it
	      needs a new CoA. ARs take care of handover.

	   ii) If MN is not BETH capable, it sends an
	       F-BU and the network continues to do
	       FMIPv6 handover.

	   iii) Concern: The MN would have to do at
		least *one* FMIPv6 handover before
		the AR could distinguish between
		a BETH capable MN and one that
		was not capable of doing FMIPv6
		at all, because there is no signaling
		back from the MN for the AR to distinguish
		between:

		  - A MN that is BETH capable and is
		    supressing handover related signaling
		    because it knows the network will
		    handle it.

		  - A completely nonFMIPv6 MN that is
		    incapable of responding to FMIPv6 messaging.

		We could solve this problem by having the
		MN issue a PrRtSol for the old AR when it
		came up in the network and include the code BETH-HANDOVER,
		and have AR respond with a PrRtAdv with its own
		address. This would avoid having to put this
		information into the RtAdv. 

    b) Mobile Initiated:
	MN sends SolPrRtAdv to old AR with code BETH-HANDOVER.

	i) If new AR is BETH capable, old AR replies with 
	   PrRtAdv having code BETH-HANDOVER. MN supresses
	   handover related signaling until it needs a new CoA.

	ii) If new AR is not BETH capable, old AR replies
	    with PrRtAdv having code FMIPv6-HANDOVER. MN
	    continues FMIPv6 handover.

6) BETH->FMIPv6

Essentially, this works the same as in 5), except the code is
FMIPv6-HANDOVER. 

Network-initiated:

	The old AR issues a PrRtAdv for the new AR with code
	FMIPv6-HANDOVER.

	The MN begins doing FMIPv6 handover, i.e. issues an F-BU
	when on the new AR, etc.

Mobile-initiated:

	The MN issues a SolPrRtAdv for the new AR with code
	FMIPv6-HANDOVER.

	The old AR replies with PrRtAdv with code FMIPv6-HANDOVER.

	Thereafter, the MN/AR does FMIPv6 handover.

7) nonFMIPv6 capable 

If an FMIPv6 AR sends a PrRtAdv to an MN that has not established
that it is BETH capable and it receives no F-BU, the network
MUST suppress sending further FMIPv6 signaling over the air
and allow the MN to do SMIPv6 handover.

If an FMIPv6 MN sends a SolPrRtAdv to an AR and it gets no
PrRtAdv in response, it MUST suppress sending further FMIPv6
signaling over the air and do SMIPv6 handover.