Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue #4)

From: James Kempf <[email-masked]>
Date: Wed, 11 Jul 2001 12:15:12 -0700 (PDT)

Gary,

Seems like the arrival of the first packet, if it is being tunneled from
oAR, is predicated on the handover signalling being completed between
oAR and nAR, correct?

		jak
		
>Delivered-To: [email-masked]
>From: "Gary Kenward" <[email-masked]>
>To: "'Pat Calhoun'" <[email-masked]>
>Cc: "'Nakhjiri Madjid-MNAKHJI1'" <[email-masked]>, 
"[email-masked]'" <[email-masked]>, [email-masked]
>Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,  
RE: Issue #4)
>Date: Wed, 11 Jul 2001 15:00:32 -0400
>
>Pat:
>
> The oAR does not need to know when the first packet arrival
>at the newAR may occur. Indeed, for proactive to be effective,
>the oAR must initiate a ct based upon an event that is only indicates
>a possible handover.
>
>  Here is the scenario: the MN traffic is passing through, say, AR3.
>The RF subsystem (aka the link layer, aka L2) "determines" (through L1/l2
>mechanisms) that AR5, AR19, and AR11 are potential candidates for handover.
>AR3 receives an event from L2 that instructs it to transfer context to
>AR5, AR19, AR11. The three "target" ARs in this example are thus ready to
>receive a handover of the MNs traffic, if it is required to maintain the
>traffic flow. Note that this approach does not completely prevent the MN
>from unexpectedly appearing in the coverage domain of a different AR - 
>that's the nature of wireless, however, it goes a long way to improving
>the situation.
>
>  Nothing in the above refers to a deadline event. Of course, it is 
>the objective to have the context in place before it is needed at the
>new AR. But ct must still work if this deadline is not met, and, because
>we all know how unpredictably handovers can be, the requirements and
>design should explicitly address this situation. In other words, in
>wireless handover, the exception is the rule.
>
>  As I have stated, I want to change that text to clarify that ct completion
>before the first packet arrival is a goal, not a requirement. Or, perhaps,
>it is a SHOULD, not a MUST.
>
>Gary
>
>Note: the ct scheme we are working on is a little different then that
>described above, but hte principle is the same. I did not want to get into
>all the details in this email.
>
>> -----Original Message-----
>> From: Pat Calhoun [mailto:[email-masked]]
>> Sent: Wednesday, July 11, 2001 10:34 AM
>> To: Kenward, Gary [WDLN2:AN10:EXCH]
>> Cc: 'Nakhjiri Madjid-MNAKHJI1'; [email-masked]';
>> [email-masked]
>> Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
>> comments) (SHOULD
>> be , RE: Issue #4)
>> 
>> 
>> If we end up deciding that we want to keep most of the current
>> text, I will follow the WG's desire, but I do have some
>> concern with the fact that it currently uses the arrival of
>> a packet destined for the MN as the main difference between both
>> modes of operation. My issue here is in source triggers (meaning oAP
>> initiates CTP), oAP has no way of knowing when the first packet will
>> be received, and therefore doesn't know whether a proactive or
>> reactive CTP should be initiated. This is why I am convinced that this
>> is just informational, and not a protocol thing.
>> 
>> PatC
>> 
>> On Wed, Jul 11, 2001 at 10:20:20AM -0400, Gary Kenward wrote:
>> > Madjid:
>> >  
>> >    I'm glad you feel this way. I guess this discussion 
>> began as a result of 
>> > Issue #4, which proposes an alternate wording.
>> >  
>> >     After a few exchanges with Cedric, I reviewed the 
>> current text, and
>> > I realized that it indicates that proactive is deadline 
>> driven, which I
>> > really
>> > believe is a bad thing to require.  All I want to ensure is 
>> that there is a 
>> > capability with ctp to start a ct sometime before the 
>> actually traffic
>> > handover
>> > is initiated. Why? Because there are many networks that 
>> provide "warnings"
>> > that a handover may be imminent (actually, most RF systems 
>> can be designed
>> > to do this, and should). How? Well, the actual trigger 
>> event will change
>> > depending upon the L2 design, but typically, the mechanism 
>> starts with the
>> > base receiver sensing transmission from a mobile, and then 
>> usually many
>> > other 
>> > mechanisms that kick in to identify the mobile at L1/L2.
>> >  
>> >    So, I would also like to keep the current text, for the 
>> same reason. I
>> > would
>> > like to remove the deadline, or at least change it so that 
>> it is clearly a
>> > desirable
>> > deadline, but not a requirement (we cannot make it a 
>> requirement because the
>> > physics
>> > of wireless handover make the timing of any forewarning 
>> event completely un-
>> > predictable).
>> >  
>> >    Maybe I've said this all before, and maybe my view is 
>> clear to everyone.
>> > Sorry
>> > for being repetitive.
>> >  
>> > Gary
>> >  
>> > 
>> > -----Original Message-----
>> > From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
>> > Sent: Tuesday, July 10, 2001 6:37 PM
>> > To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]';
>> > [email-masked]
>> > Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
>> > 
>> > 
>> > Gary,
>> >  
>> > I don't think we should remove the reactive/ proactive 
>> definitions out of
>> > requirement, unless there is a consensus for removing it.
>> >  
>> > If we nobody can come up with a better definition than the already
>> > existing one, either we keep it or declare it as an open issue.
>> >  
>> > Personally I liked the definitions that are based on the 
>> starting event
>> > such as link establishment better, but I still can live 
>> with the exiting 
>> > one (packet arrival) for the time being. Removing the whole thing
>> > is throwing a lot of good thoughts away.
>> >  
>> > A requirement subject to modifications is better than no 
>> requirement.
>> >  
>> > Madjid
>> >  
>> >  
>> > 
>> > -----Original Message-----
>> > From: Gary Kenward [mailto:[email-masked]]
>> > Sent: Tuesday, July 10, 2001 8:53 AM
>> > To: [email-masked]'; [email-masked]
>> > Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
>> > 
>> > 
>> > 
>> > John: 
>> > 
>> >    I have been contemplating removing the "reactive"/"proactive" 
>> > definitions from the requirements also, but I really do hope we 
>> > do not lose the concept of starting ct as early as possible. Being 
>> > proactive with ct has been a fundamental component to ct since the 
>> > problem statement draft, and, to me, a critical tool for providing 
>> > seamless service handover. 
>> > 
>> >    There are those who, rightfully, have no interest in proactive 
>> > ct for their networks. If we lose the requirement, it may be very 
>> > difficult for the wg to proceed with a ctp design that supports 
>> > this mode. 
>> > 
>> >    I'll wait for your issue to be generated. Some of us are also 
>> > struggling with some alterative wording of the definitions 
>> > 
>> > Gary 
>> > 
>> > > -----Original Message----- 
>> > > From: [email-masked] [ mailto:[email-masked]
>> > <mailto:[email-masked]> ] 
>> > > Sent: Tuesday, July 10, 2001 1:59 AM 
>> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked] 
>> > > Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) 
>> > > 
>> > > 
>> > > Hi Gary, 
>> > > 
>> > > >  I agree, particularly with your definition of ct (although I'm 
>> > > > not sure where "reductive mode" came from). 
>> > > 
>> > > 
>> > > Ooops, I meant that I was in "reductive mode" (trying to 
>> > > simplify & get back to the basics).  
>> > > 
>> > > > In thinking through the overall discussion, I am 
>> realize that the 
>> > > > big difference between "reactive" and "proactive" is 
>> how they are 
>> > > > triggered. "proactive" assumes that there is a trigger 
>> available 
>> > > > early on that permits some context transfer in advance 
>> of an actual 
>> > > > handover. 
>> > > 
>> > > I agree. My thoughts are that the discussion of reactive 
>> and proactive 
>> > > (& triggering, etc.) get quite close to protocol design.  I think 
>> > > that is one reason that the discussion became so heavy on the 
>> > > the requirements. 
>> > > 
>> > > >   I do believe the current wording for proactive is 
>> wrong. Now that 
>> > > > I have had time to contemplate the wording, it does not 
>> define what 
>> > > > I have always believed proactive ct should be about. I'm hoping 
>> > > > that if we fix that wording, we can move on to the 
>> important part 
>> > > > of designing ctp. 
>> > > 
>> > > My suggestion would be to cut-out of the requirements 
>> document the 
>> > > discussion about proactive & reactive text.  I will try 
>> to make an 
>> > > issue for this later in the day. 
>> > > 
>> > > thanks, 
>> > > John 
>> > > 
>> > 
>>

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 11 Jul 2001 15:17:52 -0400

