Subject: RE: [seamoby] Reactive context transfer

From: James Kempf <[email-masked]>
Date: Fri, 15 Jun 2001 11:08:48 -0700 (PDT)

Charlie/Gary,

> For us, it is unacceptable that CT should be dependent upon
>some layer 3 messaging from the MN. Over the air transit latencies
>are just too great, and we don' see the value. I think here we
>simply must agree that we have different views of the world.
>

I agree with this. Increasing the handover latency even more
results in a higher probability of human  perceptible artifacts in real time 
streams. We cannot realistically recommend IP as a substrate for 4G
telephony unless we can design handover so that the probability
of artifacts is absolutely minimal.

> This whole issue was discussed at great length, and it was
>clear then that there was no "right" approach. We decided then
>that we would abstract out the initiating event - some called
>it a trigger - and that would allow for different networks and
>different vendors to define the approach they like the best.
>

I agree with this as well. In WLANs, for example, the aggregate
bandwidth is much higher. The amount of latency in small cells with few MNs 
moving slowly (walking speed at best) will probably be small enough
that the MN can become actively involved in context transfer.

The specification needs to parameterized so that triggering of
handover depends on the characteristics of the radio link. Charlie's
original message had four possiblities, which I view as being
two sets of orthogonal characteristics, with two possibilities each.
One set is network, mobile triggered. The other is source, target
triggered (or what you have been calling proactive and reactive).
I think the spec needs to call these out.

		jak

---

From: Kulwinder Atwal <[email-masked]>
Date: Fri, 15 Jun 2001 14:25:45 -0400

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, June 15, 2001 1:58 PM
To: 'Charles E. Perkins'
Cc: 'seamoby'
Subject: RE: [seamoby] Reactive context transfer

Charlie: 

This is implementation specific. 

Since I was the one who proposed triggers.  My recollection is quite
different.

The intent was that we would not know where the trigger packet came from,
but at no time did I ever suggest it was out of scope.

In fact, I explicitly stated that it could be MN or Network initiated as did
Vijay. 

 Who triggers context transfer is not relevant, unless we believe 
we are going to build the trigger into CTP as a signalling message. 
There was a long debate, and it was decided very early on that 
it was not necessary to build this into CTP. That does not 
mean that this approach is excluded from the mobility solution, nor 
does it mean that an MN message could not trigger CT indirectly. It 
simply means that CTP will not include an MN to AR message. 

 You can refer to the archives if you question this, in particular, 
the conference call meeting minutes.  

IETF rules do not allow concensus from meetings.  ONLY mailing lists
concenus is valid. 

 At the moment, I would suggest strongly that we retain that decision. 
It allows both camps to work on their preferred solution. More importantly, 
it would allow us to move forward. 

We cannot move forward until this is resolved.

- Kulwinder.  

 What you are proposing is to return to the discussions of six months ago. 
This would be unacceptable to me, for sure, and I suspect others engaged 
with this process would also be very frustrated. 

Gary 