James:

 Sure, but this presumes a specific handover solution.

Gary

> From: James Kempf [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2001 3:15 PM
> To: [email-masked]; Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments) (SHOULD
> be , RE: Issue #4)
> 
> 
> Gary,
>

---

From: James Kempf <[email-masked]>
Date: Wed, 11 Jul 2001 13:14:36 -0700 (PDT)

Right, well, then at least for this particular solution we seem to agree there 
is a need for a total ordering on handoff signaling and CT. Namely, that
handoff signaling must happen before CT. Not to rule out there might be other 
solutions where no ordering occurs.

Given this, it seems like the implementation consequences of separating
CT and handover signalling are the following. If nAR doesn't know first that a 
handover is going to happen and a CT packet arrives first, it must set
a timer and wait until the handover signaling arrives. If the handover
signaling doesn't arrive until the timer pops, nAR discards the CT.
If it does, nAR completes the handover by replying back to oAR and
installing CT. Then  awaits the arrival of the MN on the new L2.

Does this make sense?

		jak

>To: "'James Kempf'" <[email-masked]>, [email-masked]
>Cc: [email-masked], [email-masked], 
[email-masked]
RE: Issue #4)
>Date: Wed, 11 Jul 2001 15:17:52 -0400
>
>James:
>
>> comments) (SHOULD be ,  
>> comments)

---

From: [email-masked]
Date: Thu, 12 Jul 2001 11:42:44 +0300

Hi James,

> Right, well, then at least for this particular solution we 
> seem to agree there is a need for a total ordering on handoff 
> signaling and CT. Namely, that handoff signaling must happen 
> before CT. Not to rule out there might be other solutions 
> where no ordering occurs.
> 
> Given this, it seems like the implementation consequences of 
> separating CT and handover signalling are the following. If nAR 
> doesn't know first that a handover is going to happen and a CT 
> packet arrives first, it must set a timer and wait until the
> handover signaling arrives. If the handover signaling doesn't 
> arrive until the timer pops, nAR discards the CT.

I guess I should read all of the mails in my inbox before responding!
I think that this makes a lot of sense, and further more, this 
can be used to get rid of 'stale' context as well.

br,
John

---

From: [email-masked]
Date: Thu, 12 Jul 2001 11:50:59 +0300

Hi Pat,

> 
> >   As I have stated, I want to change that text to clarify 
> > that ct completion before the first packet arrival is a goal, 
> > not a requirement. Or, perhaps, it is a SHOULD, not a MUST.
> 
> Right but using the above example, there is *nothing* the protocol
> can do to ensure this happens. This is network engineering, wireless
> technology capabilities, etc.
> 
> So, this requirement is kind of moot, since we agree that the protocol
> doesn't care, and the packet would be identical regardless of whether
> the CT occurred prior to the arrival of the first packet. I think it 
> still makes sense to discuss timing in the protocol spec, but this is
> informative only.
> 
> Am I simply confused?

I more-or-less agree with you, except on this point (which is debatable).
The only way we could make CT completion a before the first packet arrival
a MUST would be that we have a CT-completion-ack message.  When this message
is recieved, then the handoff can be instigated.  I'm sure that this 
is a good idea, however.  

More generally, I see the use of different 'triggers' as a way to 
start context transfers.  One trigger could be simply that th
mobile node 'sees' a new point of attachment.  This could kick off
some context transfer.  Another trigger could be the initiation of
a handover and yet another would be the completion of a handover.
However, I'd prefer not to get into the uses of the triggers yet.
I think the usage of triggers will be situational - and the CT
should be robust enough to handle all situations.

br,
John

---

From: James Kempf <[email-masked]>
Date: Thu, 12 Jul 2001 08:27:09 -0700 (PDT)

Right, but if the CT is bundled with the HO signaling, there's no
issue of caching. Makes the implementation a lot simpler, for
implementations that can use that.

		jak
		