> -----Original Message----- 
> From: Charles E. Perkins [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Friday, June 15, 2001 1:01 PM 
> To: Kenward, Gary [WDLN2:AN10:EXCH] 
> Cc: 'seamoby' 
> Subject: [seamoby] Reactive context transfer 
> 
> 
> 
> Hello Gary, 
> 
> > Gary Kenward wrote: 
> 
> >        .......                   We did discuss how CT was to be 
> > initiated, and agreed that there would be no explicit 
> signalling from 
> > the MN (not at least as far as CT was concerned). 
> 
> I would consider this as wholly unacceptable, except that in your 
> next paragraph you state: 
> 
> >   The definition of reactive CT (read the problem 
> statement)has to do with 
> > the order/timing of events, not with where the initiating 
> event comes from. 
> 
> So then I started to wonder about how one might define "reactive" to 
> make the previous sentence come true.  But, the word "reactive" does 
> not occur in draft-ietf-seamoby-context-transfer-problem-stat-01.txt. 
> No help there.  I did find some redefinition of "reactive" in 
> draft-hamid-seamoby-ct-fwk-00.txt, but that document was, I believe, 
> not the result of design team discussions.  In fact, I have some 
> other comments on the latter document, but for now I would just like 
> to suggest that it should not be taken as relevant to the current 
> discussion about reactive context transfers. 
> 
> That puts me back to square one.  From that standpoint, I would like 
> to suggest that the context transfer problem statement needs to 
> very clearly define the following concepts: 
> 
> - Network-initiated context transfer, for which the access network 
>   tells the mobile where to go 
> 
> - Mobile-initiated context transfer, for which the mobile tells the 
>   network where it wants to go 
> 
> - Predictive context transfer, for which either the mobile or the 
>   network initiates context transfer BEFORE leaving the previous 
>   access router 
> 
> - Reactive context transfer, for which either the mobile or 
> the network 
>   initiates context transfer AFTER the mobile arrives (establishes 
>   a link) at the new access router. 
> 
> 
> I like the word "predictive" for several reasons: 
> 
> - It has exactly the right meaning, and even connotes that caution 
>   is necessary because not all predictions come true 
> 
> - In contrast to some other alternatives one often hears, it is 
>   a word that one can find in the dictionary. 
> 
> Regards, 
> Charlie P. 
>

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 15 Jun 2001 14:52:01 -0400

Charlie:

  I'm never one to oppose providing for optional solutions,
as long as the cost is justifiable. I think we are together
on this. Let's get to the protocol design and take it from there.

Gary

> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Friday, June 15, 2001 2:11 PM
> Subject: Re: [seamoby] Reactive context transfer
> 
> 
> 
> Hello Gary,
> 
> > Gary Kenward wrote:
> 
> Maybe we're not so far apart after all.  Of course I agree that
> we should have the possibility to do context transfer without
> requiring the mobile node to trigger the process.  I'm just
> holding out for the possibility that the mobile node CAN trigger
> the process in some circumstances.  For instance, it would probably
> be just fine over 802.11, even if it's not advisable over some
> cellular media.
> 
> Exactly.  Thus, I claim we aren't so far apart.  But, some of the
> allowable choices should include allowing the mobile node to
> initiate the process of context transfer.
> 
> Again, just because context transfer CAN be accomplished without
> a trigger from the mobile node in SOME circumstances, does not mean
> that the mobile node should be disallowed from supplying the trigger
> in OTHER circumstances.  Thus, I agree with the second and third
> sentences, but it seems pretty clear that we can ALLOW such a
> trigger indication without dragging down the rest of the protocol.
> Thus I am asking for reconsideration of the 4th sentence, and I
> don't see any downside at all.
> 
> That's raising the bar pretty high for my participation in this
> particular discussion.  Would it be O.K. to ask that you respond
> just to my points in this e-mail?
> 
> Well, from the e-mail I've seen so far, it looks like there may be
> frustrations on both sides.  Moreover, to accomodate those who wish
> to allow mobile-node triggering, I don't think would cause any
> discomfort to those who want to have network-initiated transfers.
> So why not?
> 
> Regards,
> Charlie P.
>

---

From: Kulwinder Atwal <[email-masked]>
Date: Fri, 15 Jun 2001 17:06:12 -0400

> From: Charlie Perkins [mailto:[email-masked]]
> Sent: Friday, June 15, 2001 4:59 PM
> To: Gary Kenward
> Cc: [seamoby] Working Group mailing list
> >  Will the mobile actually initiate a ct or will it initiate a
> > handover? Or are you expecting to do both?
> 
> It seems to me that quite often, if the mobile is going to
> initiate a handover, it will request that the context features
> should be transferred at the same time.  However, I do
> not suggest that we should make such a restriction.
> Is it necessary to be explicit?
> 
> 
> 
> 
> > Do you expect to complete
> > MN initiated CT in less then 60ms? If not, how will ct in 
> this context
> >
> > provide seamless handover for VoIP?
> 
> I would hope that any system built to support VoIP would complete
> a context transfer within 60ms.  Perhaps systems built that require
> mobile-initiated context transfers will take longer than others, but
> still fit within the time requirements.  It would depend on many
> factors.

Also, a bifurcated flow lasting less than half a dozen packets is an option
for systems with less than ideal signalling delay.

- Kulwinder.

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 15 Jun 2001 18:58:35 -0400

Hello again.

> Is it necessary to be explicit?

Only for proactive CT. Although, I'm not sure of how, at the IP
layer, a mobile would know that it is about to handover, but hasn't
yet (of course, it's simply a matter of providing the right event
from the link layer I suppose).

> still fit within the time requirements.  It would depend on many

Ok, we agree. Then what is your understanding of the 3G radio channel
transfer delay for a single IP frame? 

Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 15 Jun 2001 18:59:29 -0400

I've lost count ;^{

-----Original Message-----
From: Charlie Perkins [mailto:[email-masked]]
Sent: Friday, June 15, 2001 5:10 PM
To: Kenward, Gary [WDLN2:AN10:EXCH]
Cc: 'seamoby'
Subject: Re: [seamoby] Reactive context transfer

Hello folks, 

I don't want to fan the flames, but I have to pipe up and 
speak here. 

Gary Kenward wrote: 

 Actually, it turns out that consensus cannot be determined at the dtlevel,
only at the wg level - which requires Pat.  
 Based upon this, every "decision" made during the last six months canbe
re-opened. I hope Pat has lot's of energy.Gary

In the first place, according to my understanding, Pat should 
play an equal role in the consensus as other working group 
members.  The working group chair can make determinations 
about what the consensus of the group is, and  try to 
see whether or not the milestones are likely to be met by 
following the processes of the moment.  However, it is possible 
for the working group consensus to take shape in a way that 
may be different than the desires of the working-group chair(s) 

Of course, the foregoing is only my opinion and someone else 
who knows the rules better might be able to make some 
clarifications.  But I'll bet it's not too far wrong.. 

As for the problem of re-opening previous decisions, that 
should only happen if the previous decisions cannot stand up 
to working-group scrutiny.  I don't see that happening, and 
it seems to me that the current discussion (about reactive 
signaling) has only taken up a few days.  Of course there 
were lots of discussions preceding the current one -- but I 
reckon you weren't counting those. 

Regards, 
Charlie P.

---

From: [email-masked]
Date: Tue, 19 Jun 2001 09:01:20 +0300

Hi Hamid,
 
All right. Let me suggest the following requirements plus the description
part and see if we can get a consensus on it. 

4.2 The context transfer MUST define the common IP level (layer 3) triggers
to initiate context transfer. 

4.3 The context transfer MUST separate the signaling to initiate Context
Transfer from the transfer of context.   

	The request for the transfer of context may come from the MN,
current AR, recieving AR, or other entity on the Access Network. There could
be instances where the access network or the MN may need to initiate context
transfer e.g. to actively balance the load between several ARs or to switch
to a different type of access technology.   Therefore, a common set of IP
level signalling messages (Layer 3 Triggers) must be defined, and the
current AR must capable of recieveing such messsages on any of its
interfaces.  These signalling messages do not preclude the use of Layer 2
Triggers at the current AR to initiate the common layer 3 signaling for
context transfer initiation.

While this is a noble goal, in practice I think that this will be a hard one
to fufill.  (Please interpret this meaning that I support this work, but
think it will be very hard to do.  I'd suggest it as a seperate work item.)
Rather than MUST, I suggest we change this to SHOULD.  I'd suggest the
following:
 
4.2 Context transfer SHOULD define common IP level (layer 3) triggers to
initiate context transfer.
4.3 Context transfer MUST provide mechanisms for layer 2 triggers to intiate
context transfer.
4.4 Context transfer SHOULD separate the signaling to initiate Context
Transfer from the transfer of context.
 
4.3 is added for completeness.
 
4.4 is a SHOULD I think.  What is the need for seperating signaling and
transfer of context?  If I am an AR, and I get a message 'Here is new header
compression state for mobile node x' - I might be able to think that means
that mobile node x is going to be coming to me soon ... 
 
best regards,
John 
 
4

---

From: "Hamid Syed" <[email-masked]>
Date: Tue, 19 Jun 2001 09:35:28 -0400

Hello John,

see my rssponse below.

best regards

-Hamid

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Tuesday, June 19, 2001 2:01 AM
> To:	Syed, Hamid [WDLN2:AN22:EXCH]
> Cc:	[email-masked]
	[Syed, Hamid [WDLN2:AN22:EXCH]]  Well. Any layer 2 mechanism is out
of the IETF scope. It will also be layer 2 technology specific which we are
trying to avoid. Definitely each layer 2 technology can define its own
meachnism to trigger the common IP layer triggers for context transfer. If
we work on layer 3 triggers, it would be well within the ct scope. 
> Transfer from the transfer of context.
	[Syed, Hamid [WDLN2:AN22:EXCH]]  I would rather prefer MUST for 4.4.
See my comment below. 
> that mobile node x is going to be coming to me soon ... 
	[Syed, Hamid [WDLN2:AN22:EXCH]]  The source of signaling could be
MN, AR or any entity in the access network (ref: the description part of the
requirements) while the context transfer happens between the old and new
ARs. That is why the signaling MUST be separated from the actual transfer of
context.

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Tue, 19 Jun 2001 09:59:21 -0500

Hello Hamid:
I have some questions for you.
regards,
ajoy 
 
Syed, Hamid [WDLN2:AN22:EXCH]]  Well. Any layer 2 mechanism is out of the IETF scope. It will also be layer 2 technology specific which we are trying to avoid. 
 
Ajoy: I thought we are assuming layer 2 triggers not defining any mechanisms for layer 2 trigger. BTW,
in absence of layer 2 trigger, how mobile node will know if it has moved to a new
access router. 
 
Definitely each layer 2 technology can define its own mechanism to trigger the common IP layer triggers for context transfer. 
 
Ajoy: Are you saying that layer 2 trigger at MN will initiate layer 3 message which may be used to initiate Context Transfer ? 

 

 -----Original Message-----
From: Hamid Syed [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 8:35 AM
To: [email-masked]'
Cc: [email-masked]
Subject: RE: [seamoby] Reactive context transfer

Hello John, 

see my rssponse below. 

best regards 

-Hamid 

	-----Original Message----- 
From:   [email-masked] [SMTP:[email-masked]] 
Sent:   Tuesday, June 19, 2001 2:01 AM 
To:     Syed, Hamid [WDLN2:AN22:EXCH] 
Cc:     [email-masked] 
Subject:        Re: [seamoby] Reactive context transfer 

	Hi Hamid, 

  
4.2 Context transfer SHOULD define common IP level (layer 3) triggers to 
initiate context transfer. 
4.3 Context transfer MUST provide mechanisms for layer 2 triggers to intiate 
context transfer. 
[Syed, Hamid [WDLN2:AN22:EXCH]]  Well. Any layer 2 mechanism is out of the IETF scope. It will also be layer 2 technology specific which we are trying to avoid. Definitely each layer 2 technology can define its own meachnism to trigger the common IP layer triggers for context transfer. If we work on layer 3 triggers, it would be well within the ct scope. 

	4.4 Context transfer SHOULD separate the signaling to initiate Context 
Transfer from the transfer of context. 
[Syed, Hamid [WDLN2:AN22:EXCH]]  I would rather prefer MUST for 4.4. See my comment below. 
4.3 is added for completeness. 
  
[Syed, Hamid [WDLN2:AN22:EXCH]]  The source of signaling could be MN, AR or any entity in the access network (ref: the description part of the requirements) while the context transfer happens between the old and new ARs. That is why the signaling MUST be separated from the actual transfer of context.   

	best regards, 
John 
  
4

---

From: "Hamid Syed" <[email-masked]>
Date: Tue, 19 Jun 2001 11:42:53 -0400

Hello Ajoy,

see my response below.

regards

-Hamid

> From:	Singh Ajoy-ASINGH1 [SMTP:[email-masked]]
> Sent:	Tuesday, June 19, 2001 10:59 AM
> To:	Syed, Hamid [WDLN2:AN22:EXCH]; [email-masked]'
> Cc:	[email-masked]
> Syed, Hamid [WDLN2:AN22:EXCH]]  Well. Any layer 2 mechanism is out of the
> IETF scope. It will also be layer 2 technology specific which we are
> trying to avoid. 
>  
[Syed, Hamid [WDLN2:AN22:EXCH]]  At IETF, probably we need to define layer 3
trigger and its characteristics to initiate context transfer. I am not
saying that there wont be any layer 2 triggers but those could be different
for individual layer 2 technology. 

>  
> Definitely each layer 2 technology can define its own mechanism to trigger
> the common IP layer triggers for context transfer. 
>  
> Ajoy: Are you saying that layer 2 trigger at MN will initiate layer 3
> message which may be used to initiate Context Transfer ?
	[Syed, Hamid [WDLN2:AN22:EXCH]]  Yes. 
> of the IETF scope. It will also be layer 2 technology specific which we
> are trying to avoid. Definitely each layer 2 technology can define its own
> MN, AR or any entity in the access network (ref: the description part of
> the requirements) while the context transfer happens between the old and
> new ARs. That is why the signaling MUST be separated from the actual
> transfer of context.   
> 
> 		best regards, 
> 	John 
> 	  
> 	4 
> 	  
> 	  
> 	  
>

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Tue, 19 Jun 2001 11:43:05 -0500

Hello Hamid:

Please see one more questions.

regards,

ajoy 

Don't you think any layer 3 message from MN to newAR may be too late for
context transfer? The nework

layer message can only be sent by MN to newAR upon completion of layer 2
handover.  

[-----Original Message-----
From: Hamid Syed [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 10:43 AM
To: 'Singh Ajoy-ASINGH1'; [email-masked]'
Cc: [email-masked]
Subject: RE: [seamoby] Reactive context transfer

Hello Ajoy, 

see my response below. 

regards 

-Hamid 

	-----Original Message----- 
From:   Singh Ajoy-ASINGH1 [SMTP:[email-masked]] 
Sent:   Tuesday, June 19, 2001 10:59 AM 
To:     Syed, Hamid [WDLN2:AN22:EXCH]; [email-masked]' 
Cc:     [email-masked] 
Subject:        RE: [seamoby] Reactive context transfer 

	Hello Hamid: 
  
Syed, Hamid [WDLN2:AN22:EXCH]]  Well. Any layer 2 mechanism is out of the
IETF scope. It will also be layer 2 technology specific which we are trying
to avoid. 

Ajoy: I thought we are assuming layer 2 triggers not defining any mechanisms
for layer 2 trigger. BTW, 
in absence of layer 2 trigger, how mobile node will know if it has moved to
a new 
access router. 

  

  

	 -----Original Message-----
From: Hamid Syed [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Tuesday, June 19, 2001 8:35 AM
To: [email-masked]'
Cc: [email-masked]
Subject: RE: [seamoby] Reactive context transfer

	Hello John, 

	see my rssponse below. 

	best regards 

	-Hamid 

	        -----Original Message-----
From:   [email-masked] [SMTP:[email-masked]]
Sent:   Tuesday, June 19, 2001 2:01 AM
To:     Syed, Hamid [WDLN2:AN22:EXCH]
Cc:     [email-masked]
Subject:        Re: [seamoby] Reactive context transfer 

	        Hi Hamid,

	        4.2 The context transfer MUST define the common IP level
(layer 3) triggers
to initiate context transfer. 

	        4.3 The context transfer MUST separate the signaling to
initiate Context
Transfer from the transfer of context.   

	                The request for the transfer of context may come
from the MN,

	        While this is a noble goal, in practice I think that this
will be a hard one
to fufill.  (Please interpret this meaning that I support this work, but
think it will be very hard to do.  I'd suggest it as a seperate work item.)
Rather than MUST, I suggest we change this to SHOULD.  I'd suggest the
following:
 
4.2 Context transfer SHOULD define common IP level (layer 3) triggers to
initiate context transfer.
4.3 Context transfer MUST provide mechanisms for layer 2 triggers to intiate
context transfer.
[Syed, Hamid [WDLN2:AN22:EXCH]]  Well. Any layer 2 mechanism is out of the
IETF scope. It will also be layer 2 technology specific which we are trying
to avoid. Definitely each layer 2 technology can define its own meachnism to
trigger the common IP layer triggers for context transfer. If we work on
layer 3 triggers, it would be well within the ct scope. 

	        4.4 Context transfer SHOULD separate the signaling to
initiate Context
Transfer from the transfer of context.
[Syed, Hamid [WDLN2:AN22:EXCH]]  I would rather prefer MUST for 4.4. See my
comment below.
4.3 is added for completeness.
 
4.4 is a SHOULD I think.  What is the need for seperating signaling and
transfer of context?  If I am an AR, and I get a message 'Here is new header
compression state for mobile node x' - I might be able to think that means
that mobile node x is going to be coming to me soon ...
[Syed, Hamid [WDLN2:AN22:EXCH]]  The source of signaling could be MN, AR or
any entity in the access network (ref: the description part of the
requirements) while the context transfer happens between the old and new
ARs. That is why the signaling MUST be separated from the actual transfer of
context.   

	        best regards,
John
 
4

---

From: Kulwinder Atwal <[email-masked]>
Date: Tue, 19 Jun 2001 15:24:34 -0400

> From: [email-masked] [mailto:[email-masked]]
> To: [email-masked]
> Cc: [email-masked]

An load balance decision, or the MN requesting this will not have context to
contribute.  Further, if it is the newAR, it will not be sending context to
oldAR.  It will be requesting.

- Kulwinder.

---

From: Kulwinder Atwal <[email-masked]>
Date: Tue, 19 Jun 2001 15:27:32 -0400

-----Original Message-----
From: Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 12:43 PM
To: 'Hamid Syed'; Singh Ajoy-ASINGH1; [email-masked]'
Cc: [email-masked]
Subject: RE: [seamoby] Reactive context transfer

Hello Hamid:

[ka] The request could have been made at the oldAR, before the MN moved to
the newAR.

Hello Ajoy, 
see my response below. 
regards 
-Hamid 

 

  

  
  
 -----Original Message-----
From: Hamid Syed [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 8:35 AM
To: [email-masked]'
Cc: [email-masked]
Subject: RE: [seamoby] Reactive context transfer

Hello John, 
see my rssponse below. 
best regards 
-Hamid 
        -----Original Message-----
From:   [email-masked] [SMTP:[email-masked]]
Sent:   Tuesday, June 19, 2001 2:01 AM
To:     Syed, Hamid [WDLN2:AN22:EXCH]
Cc:     [email-masked]
Subject:        Re: [seamoby] Reactive context transfer 
        Hi Hamid,
 
        4.2 The context transfer MUST define the common IP level (layer 3)
triggers
        4.3 The context transfer MUST separate the signaling to initiate
Context
                The request for the transfer of context may come from the
MN,

        While this is a noble goal, in practice I think that this will be a
hard one
to fufill.  (Please interpret this meaning that I support this work, but
think it will be very hard to do.  I'd suggest it as a seperate work item.)
Rather than MUST, I suggest we change this to SHOULD.  I'd suggest the
following:
 
        4.4 Context transfer SHOULD separate the signaling to initiate
Context

4

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 20 Jun 2001 15:16:44 -0500

John,

What is a "common" IP level trigger mean here? common with what?

What is the difference between "signalling to initiate context tranfer
(which is
a CT trigger)" and 
"common IP level triggers". 
Don't get me wrong, I think I was among the very first people who 
talked about CT trigger, but I am not sure I see the difference the two.

Thanks,
Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 1:01 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [seamoby] Reactive context transfer

Hi Hamid,

 

 
best regards,
John 
 
4

---

From: [email-masked]
Date: Thu, 21 Jun 2001 09:10:55 +0300

Hi Madjid,

> What is a "common" IP level trigger mean here? common with what?

Common might not be the correct term, perhaps standard would be better?
Of course, going into standard IP triggers gets into an API issue.
Should we go down that road already?

> (which is a CT trigger)" and "common IP level triggers". 

I am making a seperation between an explicit message (i.e. - signaling)
and the arrival of some data (which could be a trigger).

> talked about CT trigger, but I am not sure I see the 

I think the difference (in my mind) is whether we have implicit 
signaling or explicit signaling.  

More comments in my next mail.

John

---

From: [email-masked]
Date: Thu, 21 Jun 2001 09:23:01 +0300

Hi Hamid,

> of the IETF scope. It will also be layer 2 technology specific which
> we are trying to avoid. Definitely each layer 2 technology can define
> its own meachnism to trigger the common IP layer triggers for context
> transfer. If we work on layer 3 triggers, it would be well within the ct
scope. 

Well, I think that standardizing layer 2 info is outside of the
scope of the IETF, supporting layer 2 info is not outside of the
scope - but it is an implementation dependent issue.  All I seek
is that we don't disallow layer 2 triggers in addition to layer
3 triggers.

Layer 3 triggers are a bit tricky, in my opinion, because layer 3 triggers
may be impacted by the OS you are using, the seperation between
user space & kernel space, etc.  I think this is work that needs to
be done, but I'm not so sure it should be embedded within a 
SeaMoby document.

> [Syed, Hamid [WDLN2:AN22:EXCH]]  The source of signaling could be MN, AR 
> or any entity in the access network (ref: the description part of the 
> ARs. That is why the signaling MUST be separated from the actual transfer 
> of context.   

Perhaps we are debating if the signaling is implicit or explicit.

Would modifying the above to:

4.4 Context transfer MUST be able to separate the signaling to initiate 
Context Transfer from the transfer of context. 

This would allow seperate signaling where needed, but also allow 
the context transfer itself to act as signaling as well.

br,
John

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 21 Jun 2001 12:22:43 -0500

Hi John,

Why is explicit messaging so important, it might even
add more delay. I think we should go after the event that
 triggers this signaling (implicit or explicit is less important
IMHO).

Madjid 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, June 21, 2001 1:11 AM
To: Madjid.Nakhjiri
Cc: [email-masked]
Subject: RE: [seamoby] Reactive context transfer

Hi Madjid,

John

---

From: [email-masked]
Date: Mon, 25 Jun 2001 15:47:41 +0300

Hi Madjid,

> triggers this signaling (implicit or explicit is less important

I was just seperating the concepts out.  I don't like 
explicit signaling either.

John