>From: "Kulwinder Atwal" <[email-masked]>
>To: "James Kempf" <[email-masked]>, <[email-masked]>
>Cc: <[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>, 
<[email-masked]>
>Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,    
      RE: Issue #4)
>Date: Thu, 12 Jul 2001 07:58:42 -0400
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
>
>
>----- Original Message -----
>From: "James Kempf" <[email-masked]>
>To: <[email-masked]>; <[email-masked]>; <[email-masked]>
>Cc: <[email-masked]>; <[email-masked]>;
><[email-masked]>; <[email-masked]>;
><[email-masked]>
>Sent: Wednesday, July 11, 2001 6:42 PM
>Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,
>RE: Issue #4)
>
>
>> Kulwinder,
>>
>> I was thinking more of whether or not a handoff is even going to happen.
>> If the HO signaling never occurs, the AR must drop the CT at some point,
>
>I am saying that 'some point' is upto the implementor based on memory/system
>load/amount of boundedness, etc as to when the state should be re-cycled, or
>if some part should be stored in non-voilatile memory.
>
>The implementor could just say that X amount of RAM will be available for
>all system operations, and any used memory (CT/HO state) will be freed
>periodically.  As far as an RTOS is concerned memory is memory.
>
>All a general timer really determines is how many outstanding CT/HO
>operations that an AR can have.  Since ARs come in all sizes and speeds a
>general timer is really arbitrary in limiting the number of outstanding
>CT/HO operations.
>
>If the HO never occurs the oldest pending CT could just be over-written with
>some new CT (A caching policy).
>
>I believe it a  memory management issue that can left to the implementor.
>
>- Kulwinder.
>
>> unless, as you note, it is so stable (and the amount of state the AR
>> must cache is well bounded) that it can simply hang on to it.
>>
>> jak
>>
>> >From: "Kulwinder Atwal" <[email-masked]>
>> >To: "James Kempf" <[email-masked]>, <[email-masked]>
>> >Cc: <[email-masked]>, <[email-masked]>,
>> <[email-masked]>, <[email-masked]>,
>> <[email-masked]>
>> >Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD
>be ,
>>       RE: Issue #4)
>> >Date: Thu, 12 Jul 2001 06:50:55 -0400
>> >X-Priority: 3
>> >X-MSMail-Priority: Normal
>> >X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
>> >
>> >
>> >----- Original Message -----
>> >From: "James Kempf" <[email-masked]>
>> >To: <[email-masked]>; <[email-masked]>
>> >Cc: <[email-masked]>; <[email-masked]>;
>> ><[email-masked]>; <[email-masked]>;
>> ><[email-masked]>
>> >Sent: Wednesday, July 11, 2001 6:05 PM
>> >Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD
>be ,
>> >RE: Issue #4)
>> >
>> >
>> >> Ok, then it does seem we agree (or perhaps Gary doesn't?) that
>> >> there is an ordering on what's needed for nAR to be primed for
>> >> that first packet. nAR must have the HO signaling and the CT
>> >> signaling, and if it doesn't have the first, it must wait
>> >> for the second, and vice versa.
>> >>
>> >> IMHO, whether or not that is done by doing the signaling separately
>> >> (and thus incurs the overhead of maintaining timers on the router)
>> >
>> >When a context is 'too stale' is really context dependant, not whether or
>> >not the HO happens according to some ideal.
>> >Therefore, the timers I would think would be for things like ROHC
>> >specifically, but not for static context or CT/HO in general.
>> >
>> >In fact, an AR in a private wireless network could hold on to static
>context
>> >in FLASH memory and reuse it, since it knows that there are only a few
>MNs
>> >in the small private network.  Such an AR would only ever need to request
>> >dynamic context and authentication.
>> >
>> >In general, as Gary has suggested, CT/HO state could just be the subject
>of
>> >garbage collection at an implemenation specific interval.
>> >
>> >- Kulwinder.
>> >
>> >> or together is an implementation decision. I suppose whoever does
>> >> the MIP binding will determine that.
>> >>
>> >> jak
>> >>
>> >> >Date: Wed, 11 Jul 2001 13:41:41 -0700
>> >> >From: Pat Calhoun <[email-masked]>
>> >> >To: James Kempf <[email-masked]>
>> >> >Cc: [email-masked], [email-masked],
>> >> [email-masked], [email-masked],
>> >[email-masked]
>> >> >Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
>(SHOULD
>> >be ,
>> >>       RE: Issue #4)
>> >> >Mail-Followup-To: James Kempf <[email-masked]>,
>> >[email-masked],
>> >> [email-masked], [email-masked],
>> >> [email-masked], [email-masked]
>> >> >Content-Disposition: inline
>> >> >User-Agent: Mutt/1.2.5i
>> >> >
>> >> >James,
>> >> >
>> >> >I believe that there are ways around this. One example is a very
>> >> >simple MIP extension that is sent stating that a CT is forthcoming
>> >> >(or may have already been sent). At least, this would be enough for
>> >> >the receiver to know that it must wait for CT before sending packets
>> >> >to the mobile.
>> >> >
>> >> >PatC
>> >> >On Wed, Jul 11, 2001 at 01:43:51PM -0700, James Kempf wrote:
>> >> >> Gary,
>> >> >>
>> >> >> >Err, no. That's not what I was agreeing to.
>> >> >> >Once again, proactive ct should be driven by the initiation
>> >> >> >event, not the deadline event. It is preferable that context
>> >> >> >be installed before the traffic arrives at the newAR, but it's
>> >> >> >not a MUST requirement, and it certainly does not dictate that
>> >> >> >ho and ct protocols must be synchronous.
>> >> >> >
>> >> >>
>> >> >> I'm not sure I understand. If nAR can't deliver packets unless
>> >> >> the CT is installed, then how can it not be a MUST requirement?
>> >> >> Seems to me, that the completion of the handover is predicated
>> >> >> on CT working.
>> >> >>
>> >> >> >And I see no reason for requiring handover signalling to complete
>> >> >> >before ct (MIP may require it, but that's would be a potential
>> >> >> >MIP weakness, were it true). Even if this is true, it applies only
>> >> >> >to reactive ct, and contradicts the purpose of proactive ct.
>> >> >> >
>> >> >>
>> >> >> Right, I didn't say it was a general requirement, I only said
>> >> >> I see it as a requirement for a particular solution. And I don't
>> >> >> necessarily see it as a weakness, if it results in faster handover
>for
>> >MIP.
>> >> >>
>> >> >> >You seem to be implying that there is some dire consequence to be
>> >> >> >realized if a ct happens but an ho doesn't. At best, the new AR
>> >> >> >will be holding onto useless context. At worse, the new AR may
>> >> >> >reserve resources that could be used elsewhere. Either situation
>> >> >> >seems resolvable with some sort of "life timer" and garbage
>> >> >> >collection. It does not imply that the two protocols be
>> >> >> >synchronous.
>> >> >> >
>> >> >>
>> >> >> I'm not implying anything, I'm just trying to figure out where
>> >> >> you are coming from. I've had my head embedded in this handover
>> >> >> problem for a while now, particularly with regard to making
>> >> >> MIP handover fast enough for real time streams, and every time
>> >> >> I tune into the CT discussion, it seems to be drifting off into
>> >> >> philosophy and further away from what IMHO is essential engineering
>> >> >> for getting MIP to work fast. I'm sure I'm probably missing
>> >> >> alot of context here (so to speak), and I do admit to a MIP bias,
>but
>> >I'm
>> >> >> having some real trouble extracting anything out of this.
>> >> >>
>> >> >> >I'm missing the critical state relationship between ct and ho
>> >> >> >that you are alluding to.
>> >> >> >
>> >> >>
>> >> >> Sure I am. Let's take  a specific example. Suppose we are doing
>> >> >> network assisted handover in MIP. Suppose that we want to transfer
>> >> >> the authentication  context and header compression context so that
>> >> >> we can start up the real time stream on the MN just as soon as
>> >> >> it shows up on the L2 (otherwise the user ends up hearing a half
>> >> >> duplex converstation). In order for the handover to successfully
>> >> >> conclude, the nAR needs:
>> >> >>
>> >> >> 1) Signaling from oAR that MN is coming soon,
>> >> >> 2) The relevent CT for nAR to install,
>> >> >> 3) Tunneled packets until MN gets around to changing its CoA.
>> >> >>
>> >> >> and it needs them in that order.
>> >> >>
>> >> >> Suppose they do not arrive in that order. Clearly, 3) being out of
>> >> >> order first can be ruled out. If 3) arrives before 1, nAR doesn't
>> >> >> know that MN is coming. If 2) arrives before 1), nAR can wait for
>1),
>> >> >> but that implies a timer. If 3) arrives before 2), the proper
>> >> >> authentication and header compression state isn't around.
>> >> >>
>> >> >> What am I missing?
>> >> >>
>> >> >> jak
>> >> >>
>> >>
>> >
>>
>

---

From: James Kempf <[email-masked]>
Date: Thu, 12 Jul 2001 09:01:43 -0700 (PDT)

Phil,

>Parallelization can be done cleanly, with MIP and other mobility models
>as James and I have suggested.   I see no reason to even talk about poly-
>phasic since, if its not important to the handover its not really mobility
>context.  Its application layer garbage that should NOT be cluttering CT.
>

This language is a little strong. 

While I agree with you that being able to bundle CT and HO signalling
is preferable, I also believe that Pat has a point about it not
being possible in some mobility protocols. He has indicated MIPv4
as an example. 

So the requirements need to be flexible enough to accommodate both.

		jak

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 12 Jul 2001 13:26:16 -0400

James:

> Sent: Wednesday, July 11, 2001 4:44 PM
> To: [email-masked]; [email-masked]; Kenward, Gary
> [WDLN2:AN10:EXCH]

Well, there is a case to be made (check the archives) for forwarding
before context is installed. Of course, this does not always make sense,
but in some situations it may work fine. 

Also, the nAR could buffer the packets, waiting for ct. 

Now, to be clear, I'm re-iterating arguements that have been made by
others on the list. I believe they are valid arguements for a general
ct solution. Whether they yeild "seamless" handover or not will only
be proven through operational experience.

> necessarily see it as a weakness, if it results in faster 
> handover for MIP.

Oh, ok. My mistake. Then you are not suggesting that we put it into
the requirements, given that it is a specific example?

> for getting MIP to work fast. I'm sure I'm probably missing

ct isn't about make MIP work fast (if MIP is slow, I don't think
ct will improve it ;^} ). 

You are right about the philosophical digressions. We are trying
to develope a general solution here, not a MIP feature, and it is
hard to capture all of the requirements for different mobility
scenarios without creating a shopping list. 

Personally, and I've tried to suggest this before, I think we 
should nod at what we have, and move on to the design. We can always 
go back to the requirements if we decide that there is something 
seriously wrong. A moot point, perhaps, because there appears to
be only one open issue, and it will hopefully be resolved in
London.

> alot of context here (so to speak), and I do admit to a MIP 
> bias, but I'm

Yes, for an ideal handover. Much of the arguements put forth have 
resisted the idea that ct be constrained by this sequence (c.f. above).

Also, I must point out, that 1) and 2) do not necessarly imply that 3)
will ever happen, and that must be captured in the requirements. Said
in another way, proactive ct can never be a gauaranteed service, it
is, as someone pointed out to me, a "best effort" service - you hope
that you get the context to the right AR, but you can never, ever,
gaurantee it (unless you ct to all the ARs in the access network ;^} ).

> know that MN is coming. If 2) arrives before 1), nAR can wait for 1),

A long debate, captured in the archives, centered around the desire
by some not to link 3) to 2). I agree that seamless handover would
require 2 to happen before 3 (and thus 1 before 2). I believe that
what is wanted by some is an assurance that the requirement for 
seamlessness doesn't create deadlock or hard failure situations.
This is a valid concern, but each new condition softens the wording of
the requirements.

Some of use are working on new wording. The tough part is not
in replacing the terminology, but in capturing the essence of a complex
process without getting into design detail and without writing 20 pages
of qualitative description.

I hope this helps James. To be clear: MIP is only one of the possible
mobility solutions that ct has to work with. Many of the alternative
mobility solutions are either non-public, under development, or non-IETF,
so we stumble over each issue as it comes up, and struggle with all the
ambiguities.

Gary

---

From: Phillip Neumiller <[email-masked]>
Date: Thu, 12 Jul 2001 13:34:41 -0400

James, Pat,

Yeah, sorry about the language.  I woke up on the wrong side of
Florida this morning or something.  More (kindler gentler 
points of light below) :-)

> Sent: Thursday, July 12, 2001 12:02 PM
> 

I would just like to add the requirement for the "active" CT where
CT occurs concurrently with handover.  If we can have pro- and re-
CAN we please add "active".  As for the poly-phasic stuff, I have
no use for it, but if the group sees use for it I have no problem
leaving it in.

Thanks,

Phil

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 12 Jul 2001 13:37:40 -0400

Phil:

  Consider this: does requiring ct to complete successfully in
addition to traffic handover make mobility more or less reliable?
If ct fails (or more likely is delayed), what is the fall back
position? Would it not be useful, in some situations, to allow
for traffic handover to proceed without ct? Simply as an option?

  This, to me, implies greater reliability, not less.

Gary

> From: Phillip Neumiller [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2001 5:18 PM
> To: 'James Kempf'; [email-masked]; Kenward, Gary
> [WDLN2:AN10:EXCH]
> Is there any co-dependence between CT and "succesful" handovers?
> I think so.  Seperating the messages makes handover less reliable.
> Do we want to build "seamless handover" systems that are less
> reliable?  What about jitter and congestions effect on the timing
> of multiple messages?  Yuck.  I don't get your argument Pat.
> 
> Best Regards,
> 
> Phil
>

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 12 Jul 2001 13:39:52 -0400

Me thinks Gary does agree. 

At least with the first paragraph. I'm not sure about the
second paragraph, but it sounds right.

Gary

> Sent: Wednesday, July 11, 2001 6:06 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; Kenward, Gary [WDLN2:AN10:EXCH];
> [email-masked]; [email-masked];
> [email-masked]
> >> alot of context here (so to speak), and I do admit to a 
> MIP bias, but I'm

---

From: Phillip Neumiller <[email-masked]>
Date: Thu, 12 Jul 2001 13:50:30 -0400

Hi Gary,
-----Original Message-----
>addition to traffic handover make mobility more or less reliable? 

Logically, if we NEED CT to acheive "seamless handover", i.e. 
CT <= (only if) seamless, then they are co-dependent.  Thus they
are inseperable if we are to acheive our goal.  The correct 
question to ask is "do you want CT with your handover?" 
I prefer the "happy meal" answer myself.

>position? 
 
A non-seamless handover, a non-goal for this WG right?

>Would it not be useful, in some situations, to allow 
>for traffic handover to proceed without ct?

Isn't that what we have now???

> Simply as an option? 

Sure don't use CT with your handover => no seamlessness. QED

>  This, to me, implies greater reliability, not less. 

You made no reliability argument in the above statements?
Flexibility arguments were made.

Thanks,

Phil

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 12 Jul 2001 13:51:18 -0400

John:

  There was a big debate over the suggestion that ct might delay
handover in the manner you suggest. Personally, I see pros and
cons on both sides: for seamlessness, you should be able to
delay handover (or buffer packets) up to a point (e.g. buffered
voice packets become useless after a short while); while for fast
handover you should be able to proceed without waiting for ct (and
lose some of the service features, such as, perhaps, header compression).

Gary

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, July 12, 2001 4:51 AM
> Cc: [email-masked]; [email-masked]

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 12 Jul 2001 14:10:05 -0400

Phil:

  If I understand your response, I think that the real issue
is that ct must support seamlessness, for as you identified,
that is the purpose of this wg. However, I think the point that
others have stressed is that ct should not break handover.

  Thus, ct must be completed for seamless handover, but is
not required (but may be completed) for handover in general.

  And of course, no one but us knows what seamless means ;^}.

Gary

> Sent: Thursday, July 12, 2001 1:51 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Phillip Neumiller;
> [email-masked]
> Cc: [email-masked]

---

From: Phillip Neumiller <[email-masked]>
Date: Thu, 12 Jul 2001 14:21:21 -0400

Yikes!

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Thursday, July 12, 2001 2:10 PM
To: 'Phillip Neumiller'; [email-masked]
Cc: [email-masked]
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,
RE: Issue #4)
>that is the purpose of this wg.  

NO!  CT is "part and parcel" of seamlessness.  No CT means you
don't have a seamless handover, a non-goal.  I thought we were
working to design seamless handovers?  If that IS the premise,
then we should work on the BEST way to do this.  The BEST way
to do this is not pre-, pro-, or poly, its a requirement that
is NOT part of the requirements surprisingly, its DURING as
in PART OF as in BUNDLED as in ACTIVE as in any other word
I can think of describe "inextricably linked".

> However, I think the point that 

You either have CT and you get seamlessness or you don't have
it and you DON'T get seemlessness.  I see the other proposals
as "threats" that tend to break or weaken the seamless case
which is our primary goal!!!

>not required (but may be completed) for handover in general.
Right.  BUT IT IS REQUIRED FOR A SEAMLESS HANDOVER RIGHT?????
 
>  And of course, no one but us knows what seamless means ;^}. 
huh?

-pdn

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 12 Jul 2001 14:34:38 -0400

Phil:

  I did not say that you could perform "seamless handover" without ct, 
I said that ct is not essential to an ordinary handover ("seamy handover"?).
And thus, a failure to complete ct on time must not cause an 
"ordinary handover" ("best effort handover"?) to fail.

   Some designers want to be able to fall back to a "best effort"
handover if the seamless handover fails, and yes, the seams will show.
  
Gary

(PS: we cannot use the word "seamless" in a draft, so it has no
formal definition ;^{ ; and we have never come up with an alternative
- nor do I want to get into *that* discussion ;^} ).

> Sent: Thursday, July 12, 2001 2:21 PM

---

From: Phillip Neumiller <[email-masked]>
Date: Thu, 12 Jul 2001 14:41:52 -0400

1).  Not using "seamless" in a draft is rule begging to be broken since it
is
      absolutely rediculous.  What is this Monty Python's flying IETF?
2).  OK I finally understand what you are saying, and it makes sense and
      a statement based on what your wrote below REALLY NEEDS TO BE
      IN THE DRAFT.
 
i.e. Handovers that use CT MAY fall back to best effort handvovers in the
cases where CT fails.  My argument is that to make this whole thing clean
and more reliable we should add a requirement like:
 
To increase the reliability of handovers using CT, the designer MAY bundle
the CT packet with handover signalling such as that used in MIPv4 and MIPv6.

 I said that ct is not essential to an ordinary handover ("seamy
handover"?). 
And thus, a failure to complete ct on time must not cause an 
"ordinary handover" ("best effort handover"?) to fail.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 12 Jul 2001 16:56:02 -0500

Gary,
 
I am glad that you realize what the problem is now, a deadline driven definition might
not be sufficient. 
 
Again as I said I like the link establishment based definition better, since it is a trigger
based definition (I don't think that is what the issue 4 said, too lazy to look :)
 
And again, the existing definition is better than none.
 
Madjid

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, July 11, 2001 9:20 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; [email-masked]'; [email-masked]
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue #4)

Madjid:
 
   I'm glad you feel this way. I guess this discussion began as a result of 
Issue #4, which proposes an alternate wording.
 
    After a few exchanges with Cedric, I reviewed the current text, and
I realized that it indicates that proactive is deadline driven, which I really
believe is a bad thing to require.  All I want to ensure is that there is a 
capability with ctp to start a ct sometime before the actually traffic handover
is initiated. Why? Because there are many networks that provide "warnings"
that a handover may be imminent (actually, most RF systems can be designed
to do this, and should). How? Well, the actual trigger event will change
depending upon the L2 design, but typically, the mechanism starts with the
base receiver sensing transmission from a mobile, and then usually many other 
mechanisms that kick in to identify the mobile at L1/L2.
 
   So, I would also like to keep the current text, for the same reason. I would
like to remove the deadline, or at least change it so that it is clearly a desirable
deadline, but not a requirement (we cannot make it a requirement because the physics
of wireless handover make the timing of any forewarning event completely un-
predictable).
 
   Maybe I've said this all before, and maybe my view is clear to everyone. Sorry
for being repetitive.
 
Gary

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Tuesday, July 10, 2001 6:37 PM
To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]'; [email-masked]
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)

Gary,
 
I don't think we should remove the reactive/ proactive definitions out of
requirement, unless there is a consensus for removing it.

Personally I liked the definitions that are based on the starting event
such as link establishment better, but I still can live with the exiting 
one (packet arrival) for the time being. Removing the whole thing
is throwing a lot of good thoughts away.
 
A requirement subject to modifications is better than no requirement.
 
Madjid

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, July 10, 2001 8:53 AM
To: [email-masked]'; [email-masked]
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)

John: 

Gary 

> From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > In thinking through the overall discussion, I am realize that the 
> > big difference between "reactive" and "proactive" is how they are 
> > triggered. "proactive" assumes that there is a trigger available 
> > early on that permits some context transfer in advance of an actual 
> > handover. 
> 
> I agree. My thoughts are that the discussion of reactive and proactive 
> >   I do believe the current wording for proactive is wrong. Now that 
> > I have had time to contemplate the wording, it does not define what 
> > that if we fix that wording, we can move on to the important part 
> > of designing ctp. 
> 
> My suggestion would be to cut-out of the requirements document the 
> discussion about proactive & reactive text.  I will try to make an

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 12 Jul 2001 17:33:17 -0500

Am I simply confused?

Madjid>> No Pat, you are not. From day one when we had the 
requirement of "CT must be timely", it reminded me of 
Jim Salomon's expression "you are kidding yourself" requirements.

I tried to say we either don't have timing requirements or when
we do it has to have a event driven deadline (no msec...)
I insisted that CT timing needs to be considered alongside
of HO timing and so [Proactive and reactive] package was as far as we got,
i.e.
Proactive does have a deadline (packet arrival) and reactive doesn't,
it is simply a best effort...
and since there was no discussion of procedural differences between
proactive
and reactive CT. If they are done differently by oldAR, then yes packet
arrival
is not enough indication.

Madjid

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 12 Jul 2001 18:00:39 -0500

<snip/snap>

>CT should be used for volatile handover related data nothing more.  If
>you want to piggy back a bunch of security crap on it that's a BAD idea.

Phil, Have you tried the unsecure HO idea with the ADs ??

:)
Madjid

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 12 Jul 2001 18:11:35 -0500

-----Original Message-----
From: Phillip Neumiller [mailto:[email-masked]]
Sent: Thursday, July 12, 2001 1:21 PM
To: 'Gary Kenward'; Phillip Neumiller; [email-masked]
Cc: [email-masked]
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD
be , RE: Issue #4)

Yikes!

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Thursday, July 12, 2001 2:10 PM
To: 'Phillip Neumiller'; [email-masked]
Cc: [email-masked]
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,
RE: Issue #4)

Madjid>> Linked with what? what messages are you using to 
bundle CT with? What triggers are you using to start CT?
Do we have to wait for L3 mechanisms to start CT?

The issue is the triggers that is why pre pro poly came in.

Madjid

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 12 Jul 2001 18:15:33 -0500

I actually mentioned this issue long time ago. However, I don't think a fall
back for CT mean
bundling everything with MIP. It would mean renegotiating the needed context
at 
the new AR and thinking I don't care how long that takes, since CT failed,
there is
nothing I can do.
 
Madjid

---

From: [email-masked]
Date: Fri, 13 Jul 2001 09:08:29 +0300

Hi Gary, 

[<JAL> ] I remember well - I'm not advocating this approach - just
saying it is possible ... 

John

---

From: [email-masked]
Date: Fri, 13 Jul 2001 09:12:27 +0300

Hi Phil,

> working to design seamless handovers?  

Last I checked, the WG was Seamless Mobility, not Seamless Handover.
There is a difference.

John

---

From: Phillip Neumiller <[email-masked]>
Date: Fri, 13 Jul 2001 09:30:26 -0400

Hi John,

> Last I checked, the WG was Seamless Mobility, not Seamless Handover.
Isn't Mobility <=> handover a tautology by now?  So, I find your 
statement a bit unusual.  I don't see ANY difference between talking
about mobility and the implied handovers that are a required part of
mobility.  Handover is the MOST significant/difficult/profound/worked
on/engineered activity in a mobile system.  Not sure where you are
going here John.

Thanks,

Phil

---

From: [email-masked]
Date: Mon, 16 Jul 2001 10:07:14 +0300

Phil,

> on/engineered activity in a mobile system.  Not sure where you are

I'd suggest that Mobility involves more than handovers.  If 
there is a way to tie in the Candidate Access Router Discover;
Context Transfer and maybe a few other bits & bytes ... with
handover, then you have mobility.

My point being is that there may well be uses for transfering
context seperately from the handover signaling.  Usually, a 
mobile node is aware of handoff candidates BEFORE the handover
occurs, so it might make some sense to transfer some context
before hand ...

thats all,
John